Upgrading Nextcloud across several major versions

Nextcloud does not allow skipping major releases, so an administrator on an old installation has to move through each major version in order. Start by recording the installed version and the target version, then list every major release between them. That list becomes the plan's backbone, because the PHP, database and app decisions for each step depend on which release is in front of you. Treat the number of hops as a planning input that is known before the first change, not a surprise found during the work. Any partner quoting this work should be able to show the version-by-version sequence in the written scope.

The reason is mechanical. Each major release ships database schema changes and upgrade steps written against the release before it. When the upgrade runs, those steps are applied in sequence, and each one assumes the state that the previous release would have left behind. If you jump from an older release straight to a newer one, the steps for the versions in between never run. The database and the application code then describe different systems, and the recovery is difficult because you are repairing a partly migrated schema with code that expects a state it never reached. Check the upgrade manual for each step rather than relying on memory of earlier releases.

Each intermediate release is also a rollback point, and that is the practical reason for the one-hop rule. A backup taken before a given major upgrade captures the database, the data directory and the configuration as they were on that version. If a step fails, you restore that backup, fix the blocker and retry the step, instead of trying to reverse schema changes by hand. Back up before every upgrade, not only before the first one, and test a restore on a separate system so you know the backup is usable. Record which backup belongs to which version so a restore never mixes data from one release with code from another.

Third-party apps need the same discipline. Disable each app until its maintainer confirms it works with the release you are moving to, because apps depend on internal interfaces that can change between majors. Keep an inventory with each app's version, source, maintainer and compatibility status for every target version. Re-enable apps one at a time after each step and confirm they work before moving on. Also check the support window: each major release is supported for about one year through monthly maintenance releases, so a deployment several majors behind may already be outside support. Confirm current dates on the maintenance and release schedule before fixing the target.

Plan the hop list before any server is touched. Nextcloud does not allow skipping major releases, so the route from your current version to the target is a sequence of majors, each upgraded in its own cycle with a backup taken first. Start by reading the release schedule and listing every major between your installed version and the target, with the end-of-life date for each one. Nextcloud publishes a new major every four months and supports each for one year through monthly maintenance releases, so an old installation can easily require several steps. Record the PHP, database and web server requirements of each intermediate version as well, because those change from one major to the next and often determine the order of the work.

The target should be chosen with end-of-life dates in view. According to the published schedule, Nextcloud 33 is supported until February 2027, Nextcloud 34 until June 2027, and Nextcloud 35, released on 16 September 2026, reaches end of life in September 2027. Nextcloud 36 is scheduled for 17 February 2027. A target that is already close to its end-of-life date forces another full upgrade cycle within months, so count the time between your planned cutover and the next end-of-life date. Ask whether the upgrade window, app testing and sign-off will finish well before that date. Confirm each date on the current schedule, because the schedule can change after publication.

Support terms differ between the community release and the Nextcloud Enterprise tiers, and that difference affects how many hops you need to plan. The community release receives monthly maintenance for each major for one year, so a community target is only as long-lived as its own support window. Nextcloud Enterprise is sold in Standard, Premium and Ultimate tiers with a 100-user minimum. According to Nextcloud's pricing page, Standard includes one year of maintenance. Premium adds a maintenance lifecycle of five or more years, extended support hours and clustered instance support. Ultimate adds support up to 24/7 with response times down to one hour. If your organization needs a maintenance lifecycle longer than one year, that points toward Premium, so the decision should be made before the target is fixed. Confirm current tier terms with Nextcloud before deciding, because terms and minimums can change.

Turn these decisions into a written hop list that your change board can approve. For each step, record the source version, the target version, the end-of-life date, the required PHP and database versions, the web server, and the third-party apps that must be confirmed before the step runs. Take a restore point before each hop, not only before the first one. Assign owners for the tier decision, for app compatibility confirmation, and for signing off each intermediate version before the next one starts. Where a tier question remains open, put it to Nextcloud in writing and keep the plan flexible enough to add a hop if a dependency blocks an intermediate version.

Each hop needs its own test run, executed on a staging copy before production and repeated after the upgrade, using the same accounts and data set each time. The set should cover login through the identity method you chose, whether that is local accounts, LDAP and Active Directory through the LDAP app, or OpenID Connect or SAML backends. It should also cover file sync from desktop and mobile clients, public and password-protected sharing links, calendar and contacts, external storage mounts, and background jobs, which you can confirm are running in the admin overview. Finally, test every app your organization depends on, following the workflow a real user would take. Write the expected result for each case before the hop starts, so pass or fail is decided in advance rather than under pressure.

Rollback means restoring the backup taken immediately before the failed hop, with files and database restored together from that same point in time. Put the previous PHP and web server configuration back at the same time, because the application code and the runtime it expects must match the restored data. The most damaging mistake is a partial restore, such as putting back the data directory while keeping the current database, or the reverse. File records, share entries and file cache rows then point to objects that no longer exist, and the errors can surface days later as missing files or broken shares. Treat the pair as one unit in your runbook. Confirm restore timing in your own environment by rehearsing a full restore on a copy, because duration depends on your data volume, storage and database engine, and no general figure applies.

Before each hop, decide the go or no-go conditions and who makes the call. Confirm that third-party apps are disabled, since Nextcloud requires this until each app is confirmed compatible with the target release, and re-enable them only after the core checks pass. Check the target release's system requirements for PHP, database and web server versions, and confirm that your desktop and mobile client versions still work against the new server, using the vendor's compatibility notes for each client. Make the rollback cutoff explicit: once users have written new data on the upgraded instance, returning to the old backup discards that work, so agree the cutoff with the business owner before the window opens. Record every failed test with its reproduction steps.

After the last hop, keep the backups from each step until the final release is verified in production and your retention policy allows deletion. Repeat the full test set on the final version as well, because an issue introduced in an earlier hop can appear only after later apps and settings are applied. Ask any partner or internal team quoting this work to show the test scripts, the rollback runbook and the rehearsal results they will deliver, and to state which tests are included in the fixed scope. Confirm with your own team who can execute a restore out of hours, how long they expect it to take in your environment, and whether that matches the outage window agreed with the business.