Why a Nextcloud 35 upgrade starts with the platform stack
Moving a Nextcloud 34 server to version 35 is a single major step, and whether it goes smoothly depends on four things being ready before you start: the PHP runtime, the database, the web server and the installed apps. Plan the platform stack first and treat the Nextcloud package as the last thing to change. Nextcloud 35 (Hub 26 Summer) was released on 16 September 2026. Nextcloud 34 is supported until June 2027 and version 35 reaches end of life in September 2027, so an instance that stays on 34 has a fixed window to move, and that window is shorter than it may look once testing and change approval are counted.
Nextcloud does not allow skipping major releases. An instance on 34 must already run 34 successfully, and an instance still on 33 must move to 34 before it can reach 35. Confirm your current version and the version history of the server before you schedule anything. Nextcloud 33 is supported until February 2027, so an older server may already be on an unsupported line. If your server is several versions behind, read the multi-version upgrade guide first. If it is on 33, the 32 to 33 upgrade page covers the earlier step. Both pages are related reading for this one.
This page covers the changes that matter for 35, how to prepare, the order of work, how to roll back and what drives effort. The main decisions come early. Nextcloud 35 recommends PHP 8.5, with 8.3 and 8.4 also supported, and the topic changes include removal of PHP 8.2 support. It recommends MariaDB 11.8 or PostgreSQL 18, with a supported range for each and MySQL 8.4 or 9.7 also supported. It recommends Apache 2.4 or nginx with php-fpm. Oracle Database is only available with an enterprise subscription. Check each of these against the system requirements for 35 and your operating system before you choose target versions.
Start with an inventory. Record the current versions of PHP, the database, the web server, the operating system and every installed app, and note which apps come from the app store and which were built in-house. Then decide whether each platform change happens before the Nextcloud jump or as part of it, and give each change its own backup and rollback point. Effort depends on how many layers are out of date, how many apps must be tested and how much of the environment is documented. Ask any partner for a fixed-scope written proposal that lists the inventory, each platform change, the app checks and the rollback test as separate items.
What changes in Nextcloud 35 for an installed 34 server
This table compares the main requirement and upgrade-path changes between an installed Nextcloud 34 server and Nextcloud 35, with the action each one needs. Read each row against your current PHP, database, operating system and app versions before you schedule the jump. The main takeaway is that PHP and database versions are the most likely blockers, and third-party apps need confirmed compatibility before you start.
| Change | Impact | Action needed |
|---|---|---|
| PHP support | Nextcloud 35 recommends PHP 8.5 and lists 8.3 and 8.4 as supported. The topic states PHP 8.2 is removed. | Confirm the PHP 8.2 removal in the Nextcloud 35 system requirements, then move to a supported PHP version before upgrading. |
| Database minimums | Supported ranges are MariaDB 10.11 to 12.3, PostgreSQL 14 to 18 and MySQL 8.4 or 9.7. Nextcloud recommends MariaDB 11.8 or PostgreSQL 18. | Check that your current database version falls inside a supported range, and plan a database upgrade if it does not. |
| MySQL 9 MD5 component | The topic says a component is needed on MySQL 9 deployments only. | Confirm the exact requirement and component name in MySQL vendor documentation, and test the change in a non-production copy. |
| Operating system minimums | Minimums depend on your distribution, and this page does not list them. | Check the Nextcloud 35 system requirements for your distribution and confirm your installed OS packages meet them. |
| Web server | Nextcloud 35 recommends Apache 2.4 or nginx with php-fpm. | Confirm your web server and PHP-FPM configuration matches the documented setup before the upgrade. |
| Third-party app compatibility | Apps may not support Nextcloud 35 yet, and an incompatible app can block or break the upgrade. | Disable third-party apps before upgrading, and re-enable each one only after its developer confirms compatibility. |
| Major version path | Nextcloud does not allow skipping major releases during upgrades. | Upgrade from 34 to 35 as a single major step, with a full backup taken first. |
Which PHP and database versions Nextcloud 35 expects
Read the Nextcloud 35 requirements as two separate lists. The recommended versions are MariaDB 11.8 or PostgreSQL 18 for the database, PHP 8.5, and Apache 2.4 or nginx with php-fpm for the web tier. The supported ranges are wider: MariaDB 10.11 to 12.3, PostgreSQL 14 to 18, MySQL 8.4 or 9.7, and PHP 8.3 or 8.4. A supported version passes the requirements check and receives maintenance, but Nextcloud describes the recommended version as the one it aims for. Choose the recommended version when your platform allows it, and record a reason in the change ticket whenever you choose a supported version instead.
Treat the supported range as the minimum you can run during the jump, not as a target. Compare your running PHP and database against the range before you schedule anything. Any PHP release outside the 8.3 and 8.4 pair, including older versions still running on your current 34 installation, has to be moved first. The same applies to a database older than MariaDB 10.11 or PostgreSQL 14. A PHP or database upgrade is usually a separate change that happens on the current release, with its own test cycle, before you start the Nextcloud major upgrade.
The database version also sets the migration timing. A major database upgrade needs its own backup, restore test and rollback plan, and it often takes longer than the Nextcloud step itself. Confirm the database vendor's upgrade path from your current version to the target, and check that your backup tooling, replication and monitoring support the new version. If you run Oracle Database, note that Nextcloud 35 lists it only with an enterprise subscription. Confirm the licensing position with Nextcloud before you plan that path, because it changes the platform decision, not only the version number.
Pull the current requirements table from the Nextcloud system requirements page on the day of the upgrade. Requirements can change between releases, so a table copied into a planning document weeks earlier may be out of date. Save a dated copy with the change ticket, then compare it against the versions you actually run. Record the output of the PHP version command, the database server version query and the web server version on every node. Any mismatch becomes a blocking item for the go or no-go review, not a note for later.
Backups and checks to complete before the Nextcloud 35 upgrade
Nextcloud does not allow skipping major releases, and each upgrade should start from a verified backup and a known list of apps and settings. The four areas below form one preparation set, and each produces evidence the team can rely on if the upgrade to Nextcloud 35 must be reversed or repeated in a test environment.
Full backup of data and database
Take a full backup of the data directory and the database before every upgrade, and capture both from the same point in time so files and metadata agree. Put the instance in maintenance mode while the copy runs, and keep a copy of config.php with it, because the instance needs its configuration values to start again. Evidence to produce: a restore test log showing the backup was restored to a separate host and that users could sign in and open files. Confirm the restore time with your own storage before planning the change window.
App and customization inventory
List every installed app with its version, source and maintainer, and record each customization, such as custom themes, login scripts, external storage mounts and reverse proxy rules. Mark each item as compatible with Nextcloud 35, unverified or to be removed. Nextcloud's guidance is to disable third-party apps until they are confirmed compatible, so the output is an app compatibility list that the owner of each app has signed off. Ask app vendors for written compatibility statements.
Test environment from production copy
Build a test instance from a recent copy of production that matches it on PHP version, database engine and version, and web server, using the Nextcloud 35 system requirements as the target. Isolate it by disabling outbound mail, sync connectors and push notifications so test runs cannot reach real users or external systems. Run the full upgrade there first, then check sign-in, desktop and mobile sync, and each app. Evidence to produce: the upgrade log and a smoke test record listing each failure and its fix.
Server configuration review
Review config.php, PHP settings and the web server configuration before the upgrade. Check that memory caching and file locking are configured as intended, that background jobs are set to system cron, and that the data directory sits outside the web root with correct ownership and permissions. Confirm that trusted domains and the overwrite URL match the reverse proxy. Evidence to produce: a dated configuration export in which the administrator marks each setting as kept, changed or reviewed.
Why third-party apps decide when the Nextcloud 35 upgrade happens
The app inventory often sets the Nextcloud 35 upgrade date more than the core upgrade does. Nextcloud's upgrade guidance tells administrators to disable third-party apps until they are confirmed compatible with the target version, so the Nextcloud 34 instance cannot be planned from the server version alone. Before choosing a window, list every app installed on the instance, including apps that are currently disabled, because users may expect them to return after the upgrade. For each app, record the installed version, the source it came from, the developer or team that owns it, and the users or processes that depend on it. This inventory is the input to every later decision in this section, and it is usually the slowest part of the plan to complete.
Classify each app into one of four groups. Core apps ship with the server and follow its release cycle, so the upgrade itself normally handles them. App store apps are installed from the Nextcloud app store and depend on a developer publishing a release that supports the target version. Custom apps are written or modified by your own team or a contractor, so compatibility depends on your code and someone must own the build and the test. Unmaintained apps are those whose developer has stopped releasing updates or no longer responds to issues. The group matters because each one has a different owner for the compatibility answer. Unmaintained and custom apps often have no owner at all until the upgrade assigns one, which is why this classification should be the first task on the project.
Check each non-core app against Nextcloud 35 with evidence, not assumption. For app store apps, read the Nextcloud version range listed for the app, review the developer's release notes, and confirm whether a release has been published that supports the target. For custom apps, run the code on a staging copy of the Nextcloud 35 build and review any deprecated server interfaces it calls. Record each result as compatible, compatible after an update, unknown or incompatible, and treat unknown as incompatible for planning purposes. Confirm every result on a staging instance restored from a recent production backup, because a listed version range does not prove that an app works with your database, PHP and web server versions. Check the Nextcloud 35 system requirements at the same time so the app results and the platform results are tested together.
For each app, decide whether to update, replace or remove it. Update when a supported release exists and users still need the function. Replace when a maintained alternative covers the same use, and test the data migration and user workflows before committing. Remove when the app is unmaintained, unused or duplicated by a core feature, but confirm with the data owner first, because removal can delete app data and settings. An app that is not compatible can also block the plan: if it stays enabled during the upgrade, it may stop the process or fail afterward. Build a disable step into the change plan before the backup, with a named owner for each app and a re-enable test for every app that passes staging. Ask your partner or internal team to document the decision, the sign-off and the rollback path for each app before the upgrade window is approved.
How the Nextcloud 34 to 35 upgrade runs step by step
This sequence moves a Nextcloud 34 instance to 35 in an order that keeps two rollback points open: a verified backup before any change, and a restore point after the core upgrade. Each step closes with a check, so the team can stop safely at any point and know the state of the server.
Confirm version 34 and current maintenance
Start by confirming the running Nextcloud version is 34 in the administration overview and in the version value in config.php. Apply every available maintenance release within the 34 line first, so the jump to 35 starts from the latest fixes. The administrator performing the change confirms that no update is pending and records the version string in the change ticket. Done when the server reports 34 with no pending updates and the change has an agreed starting point.
Check PHP, database and web server versions
Compare the PHP, database, operating system and web server versions on the server with the Nextcloud 35 system requirements. Nextcloud 35 recommends PHP 8.5 and still supports 8.3 and 8.4, so a server on PHP 8.2 must move first. Confirm the supported database version for your engine, and if you run MySQL 9, confirm the MD5 component it requires is installed and enabled as the upgrade guidance describes. Where any component is short, complete that upgrade as a separate change on the 34 line, with its own backup and rollback, before starting the core upgrade. Done when every component appears in the supported list and the change record shows the versions.
Take and verify a full backup
Back up the data directory, the config directory and the database together, using the method your install type documents, and include any custom app directories. Store the copy outside the server and confirm it can be read. Test the backup by restoring it to a separate host or staging copy, then check that files and database match. Record the time, the version and the backup location in the change record. Rollback point one: the server is still on 34, so rollback means restoring this verified backup to the original server or to a rebuilt 34 system with the same PHP, database and web server versions. Done when a test restore has succeeded.
Enable maintenance mode and disable third-party apps
Turn on maintenance mode so users cannot write during the change, and tell users the window through your usual channel. Then disable every third-party app from the app management page or with occ, so the core upgrade does not stop on incompatible code. Save the list of disabled apps with their current versions in the change record, since you will re-enable them later. Done when maintenance mode reports active, only apps that ship with core remain enabled, and the list is saved.
Run the core upgrade by the documented method
Upgrade the core from 34 to 35 using the method the upgrade manual documents for your install type, such as the occ command line for a manually installed server. Do not skip major versions, so this change moves the server only from 34 to 35. Watch the log output for errors and let the migrations finish before interrupting anything. If the instance runs in containers, follow the documented procedure for that deployment instead. Done when the upgrade command reports completion and the server reports version 35. Rollback point two: restore the verified backup from the earlier step, because the database migrations have run and cannot be assumed reversible.
Run post-upgrade and admin checks
Open the administration overview and work through every warning the upgrade raised, including security and setup warnings. Run the integrity check and review the log for new errors after the migrations. Sign in with a test account and confirm that file upload, download and sharing work. Keep maintenance mode on until these checks pass. Done when the overview shows no upgrade-related warnings, the integrity check is clean and the test account completes each action.
Re-enable apps one at a time
Re-enable the third-party apps from your saved list one at a time, starting with the apps your teams depend on most. Before enabling each app, confirm its vendor or the app store lists compatibility with Nextcloud 35. After enabling it, test its main function and read the log for errors before moving to the next app. If an app is not compatible, leave it disabled, record the reason and wait for an updated release before trying again. Done when every app on the list is either enabled and tested or left disabled with a recorded reason.
Return the instance to normal operation
Turn off maintenance mode, confirm that background jobs and cron run, and tell users the window has closed. Watch the log and resource use after the change, and keep the pre-upgrade backup until the change is formally closed. Complete the change record with the versions before and after, the state of each app and the backup reference. Done when users can sign in, background jobs run normally and the change is signed off with a complete record.
How to test and roll back a failed Nextcloud 35 upgrade
Run the Nextcloud 35 upgrade on a staging copy and test it against the functions your users depend on before any production change is scheduled. Start with login through the identity source you actually use. If you authenticate through the LDAP app against Active Directory, confirm that existing users and groups resolve, that group-based quotas and app access still apply, and that a disabled directory account is refused. If you use OpenID Connect or SAML, complete a full sign-in and sign-out through the identity provider. Then test file sync from desktop and mobile clients running the versions your users have installed, covering uploads, edits to large files, conflicts and selective sync.
Continue the test plan with sharing to internal users, groups, public links and guests, and confirm that external storage mounts still connect and list their contents. Check previews for images, documents and video, since preview generation often depends on tools installed on the server. Send a test message through the configured mail server and confirm that password reset and share notifications arrive. Verify that background jobs run on the scheduled cron method rather than on AJAX, because a stalled job rarely produces an error on screen. Write each check as a pass or fail line with the tester's name, so the results can be reviewed later.
Third-party apps are the most common source of failure after an upgrade, so re-enable them one at a time. Leave any app that is not confirmed compatible with Nextcloud 35 disabled, and check the vendor or app store listing before enabling it. After each app is enabled, rerun the functions it touches and record which app caused which failure. Decide before the upgrade starts what counts as a rollback trigger. Fix forward when the fault is isolated to one app or one configuration value and the fix has been tested on staging. Restore from backup when the upgrade stopped partway, when files or sync state are damaged, or when you cannot explain the fault within the window your change plan allows.
The backup must include the database and the data directory taken together, along with config/config.php. The database holds the file cache, share records and user metadata that point to files in the data directory, so restoring one without the other leaves entries for files that do not exist or files with no matching record. Before the production upgrade, restore a backup to a separate host, point it at a restored database, and confirm login, a sample of files and the version reported by occ status. Note how long the restore took so your change window is based on measured time. Record the exact versions before and after, including Nextcloud, PHP, the database engine and version, the web server, the operating system and every app, so a failed attempt can be reproduced. Confirm the patch-level versions against the release notes and your own environment.
What makes the Nextcloud 35 upgrade take longer
This table lists the inputs that most change the effort of a Nextcloud 34 to 35 upgrade and how to measure each one before work starts. Read each row as a question to answer about your current installation. Effort depends on these inputs together, so a written scope built from your own inventory is the only reliable way to size the work.
| Driver | Why it matters | How to scope it |
|---|---|---|
| Third-party apps | Each app must be confirmed compatible with version 35 and is disabled during the upgrade until cleared, so unmaintained apps add decisions and testing. | Export the installed app list with versions, then mark each app as supported, replaced or removed. |
| Custom code and integrations | Custom apps, hooks and login backends such as LDAP, SAML, OIDC or SSO, plus external storage mounts, need retesting on the new release. | List each integration with its owner and a test case, including login flows and external storage connections. |
| Data directory and database size | Backup and restore time grows with data volume, and every upgrade step starts with a backup. | Measure data directory and database size, then time a test restore on a copy of the environment. |
| PHP and database versions | Version 35 recommends PHP 8.5 and lists supported database versions. Current runtimes outside that list must move first, and Nextcloud does not allow skipping major releases. | Compare current PHP and database versions with the system requirements and plan any intermediate upgrade as its own step. |
| Operating system minimums | Web server and database hosts below the minimums in the system requirements may need a rebuild instead of an in-place change. | Check the operating system minimums in the Nextcloud 35 system requirements against each host and record the gaps. |
| Staging environment | Without a staging copy, compatibility tests run against production, and rollback depends entirely on the most recent backup. | Confirm whether a copy exists with matching versions, data and apps, and who maintains it. |
| Clustered or load-balanced setup | Node updates must be ordered and coordinated, and sessions, caches and shared storage must stay consistent during the change. | Document node count, shared storage, the cache layer, and the update order and downtime window for each node. |
Nextcloud 34 to 35 upgrade cost, time and what your team must provide
What does moving from Nextcloud 34 to 35 cost?
The cost follows from a written scope, and DeployOpen quotes from that scope. The main components are environment review and planning, building and validating a staging copy, app compatibility work and testing, the production cutover, and rollback preparation. Each is a line item you can ask about. The biggest variables are how many third-party apps your users depend on, how customized the server configuration is, and whether database or PHP changes are needed first. The upgrade itself is one-time work. Ongoing support, upgrades and testing are recurring and are priced separately as retainers. Ask for an itemized quote that states which tasks are fixed, which depend on app test results, and what is excluded, such as hardware, licenses or new database servers.
How long does a Nextcloud 34 to 35 upgrade take to complete?
Duration depends on the size and shape of your instance, so no fixed timeline applies to every deployment. The main drivers are the number of installed apps and how many of them need compatibility testing, the size of the data directory and database, whether the database engine or PHP version must change before the jump, and how many test cycles your app owners need. Schedule constraints matter too, including change windows and approval steps. Nextcloud 34 is supported until June 2027, so starting planning early leaves room for staging tests and a rollback rehearsal. Ask for a schedule in the written scope that lists the test gates and the approvals each gate requires.
Can our internal team run the Nextcloud upgrade without a partner?
Yes, if your team has the skills to run the full sequence and the rollback. That means administering Linux servers, PHP-FPM and the web server, managing the database and restoring it from backup, using Nextcloud's command-line tool for upgrade and maintenance tasks, and checking installed apps against the new release. Your team also needs a staging environment that matches production closely enough to trust the test results. Ask yourself whether someone has completed a restore test and a full rollback in the last cycle. If one of those is missing, the risk sits in the rollback path, not in the upgrade command itself.
What does DeployOpen need from our team for the upgrade?
The work needs access and decisions from your side, not only time. You will need administrative access to the server, database, hosting platform and DNS or load balancer as applicable, plus a staging copy of production data that you can use for testing. An app inventory listing every installed app, its version and its owner is essential, because each app needs a compatibility decision. You will also need current backup evidence, meaning a recent backup that someone has actually restored. Finally, name the approvers who can sign off the go and no-go decisions and the app owners who will test their workflows after the upgrade. Confirm these responsibilities in the written scope before work begins.
Does a Nextcloud Enterprise subscription change the 34 to 35 steps?
No. Enterprise tiers change support terms, not the upgrade procedure. Nextcloud's pricing page describes Standard with one year of maintenance, Premium with a maintenance lifecycle of five or more years and extended support hours, and Ultimate with support up to 24/7 and response times down to one hour. These terms affect who answers when something fails and how long a version receives maintenance. They do not replace the steps of taking a backup, moving through each required version, checking apps and databases, and testing rollback. Ask whether your subscription covers the upgrade work itself or only vendor support, and get that boundary in writing.
Must we upgrade from Nextcloud 33 to 34 before moving to 35?
Yes. Nextcloud does not allow skipping major releases, so an instance on 33 must move to 34 first and then to 35. Each step needs its own backup, compatibility checks for third-party apps, and verification before the next jump. Nextcloud 33 is supported until February 2027, so an instance still on 33 is approaching the end of its support window. Plan the two jumps as one program with separate go and no-go gates. Ask any partner to show how each intermediate version is tested and how rollback works at each stage, not only at the final target.
Which PHP, database and web server versions does Nextcloud 35 require?
Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18, PHP 8.5, and Apache 2.4 or nginx with php-fpm. It lists MariaDB 10.11 to 12.3, PostgreSQL 14 to 18, and MySQL 8.4 or 9.7 as supported, and PHP 8.3 and 8.4 as supported. Oracle Database is available only with an enterprise subscription. Your current PHP version may have been removed, so check it first. For MySQL 9, confirm whether the MD5 component must be installed and configured, and verify the details against the system requirements page for the exact minor versions you run. Record your current versions and compare each one against that page in your planning document.
What usually goes wrong during a Nextcloud major upgrade?
Most failures come from a small number of causes. Third-party apps that have not been confirmed compatible can block the upgrade or break features after it, which is why Nextcloud recommends disabling them until they are verified. PHP modules and database versions often lag behind the new requirements. Custom configuration files, reverse proxy rules and timeouts on large instances can also cause errors that appear only after cutover. The most serious problem is a backup that was never restored, so the rollback fails when it is needed. Ask for a documented rollback test, a list of disabled and re-enabled apps, and a post-upgrade verification checklist before the production change.
How DeployOpen scopes and delivers a Nextcloud upgrade
DeployOpen scopes the Nextcloud 34 to 35 upgrade as a written, fixed-scope engagement inside your own infrastructure. The work starts from your current PHP, database and operating system versions, your installed apps and the one-major-at-a-time rule, then moves through a tested path to Nextcloud 35. Ongoing support is available as a retainer after the upgrade.
How we scope
- The written scope lists every server, database, web server and PHP runtime in the 34 to 35 move.
- Compatibility review covers your installed apps, checking each for Nextcloud 35 support before any change is made.
- Scope fixes target database and PHP versions against Nextcloud 35 requirements, with open items listed for your confirmation.
How we build
- Build a staging copy with restored database and file data to rehearse the upgrade before production.
- Prepare the PHP, database and operating system changes first, in the order the one-major-at-a-time rule requires.
- Disable third-party apps, upgrade in stages, then re-enable each app only after its compatibility is confirmed.
How we hand over
- Take a verified backup before each upgrade step, and record how to restore it if a step fails.
- Documentation covers the final versions, app list, configuration changes and the rollback steps used in testing.
- Handover walks your team through the upgrade record, checks and open items before the engagement closes.
How we support
- Ongoing support is available as a retainer, covering upgrades, updates and continuous testing.
- Maintenance schedule follows Nextcloud's monthly maintenance releases, so your team knows which patches to plan for.
- Note Nextcloud 35 reaches end of life in September 2027, so plan the next upgrade in advance.
