Hi Zsolt,
I tried to reproduce this with an old CMS 11 database (version 7060). With UpdateDatabaseSchema = true, CMS 13 migrated it successfully to version 21004 and created tblApplication.
I then restored the same CMS 11 database and tried the explicit migration using dotnet-episerver update-database. It failed because dbo.tblApplication did not exist, and the database remained at version 7060.
So I can reproduce the difference you described: automatic migration works, while the explicit CLI migration does not. It may be worth raising this with Optimizely Support to confirm the officially supported explicit migration path for CMS 11 → CMS 13, or whether this is an issue with the current migration tooling.
Hi Mardy,
Thanks for your confirmation, I will contact Optimizely Support.
Zsolt
Hi,
Using CMS self-hosted, trying to update database from CMS 11 to CMS 13.
Runtime database user has no admin permissions to database, so was always using Export-EPiUpdates / epideploy.exe to export sql scripts needed to update the CMS database when updating Optimizely, then execute those scripts with admin user.
Meaning DataAccessOption.UpdateDatabaseSchema is false in our setup in CMS 13.
In case of CMS 13 I could not get any of those export tools correctly working.
Also tried with automatic migration (UpdateDatabaseSchema = true) was working as expected.
Tried to manually gather the neccessary scripts as I found no current documentation on this topic, so I tried to reverse engineer it and found inconsistencies.
Latest episerver.cms.core Nuget Package 13.1.3 contains only some of the latest scripts (from 20.0.0), which is not enough for a migration.
Latest episerver.cms.core Nuget Package 12.23.3 contains only scripts up to 12.23.4.sql, which is not enough to start CMS 13 scripts on.
I found an embedded zip in episerver.data.dll, which is used for automatic migration (UpdateDatabaseSchema is true), but which does not contain the following scripts, which could be found in episerver.cms.core 12.23.3:
12.21.6
12.21.7
12.21.8
12.22.5
12.22.7
12.22.8
12.22.9
12.23.0
12.23.1
12.23.2
12.23.3
12.23.4
Some of these "extra" scripts are redundant, but some are not, for instance function StringSplit is created only here. In the database I migrated automatically, the function is missing, so it seems automatic migration also has issues.
Does someone has experience with official way of explicit migration?
Thanks,
Zsolt