chore(admin): update ownCloud migration guide

[MichaIng]

nextcloud/server#59677 fixes direct migration from ownCloud to latest Nextcloud.

It does not change something about the fact that latest ownCloud 10 does not support any PHP version supported by Nextcloud. But while keeping PHP 7.4 during the migration to Nextcloud 25 makes it easier to revert to ownCloud in case of an issue, that path requires manually patching version.php, a lot of major version upgrades, and intermediate PHP upgrade steps. Overall the efforts are a lot higher than migration directly to latest Nextcloud, and upgrade PHP only once prior to that.

Another reason to prefer direct migration to latest Nextcloud is, that Nextcloud 25 migrations are not maintained anymore. There is hence a chance that some recent ownCloud 10 version introduces a change that causes a major or subtil issue during the migration, that is fixed only in Nextcloud versions which are not EOL.

The migration steps have been adjusted to reflect the direct migration path to the upcoming Nextcloud 34.0.0.

The table itself, to in case list different migration paths for different ownCloud versions, has been left in place, including the optional/conditional migration steps to further upgrade Nextcloud and in case PHP afterwards. However, to reduce maintenance efforts and simplify/clarify things, I'd vote for removing support for migration to any older Nextcloud versions entirely, and remove the target version and post-migration upgrade steps from the docs. Once latest Nextcloud removes support for migrations from ownCloud 10.13.x, it is probably better to simply remove this migration path from the docs, and require admins to upgrade ownCloud first. IMO, keeping support for (and documenting) migrations to Nextcloud versions, which themselves are not supported, and hence do not get possibly needed fixes for migration scripts and version.php, does not make sense.

Let me know if you agree to the last point, then I'll adjust the commit accordingly.

☑️ Resolves

• Fix #…

🖼️ Screenshots

Before:

After:

Would it make sense to split each ownCloud-Nextcloud version pair into their own table row, when keeping the table at all?

✅ Checklist

• I have built let github-actions build the documentation locally and reviewed the output (😅)
• Screenshots are included for visual changes
• I have not moved or renamed pages (or added a redirect if I did)
• I have run codespell or similar and addressed any spelling issues

[github-actions]

📖 Documentation Preview

🔍 Open preview →

📄 1 changed documentation page

• admin_manual/maintenance/migrating_owncloud.rst

Last updated: Sat, 30 May 2026 17:04:43 GMT

[skjnldsv]

Looks good, I'll wait for the other to check as well! Thanks !! :hug:

[blizzz]

Looks good and makes sense. I do not have experience from a recent oc upgrade though.

35.0.0 would be correct for the master branch, as 34.0.0 was branched out to stable34.

[skjnldsv]

Looks good and makes sense. I do not have experience from a recent oc upgrade though.

35.0.0 would be correct for the master branch, as 34.0.0 was branched out to stable34.

I think not, we cannot vauht for 35 compatibility YET, this is not bound to our stable relzase process. I think it should stay 34 int his doc

[MichaIng]

What do you think about my last point/suggestion to not define individual Nextcloud versions at all, but suggest to use the latest (at least a still supported one) instead, removing all the subsequent "upgrade major Nextcloud/PHP versions" steps? So there wouldn't be a need to update the table, latest Nextcloud is assumed to support all documented ownCloud origin versions. And once support for e.g. ownCloud 10.13 is dropped, it is removed from the table.

[skjnldsv]

not define individual Nextcloud versions at all, but suggest to use the latest (at least a still supported one) instead

Feels error-prone. We've had many of our releases needing work to make the oc-nc migration viable. We're very far from what owncloud is nowadays. I'm not sure we should take the "try and find out" approach, especially with migrations and potential data loss if admin don't do things carefully. 🤔

[MichaIng]

Of course it makes sense to keep testing it with major Nextcloud releases, and as well with new ownCloud releases, like if there will be a v10.17.y. And if migration from v10.13 breaks at some point a way that is not seen worth the efforts to fix, support can be removed via version.php. What I basically would aim to avoid is to support migrations to unsupported/EOL Nextcloud versions, for which things cannot be guaranteed well either, fixes cannot be shipped anymore etc. I mean the potential risk of data loss is on both ends, backups inevitable.

I am just thinking about setting up a GitHub Actions workflow with sets up the supported ownCloud versions, maybe with some additional data and apps via occ, does a number of checks via occ and curl, then follows the documented steps to migrate to HEAD branch version of Nextcloud, and repeats the checks 😄. Should not be that hard, given that can copy&paste setup steps from DietPi. And maybe there is even a reasonable way to pipe the result though some existing Nextcloud CI workflows?