How to migrate from ownCloud to Nextcloud without losing control of your files
The documented route from an ownCloud 10 server to Nextcloud is an in-place upgrade, with a full backup taken before each step and every third-party Market app disabled until its compatibility with the target release is confirmed. Nextcloud does not allow skipping major releases, so the server must move through each required major version in order. Your files, shares, users and app data stay on the server you already run, which keeps the data inside your infrastructure for the whole project. Before anything changes, record what the server holds today: the ownCloud version, the PHP and database versions, every installed Market app, the number of users, any group folders and any LDAP or Active Directory binding. That inventory is the basis for every decision that follows.
Effort depends on four things: how old the server is, how many Market apps it runs, how it authenticates users against a directory, and how many accounts and how much data it holds. An older installation with many apps and a directory binding needs more planning, more test runs and more sign-off points than a small server with a few well-understood apps. This page does not give a duration, because none can be stated responsibly without the inventory. When you ask a partner for a quote, ask for a written scope that names your exact starting version, the number of upgrade steps that version requires, the apps to be replaced, removed or confirmed, and the directory settings to verify after each step. Check the vendor's migration documentation for the steps that apply to your starting version before the scope is agreed.
Two other products carry the ownCloud name, and moving to either is not this route. ownCloud Server 11.0.0, often called Classic 11, was published on July 30, 2026, and it is deployed only with Docker, with the web server, PHP runtime and database managed inside ownCloud's images. ownCloud Infinite Scale (oCIS) is a separate Apache-2.0 platform written in Go, with its own storage, identity and client decisions. A move to Classic 11 or to oCIS is a separate project with its own design, its own testing and its own budget, and the upgrade steps described here do not apply to it. Confirm which product and version your current server runs from the installation itself before you plan any of the work that follows.
Keeping control of your files means deciding before the first upgrade who holds the backups, where they are stored and how a restore is proven. Take a full copy of the data directory and the database, confirm that it can be restored on a separate host, and keep it until the upgraded server has passed its post-upgrade checks. Record which Market apps were disabled, which were confirmed compatible and who made each call, so the decisions can be traced later. Agree in writing whether your team or the partner performs each step, and who signs off before the next major version is applied. Those decisions, made early, are what keep the migration in your hands from the first backup to the final check.
What maps from ownCloud 10 to Nextcloud and what needs a decision
This table maps the main ownCloud 10 features to their Nextcloud equivalents and notes which ones need a decision before cutover. Read each verification entry as the check to complete in a test instance before the production upgrade. The main takeaway: files and accounts usually carry over with planning, while Market apps, sharing links, external mounts and encryption settings need explicit checks.
| Area | Nextcloud equivalent or native capability | Migration note | Verification |
|---|---|---|---|
| Users and groups | Local accounts and groups, or LDAP and Active Directory users through the LDAP app | Decide which accounts stay local and which move to the directory before cutover. | Vendor docs cover LDAP; confirm group mapping in a test instance |
| Folders and files | Files app with WebDAV access for desktop and mobile clients | Check file counts, sizes and file names after the upgrade with a representative data set. | Confirm in a test instance using a copy of production data |
| Sharing links | Public link shares with password and expiry options in sharing settings | Share URLs and settings may change, so list critical links and verify each one after cutover. | Confirm each share type in a test instance |
| Quotas | Per-user and group storage quotas set in administration settings | Record existing quota values per user and reapply them so no account is blocked after import. | Confirm quota enforcement in a test instance |
| External storage mounts | External storage app for SMB, NFS, S3 and other supported backends | Retest each mount, credential and permission set, since backends and mount options need review. | Confirm each backend type in a test instance |
| Server-side encryption | Server-side encryption module, enabled and managed by the administrator | Decide whether encryption carries over, and plan key handling and recovery before enabling or changing it. | Check the encryption docs for the target version; confirm key recovery in a test |
| Versioning and trash | File versions and deleted-files trash in the Files app | Review version and trash retention settings, since expiry rules may differ from the source server. | Confirm retention behavior in a test instance |
| Calendars and contacts | Calendar and Contacts apps using CalDAV and CardDAV | Clients need new server URLs, and each client sync path should be tested before users switch. | Vendor docs cover the protocols; confirm client sync in a test |
| Market apps | No guaranteed one-to-one match; each app is checked in the Nextcloud app store | Do not assume equivalence. Confirm each app and its support for the chosen target major version, such as Nextcloud 34. | Check the app store and target version compatibility for each app |
Documented upgrade tools and paths for ownCloud sites
The tools for this migration fall into three groups: the in-place upgrade itself, the occ command line that runs each step, and the checks around it, including backups and app inventory. Each card covers one tool or check, and together they show the order in which your team works through the migration.
In-place upgrade with occ
The in-place path upgrades the existing ownCloud installation on the same server, so the data directory and database stay where they are. Nextcloud does not allow skipping major releases, so the site moves through each major version in order, with occ run after each step to finish the upgrade. Confirm the version map for your target release and the point where ownCloud access ends before you schedule any step.
Upgrade manual and system requirements
The Nextcloud upgrade manual is the reference for each step, and the system requirements page for the target version sets the supported PHP, database and web server combinations. For a Nextcloud 35 target, that page recommends PHP 8.5 with 8.3 and 8.4 also supported, and lists MariaDB 11.8 or PostgreSQL 18 as recommended databases. Check the requirements for each intermediate version as well, because PHP and database versions must be ready at every stage.
Backup and restore before each step
Nextcloud requires a backup before every upgrade. Back up the data directory, the database and the configuration file together, because restoring only one of them leaves the site in an inconsistent state. Test a restore on a copy of the server before the first upgrade, and keep each backup until the upgraded site has run stable for a period your team agrees with the business.
Disabling and re-enabling apps with occ
Third-party apps must stay disabled until their compatibility with the new version is confirmed. Use occ app:disable for each app before a step, then occ app:enable only after the vendor or your own testing confirms support. Run occ app:list before you begin to inventory every ownCloud Market app, and confirm the Nextcloud replacement or removal decision for each one in the migration plan.
ownCloud export or import utilities
Do not recommend an ownCloud-specific export or import utility until its current status is confirmed in the vendor's migration documentation. Such utilities change between releases, and a tool that worked for an earlier version may not cover yours. Ask the vendor which versions it supports, whether it carries shares, versions and metadata, and what it leaves behind. Record the answer in the plan with the date you checked it.
Import apps are for cloud sources
Nextcloud's import apps for Google, Dropbox and OneDrive connect to those cloud services as sources. They do not read an ownCloud server, so they are not a path for moving this site. Use them only when some users' files sit in those services and need to reach Nextcloud. Keep this distinction in the runbook so the team does not plan an import that cannot reach the ownCloud data.
Why the upgrade path is one major version at a time
Nextcloud does not allow skipping major releases, so an ownCloud 10 server cannot jump straight to the target version. The migration is a sequence of upgrades, one major version at a time, and the route has to be planned before anyone touches production. Confirm with the vendor and the documented upgrade route which ownCloud 10 release is the supported starting point, which PHP version that release runs, and which intermediate Nextcloud versions the documented path requires. Count the hops, then estimate the work for each one. Do not assume a shorter route exists because the data would fit.
Each hop is a separate change with its own rollback point. Before every upgrade, take a full backup of the data directory and the database, and test that a restore works before relying on it. Disable third-party apps until each one is confirmed compatible with the version you are moving to, and re-enable them only after the upgrade completes cleanly. Apps from the ownCloud Market are not carried over automatically, so record which ones are in use and check each for a Nextcloud equivalent or a compatible release. Keep a written log of each version, backup location, app state and test result so the team can see exactly where a failure occurred.
The target version controls the rest of the plan. Nextcloud 34 is supported until June 2027, Nextcloud 33 until February 2027, and Nextcloud 35 was released on 16 September 2026 with end of life in September 2027. Nextcloud 36 is scheduled for 17 February 2027. Those dates come from the release schedule and can change, so check them on the day you fix the target. Ask whether the cutover will finish comfortably before the chosen version leaves support. If it will not, plan a further upgrade, or choose a newer target that gives more support time after go-live.
Do not assume the PHP version that ended ownCloud access is still correct for Nextcloud. The requirements differ by release, and the system requirements page for the target version is the authority. For Nextcloud 35, the documented recommendation is PHP 8.5, with 8.3 and 8.4 also supported, but the version for each intermediate step may differ and may change before your cutover. Check the PHP, database and web server requirements for every hop, not only the final one, and include the runtime upgrades in the same change plan as the application upgrades.
How the migration sequence runs: inventory, pilot, parallel run and cutover
The sequence moves an ownCloud 10 server to Nextcloud in stages, so each stage proves the next one before any user depends on the new instance. It ends with a planned cutover, a verified new system of record, and an old server kept in a restorable state.
List apps, users, mounts and integrations
Your team and DeployOpen record every installed app, user and group source, external storage mount, sharing setting, scheduled job, and integration with directories, mail, scripts or systems that call the server API. Each item gets an owner and a decision: keep, replace with a Nextcloud app, or retire. Nextcloud asks administrators to disable third-party apps until they are confirmed compatible, so every ownCloud Market app is flagged for a compatibility check. The step closes with a signed-off inventory and a list of apps and integrations to test in the upgrade stage.
Restore a test copy from a verified backup
Take a fresh backup of the production instance that covers both the database and the data directory, then restore it into an isolated test environment. The test copy should not send email notifications or reach production storage or identity systems. Confirm the restore by logging in, opening a sample of files and comparing file counts with production. The output is a test instance with a known backup point, which serves as the reference for every later comparison.
Upgrade the test copy one major at a time
Upgrade the test copy through each intermediate major release in order, because Nextcloud does not allow skipping major releases. Take a backup before every step and confirm the PHP, database and web server versions required by each release, including the PHP upgrade that ends ownCloud access. After each major step, run the post-upgrade occ commands from the upgrade documentation, then test every app on the inventory list. Replace Market apps with Nextcloud equivalents where needed. The step closes when the instance runs the target version with no failed checks and each app has a passing result or a documented fix.
Pilot with a small group of users
Invite a small group of users who cover the main client types: desktop sync on Windows, macOS or Linux, the Android and iOS apps, a heavy sharer, and a user who works with external guests. Pilot users connect their clients to the test instance through a separate account or profile, so their production sync continues unchanged. They test login, sync of existing folders, sharing, and document access. The output is a written pilot report listing each defect, its owner, and either a fix or an accepted limitation.
Run the parallel period with users
For an agreed period, users work with both systems while ownCloud remains the system of record. Changes made in one system are not automatically visible in the other, so the parallel run defines which system is authoritative for each user group and how changes are recorded. Use this period to test sign-in through your identity provider, mobile app behavior on managed devices, and sharing with people inside and outside the organization. The step closes with written sign-off from the business owners of the affected teams.
Cut over with a final sync
Schedule a maintenance window and place the ownCloud server in maintenance mode so no new writes arrive. Run a final data and database sync, then verify file counts and, where your tooling supports it, checksums against the source. Change the DNS record or server address that users reach, and update the server address in desktop and mobile clients through managed configuration or your device management tooling. The output is production traffic on Nextcloud and a cutover record listing the checks run and who approved each one.
Check sharing links and external users
After cutover, test each category of sharing: internal shares, public links, password-protected links, shares to external email addresses, and guest accounts. Confirm with your migration plan whether each link type carries across, because links tied to the old hostname or to ownCloud-specific settings may need to be recreated. Tell affected owners what to expect before the cutover. The check passes when a sample of each type opens from outside your network and intended recipients reach their files. Keep a list of failed links with the fix for each.
Decommission the old server, keeping backups
After an agreed observation period, place the ownCloud server in read-only archive state, stop its services, and disable its scheduled jobs and user access. Keep the final backups and the cutover database dump under a retention rule set by your records policy. Test that one of these backups can be restored into an isolated environment before the original server is removed. The output is a decommission record stating what was kept, where it is stored, who can restore it, and when it will be deleted.
What drives the effort and cost of an ownCloud to Nextcloud move
This table lists the factors that change how much work an ownCloud 10 to Nextcloud move involves, with the direction each one pushes cost or duration and what to request in a quote. Use it to prepare your inventory before asking for a fixed-scope proposal. None of these factors produces a price on its own, and the written scope sets the final fee and timeline.
| Driver | Why it changes effort or cost | What to ask for in a quote |
|---|---|---|
| Upgrade steps on the documented route | Nextcloud does not allow skipping major releases, so each major version between your ownCloud 10 starting point and the target must be upgraded and tested in turn. More steps mean more upgrade cycles and more verification. | A list of each intermediate version, the backup and check points for each step, and how rollback is handled if a step fails. |
| Market apps and their state | Each ownCloud Market app must be confirmed compatible or replaced with a Nextcloud app. Unmaintained or heavily customized apps add investigation and rework, which raises effort. | An app inventory with versions, owners, whether each app is replaced, kept or retired, and the testing planned for each. |
| Directory or SSO integration | LDAP, Active Directory, OpenID Connect or SAML logins must be re-established and tested against Nextcloud's documented authentication backends. Complex group mappings and multiple directories add effort. | The authentication design, the directories and identity providers in scope, and the user login tests included. |
| Database engine and size | The database engine and version determine the supported target configuration, and a larger database lengthens backup, migration and verification time. Oracle Database requires an enterprise subscription for Nextcloud 35. | Confirmation of the current engine and version, database size, the target engine, and the backup and restore test included. |
| Total data volume and file count | Large volumes and high file counts lengthen data-related steps such as file scans, checksums and post-upgrade file checks, and they increase the time needed for backup and restore. | Total storage size, file count, the file-integrity checks planned, and the time window assumed for the cutover. |
| External storage mounts | Each external storage mount has its own credentials, paths and behavior after the move, and some may need reconfiguration or testing separately. | A list of all external mounts, their backend types, and the reconfiguration and test steps for each. |
| Number of users and groups | More accounts and groups increase the volume of permission checks, sharing validation and user communication. Large group structures also need careful mapping. | User and group counts, sharing patterns, and the validation sample agreed for acceptance. |
| Customizations | Custom code, themes, hooks or scripts written for ownCloud may not run on Nextcloud and need redesign or removal, which is often the least predictable cost. | A list of custom code and configuration, the replacement approach for each item, and who approves the changes. |
| Office editor integrations | Collaborative editing through Collabora Online, ONLYOFFICE or Microsoft Office Online Server requires the connector to be reconfigured and tested with the new server. | The editor product, hosting location, connector versions and the document editing tests included. |
| Test and parallel-run window | Testing with real user workflows and a parallel run before cutover add time, and the length depends on how many users and integrations are validated. | The test plan, acceptance criteria, the parallel-run period you expect, and the rollback plan if acceptance is not met. |
What to run after the upgrade: occ checks and app replacement
The upgrade is not finished when the login page loads. Once the in-place path to Nextcloud 34 completes, the team confirms the instance with occ before users return. Start by checking the installed version and overall status, then run the integrity check for core files and the maintenance and repair steps that the upgrade manual describes for the target version. Record every warning in the output. A working login page can hide a file hash mismatch, a missing database index or a configuration value carried over from ownCloud that Nextcloud no longer reads. Confirm the exact command names, options and order in the Nextcloud 34 admin manual, because they can change between major versions. Keep the output with the change record so the next administrator and any auditor can see what was checked and when.
ownCloud Market apps do not carry over automatically, so the app list needs its own workstream. Before the upgrade, build an inventory from the ownCloud server: app name, installed version, business owner, and the users or workflows that depend on each app. For every app, record one of three outcomes. It may have a Nextcloud app store equivalent, it may need a planned workaround such as a script, a connector or a documented manual step, or it may be retired after the business owner signs off. For each candidate in the Nextcloud app store, confirm that it supports the target version, check the maintainer and license, and note whether it is still maintained. The upgrade documentation calls for third-party apps to stay disabled until each one is confirmed compatible, so treat that confirmation as a gate for every app on the list.
Re-enable apps one at a time and test each before enabling the next. After enabling an app, watch the admin overview and the server log for new errors, then run the test set for that app. Test what the app actually touches: the files or metadata it reads and writes, sharing and permission behavior, notifications, calls to external services, and whether its settings survived the upgrade. For example, an illustrative external storage app should be checked by signing in as a test user, opening a folder with known contents and confirming the mount resolves and the files list correctly. Record the result per app. If an app corrupts data or blocks login, disable it and keep the rest of the cutover moving. The backup taken before the upgrade is the restore point for that situation, so confirm it can be restored before the cutover date.
Finish with caches and background jobs, which are easy to overlook because nothing fails loudly. Confirm that the caching backend and memory cache settings match the target configuration in the manual, since values from the ownCloud installation may not apply. Check that background jobs run from system cron rather than AJAX, because email notifications, share expiry, file scanning and app tasks depend on that schedule. Use the admin overview to confirm the last background job run is recent, and run a test that should fire on schedule, such as a share expiry or a notification to a test account. Ask your internal team or implementation partner to write each check into the cutover runbook with a named owner and a pass or fail record. Plan the next major upgrade early, since Nextcloud 34 is supported until June 2027.
What usually goes wrong in an ownCloud to Nextcloud migration
Most ownCloud to Nextcloud migrations fail at the edges: a backup nobody restored, an app that blocks the upgrade, or a share link that changed meaning. The six risks below connect because each is cheaper to catch on a staging copy and in a parallel run with named test users than during cutover. Each card names the check that prevents it.
Backups, rollback and decommission
Teams often take a backup before upgrading but never restore it, so the first real test happens during an incident. Nextcloud's upgrade guidance requires a backup before every upgrade, but a backup proves little until it has been restored to a separate server and checked for file counts, shares and logins. Write the rollback plan before cutover: who decides to revert, which backup is restored, and how users are told. Set the decommission date in writing too, because an old ownCloud server left running keeps accepting logins and writes to data users have already moved.
Version jumps and unsupported stacks
Nextcloud does not allow skipping major releases, so the upgrade must pass through each intermediate version the upgrade documentation names. Check the PHP and database versions at every step against the system requirements for that release, not only the final target. For Nextcloud 35, the requirements list PHP 8.5 with 8.3 and 8.4 supported, MariaDB 11.8 or PostgreSQL 18 recommended, and MariaDB 10.11 to 12.3 or PostgreSQL 14 to 18 supported. Confirm that your current stack can reach each step before scheduling any work.
Third-party apps breaking upgrades
Apps installed from the ownCloud Market do not carry over automatically, and an app that is incompatible with the target release can block or break an upgrade. Nextcloud's guidance is to disable third-party apps until each one is confirmed compatible. Build a pre-upgrade app inventory with name, version, source, business owner and whether a Nextcloud app store equivalent exists. Mark each app as replace, rebuild or retire, then test the survivors on a staging copy before cutover.
Sharing links and external users
Public share links, group shares and guest accounts can look intact after migration while behaving differently for recipients. Verify expiry dates, passwords and edit permissions on a sample of links, then confirm that each external collaborator can reach the files they were given. Run a parallel test with named users who hold each type of share, including at least one external guest, and record what they see on both servers. Ask the business which shared folders support critical workflows, because broken links surface first there.
Directory login changes at cutover
If users sign in through LDAP or Active Directory on ownCloud, the Nextcloud LDAP app must be configured to match their accounts, group filters and attribute mappings. A mismatch can create duplicate accounts or lock out users whose files are tied to the old identity. Document the current directory settings, confirm how existing usernames map to directory accounts, and test sign-in with accounts from each group. If OpenID Connect or SAML is the planned login method, treat it as a separate change with its own test users.
Client sync conflicts at cutover
Desktop and mobile clients keep local sync databases that point to the old server. When the server address changes or users reconnect, clients may re-upload files, duplicate them or create conflict copies if edits happened on both sides during the switch. Freeze writes on the old server for the cutover window, instruct users to sign out and reconnect with the new address, and review conflict copies created in the first days. Pilot with named test users and their own clients first, and record which client versions behave differently.
Questions buyers ask before moving from ownCloud to Nextcloud
Can our own team run the ownCloud to Nextcloud upgrade without a partner?
Often yes, if your staff already run PHP applications, web servers and databases in production and can give the work dedicated time. Nextcloud documents an in-place upgrade path, but it is a sequence of steps, not one command. Nextcloud does not allow skipping major releases, so the team must move one major version at a time, back up before each step, and disable third-party apps until each one is confirmed compatible. Teams without that experience often bring in a partner for the app inventory, a rehearsal on a copy of production and the cutover plan. Decide by asking who will own each step, who will test, and who will sign off at the end.
What drives the cost of moving from ownCloud to Nextcloud?
The main cost is skilled time, split between discovery, build, upgrade steps, testing, cutover and documentation. Scope drives it most: the number of major versions to pass through, the PHP and database versions you run today, the number of users and the volume of data, how many Market apps you use, and how users sign in today through LDAP, Active Directory, OpenID Connect or SAML. Some costs are one-time, such as the migration project itself. Others recur, such as hosting, maintenance and any Nextcloud Enterprise subscription you choose. Ask for a quote that prices each phase separately and states which costs recur.
How long does an ownCloud to Nextcloud migration take, and what changes it?
No fixed duration applies to every installation, so treat any timeline as provisional until a rehearsal is complete. Duration depends on scope: how many major steps the version path requires, how much data and how many files the upgrades must process, how many Market apps need replacing, how complex the identity integration is, and how long user acceptance testing takes. Your environment also matters, including server capacity, backup speed and the maintenance window your users accept. A rehearsal on a copy of production gives the most reliable timing for your data. Ask any provider to base the schedule on the rehearsal results and to list the assumptions behind each phase.
What does the migration need from our staff?
The work needs named people more than it needs hours from everyone. Assign a project owner who can make scope and cutover decisions, a technical owner who can access the servers, and a backup owner who can confirm backups are complete and that a restore has been tested. Identify test users across departments and roles who will check files, shares, calendars and apps before and after cutover. If you use LDAP or Active Directory, you need a directory administrator who can create or approve a bind account and confirm group membership. Also plan for DNS, TLS certificate and change approval contacts.
Is ownCloud Infinite Scale a migration path to Nextcloud?
No. ownCloud Infinite Scale (oCIS) is a separate platform licensed under Apache-2.0 and written in Go, and it is not a documented route into Nextcloud. The in-place path discussed for ownCloud environments applies to the classic ownCloud server line, and the classic ownCloud 11 server is deployed only with Docker. If your current system is oCIS, moving to Nextcloud is a different project. It would involve exporting data from oCIS, replacing its clients and sharing behavior, and rebuilding identity and storage integration. Confirm which ownCloud product you run before you compare any plan or quote.
What happens to our ownCloud Market apps after the move?
Market apps do not carry over automatically, so each one needs a decision. Start by listing every installed app, its version, whether it is actively maintained, and which users depend on it. For each app, check whether Nextcloud's app store offers an equivalent, whether a built-in feature covers the need, or whether the function must be rebuilt or retired. Nextcloud's upgrade guidance advises disabling third-party apps until each one is confirmed compatible with the target version, so plan how each app will be tested before the cutover. Ask your provider to deliver the app inventory and a keep, replace or retire decision for every app as part of the written scope.
Do we need Nextcloud Enterprise to complete the move?
Enterprise is mainly a support and lifecycle decision, not a technical prerequisite that the move itself requires. The community edition is open source under AGPL-3.0, and the upgrade steps are documented for it. Nextcloud's pricing page lists Enterprise tiers with a 100-user minimum, with list prices starting at 71.29 euros per user per year for Standard, 104.99 euros for Premium and 204.75 euros for Ultimate, and lower rates from 200 users. Premium adds a maintenance lifecycle of five years or more and clustered instance support, and Ultimate adds support up to 24/7 with response times down to one hour. Compare these against your support hours, risk tolerance and lifecycle needs, and confirm the choice with Nextcloud for your target release.
What should a written quote for this migration include?
A useful quote lists the scope, the assumptions it depends on, and the deliverables. Scope should name the source and target versions, the upgrade steps, the user count, the data volume, the apps in use and the identity integration. Assumptions should cover your environment, access to servers and directories, test user availability and the maintenance window. Deliverables usually include a rehearsal report, a rollback plan, a cutover runbook, post-upgrade checks and admin documentation. The quote should also state client responsibilities, acceptance criteria, exclusions, change control, and what support follows cutover. Separate one-time project fees from recurring hosting, maintenance and any Nextcloud subscription. DeployOpen's engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing before work starts.
How DeployOpen scopes, delivers and supports an ownCloud to Nextcloud migration
DeployOpen plans and carries out ownCloud to Nextcloud migrations inside your own infrastructure, following the documented in-place upgrade path and the one-major-version-at-a-time rule. Work starts from a written scope that names the ownCloud version, target Nextcloud release, databases and apps in use.
How we scope
- Confirm the current ownCloud 10 server version, PHP runtime, database and web server before any upgrade step is planned.
- Inventory third-party ownCloud Market apps and map each to a Nextcloud replacement or a decision to drop it.
- Agree in writing the Nextcloud target version, the upgrade steps in order, the backup approach and the post-upgrade occ tasks included.
How we build
- Build a staging copy of the ownCloud instance and rehearse each major version step before touching production.
- Test PHP, database and web server compatibility for each intermediate release, since Nextcloud does not allow skipping major releases.
- Document the occ commands run after each upgrade, along with the apps disabled and re-enabled and the results of each check.
How we hand over
- Hand over a runbook covering the backup and restore steps, the exact upgrade sequence and the rollback point for each stage.
- Record the final configuration, installed app list, replacement app decisions and open items in documentation your team keeps.
- Walk your administrators through the production checks and the cutover, with the results recorded against the agreed scope.
How we support
- Ongoing support, upgrades and testing are available as a retainer after handover, if your team wants that cover.
- Plan the next Nextcloud upgrade against the published release schedule so each major step remains one version at a time.
- Review third-party app compatibility before each upgrade and update the runbook when apps or requirements change.
