I wanted to ask if anyone has experience with migrating from OwnCloud to Nextcloud. We are currently facing the challenge of having a server with over 100 active users who also use the OwnCloud Desktop app.
Our question is how to best handle this situation to ensure a smooth transition to Nextcloud. We are definitely considering running everything in a parallel environment, but the main challenge is how to manage the Desktop app during the migration.
I have been using the Owncloud client for Nextcloud on one computer for a long time (because the Nextcloud client no longer supports 32-bit). If you migrate/upgrading your existing Owncloud installation to Nextcloud in-place, it would be interesting to check whether the Owncloud client continues to run 1:1 with Nextcloud als new backend. If so, you would then have enough time to replace the clients with the new Nextcloud client.
But if you really have so many clients that this is an issue, I think the only way to go is to run a separate test run. That’s where you could test things like this.
Question is, can you ask the users to de-install the owncloud client and install the nextcloud one? Or should everything be automatic (perhaps with a script you can copy the configuration and you don’t need to configure the Nextcloud client)?
For the server, I don’t know if the migration paths are still tested and how reliable they are. I’d check with a test system that is similar to yours (or even a copy), how it works. And based on that, you can go through the issues, report them.
There is the web-migrator:
that hasn’t seen updates for a while.
But you are still on the php version of ownCloud I suppose?
Other way, less elegant, you could set up a new Nextcloud instance. That way, you run into less trouble. To link both setups, you can use federated sharing between the instances. If it is just for the raw data, you can move it to the new setup. However, if you have a lot of shares, shared links etc. such information would be lost.
Since we drop Debian Bullseye support in our project, which is the last version where ownCloud can even run (with native PHP 7.4), I was testing ownCloud 10 => Nextcloud 25 migration for our last remaining ownCloud users:
The source code however shows that only ownCloud 10.13 is possible without patching the code:
Now I wonder whether the docs are wrong, and some breaking changes have been applied to recent ownCloud subversions, or whether upgrade support until ownCloud 10.15 and even latest 10.16 can be patched inside without issues? I’d even open a PR to add this upstream.
Of course I was just testing it, and so far it looks fine.
Another minor issue was ownCloud’s 'apps_paths' array in config.php which contains a redundant path to the apps dir, but more problematic a non-existing /apps-external path by default, if any app from the market was installed.
Oh, the docs actually seem outdated or mix things up, since latest NC33 code still declares upgrade support from ownCloud, including from its latest v10.16:
Of course ownCloud and latest Nextcloud cannot run with the same PHP version, but since latest Nextcloud might include some additional migration steps for ownCloud 10.14 and above, it seems best to ignore this: upgrade PHP, then do the migration steps. I am testing this now as well.
EDIT: Sadly occ (upgrade) cannot run with an ownCloud 10.16 database:
EDIT2: This worked for me with some ownCloud 10.16 test instances, migration to NC32 directly:
mysql -e 'ALTER TABLE nextcloud.oc_appconfig ADD type INT UNSIGNED NOT NULL DEFAULT 2;'
mysql -e 'ALTER TABLE nextcloud.oc_appconfig ADD lazy SMALLINT UNSIGNED NOT NULL DEFAULT 0;'
mysql -e 'ALTER TABLE nextcloud.oc_preferences ADD lazy SMALLINT UNSIGNED NOT NULL DEFAULT 0;'
mysql -e 'ALTER TABLE nextcloud.oc_preferences ADD type SMALLINT UNSIGNED NOT NULL DEFAULT 0;'
mysql -e 'ALTER TABLE nextcloud.oc_preferences ADD flags INT UNSIGNED NOT NULL DEFAULT 0;'
mysql -e 'ALTER TABLE nextcloud.oc_preferences ADD indexed VARCHAR(64);'
occ upgrade # will fail
mysql -e 'ALTER TABLE nextcloud.oc_preferences DROP COLUMN lazy, DROP COLUMN type, DROP COLUMN flags, DROP COLUMN indexed;'
occ upgrade # will succeed without error
Creating the oc_appconfig columns is strictly needed for occ to run at all. It does not cause issues when creating them with correct types and defaults, the type migration is skipped, the lazy column is removed first, and re-added in the very next migration.
The oc_preferences columns are needed to prevent oc_accounts from somehow being removed. Before database migrations even start, occ upgrade throws an error about the missing columns when calling this code. But it continues (and finishes), which seems to lead to oc_accounts removal somehow, which I was able to replicate 2 times. Adding the 4 new columns prevents this, but causes the related later migration steps to fail, hence they need to be removed again.
When occ upgrade passed the first migration steps once, the missing oc_preferences columns do not throw errors and do not cause the oc_accounts table being removed.
The 2nd occ upgrade hence succeeds.
Looks fragile, so a backup and database dump is absolutely needed . But it worked for some test instances. We will offer this to our remaining ownCloud users, when they upgrade from Debian Bullseye to Bookworm, adding to real-world tests. Nothing to loose when a backup is there, and since ownCloud Infinite Scale does not support any direct ownCloud 10 (meta)data import, there is nothing else one can do with an ownCloud database.