I need some help migrating from Owncloud 10.12.2 to Nextcloud.
I tried upgrading to Nextcloud 25.0.9 or 26.0.4 but got the error message “Updates between multiple major versions and downgrades are unsupported”.
The migration manual only mentioned upgrades from owncloud 10.11.x to 25.0.x, does anybody know if there will an uprade path from 10.12.x?
I found follwing post Migrating from ownCloud to a NextCloud docker container: “Updates between multiple major versions and downgrades are unsupported” which edited the version tag to force the upgrade but breakes oauth2 integration.
Normally this should not be a problem for me, or does this break a basic function of Nextcloud?
It looks like the owncloud oauth2 migration may have been fixed recently anyhow (and made its way into NC25.0.8) via PR #38577
It looks like 10.11 migration support was added in #35471
For 10.12 a quick look shows some new db migrations (db changes) which are the biggies to look out for typically with OC->NC migrations. Below find the list and my comments on the probable impact of each on a migration.
^This adds a creation_time column to oc_accounts. It’ll probably just be ignored post migration so likely okay.
^This just adds an index. Probably fine.
^This adds/updates configuration parameters that NC should just ignore. Probably fine.
^This might require some special handling, but I think it’ll only require a light touch. The length of the components field in oc_calendars was increased from 20 to 255. This was done to accommodate an issue where it needed to be 21 characters. NC already uses a 64 character field. Probably best to manually ALTER this table field post-migration to match NC. I suspect from reading the associated issue and PR that 64 will still be more than enough.
Docker image comments
That said, while using the Docker image typically simplifies things, the official admin manual approach to an OC to NC migration is entirely built on a manual deploy. The Docker image also has additional version checks and they likely weren’t tested with an OC migration in mind. I skimmed that thread you linked and it looks interesting so no reason to not try that path if you wish, but putting that out there.
Hopefully it goes without saying that this all shouldn’t happen without good backups and recovery processes in place. Fortunately the migration can be tested offline in a test environment.
Hi @jtr ,
thank you for the detailed answer, you helped me a lot!
Little spoiler, i did the upgrade and it worked very well!
So here is a brief summery of what i did.
I Waited for NC Version 25.0.10, to get to oAuth2 fix
Start with the migration according to the NC migration documentation
before I executed die occ upgrade command, I change version.php (this will cause integrity errors which you can fix by undoing the changes after the migration)
'10.11' => true,
'10.12' => true,
execute occ upgrade without any problems
execute database fixes according to the NC migration documentation
Alter DB to utf8mb4_general_ci
ALTER DATABASE owncloudDB CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
edited OC cron to NC cron
be lucky new NC user!
First of all after the migration I upgraded to PHP 8.0
Next step will be a NC Upgrade to 26
According to the owncloud database scheme changes
new column creation_time for oc_accounts will be remove through the database migration process during upgrade
MariaDB [owncloudDB]> DESCRIBE oc_accounts;
| Field | Type | Null | Key | Default | Extra |
| uid | varchar(64) | NO | PRI | | |
| data | longtext | NO | | NULL | |
new index fs_parent_storage_size exists after the upgrade, but i also think that should not cause any problems
i do no see the configuration paramter after the migration, maybe because the old config value was NULL
char lenght for components column of oc_calendards table will automaticly altered through the migration routine and does not have to be altered afterwrads. I checkt the table content before and there were no values with more than 21 characters.
According to the issue report which cause the increase to 255 characters, the orginal size was 255, before it was reduce to 20. Perhaps therefore nextcloud had already the correct database migration routine.