For this Umbraco migration, the database route was the better choice. uSync can be useful in the right project, but this website had too much history inside Umbraco to treat the upgrade as an export and import task.
The old Umbraco 7 site had years of content, media, document types, data types, templates, redirects, back office settings, and editor habits. Rebuilding all of that by hand would have added time and created too many chances for small differences between the old site and the upgraded one.
The route followed was:
7.x to 7.15.10 to 8.5.5 to 8.18.5 to 10.0.0 to 10.8.11 to 13.x
That line looks tidy. The work behind it is in the checks between each version.
Step 1: Upgrade Umbraco 7 to 7.15.10
The first step was to bring the existing Umbraco 7 site to 7.15.10.
Before the upgrade, Recycle Bin data was removed. Separate backups were taken for the database, media, code, configuration, and release process. Package versions and custom changes were also recorded, because older CMS projects often hide important details in places nobody has touched for years.
After the upgrade, the back office was tested through normal editor use. Login, content loading, media, templates, page rendering, forms, and publishing all had to work properly before the site went near Umbraco 8.
Step 2: Run health checks before Umbraco 8
The next step was to prepare the site for Umbraco 8.5.5.
The PreMigrationHealthChecks-master package was installed in Umbraco 7, and the checks were run through Health Check → Check All Groups. Any issues found at this stage were fixed before the upgrade continued.
Older property editors need special attention here. MediaPicker, MultiNodeTreePicker, and similar data types can make the migration look worse than it is. A field may appear empty in the CMS after the upgrade, while the migrated JSON still carries the value.
That is the moment to inspect the database rather than rebuild content by hand. In some cases, custom recovery logic is needed so the newer editor can read and show the old value again.
The umbracoLanguage table also needs a check before the move to Umbraco 8. In some projects, the ID type must be changed from smallint to int to avoid upgrade errors.
Step 3: Upgrade from 7.15.10 to 8.5.5
Once the health checks and editor fixes were complete, the site moved from 7.15.10 to 8.5.5.
This stage needs careful testing because CMS behaviour changes between versions. Content types, media fields, templates, forms, redirects, language content, and custom editor logic all need to be opened and tested inside the CMS.
If a field appears empty, check the database before treating the content as lost. Older picker values may be present, but stored in a format the newer editor reads differently.
Step 4: Upgrade from 8.5.5 to 8.18.5
The next upgrade took the site from 8.5.5 to 8.18.5.
Before this step, the umbracoServer table may need the column isMaster BIT NOT NULL. In older projects, that small database change can save a very long afternoon.
After the upgrade, logs, content trees, media links, templates, forms, redirects, search, packages, and editor tasks were checked again. Every fix was recorded, because the second dry run should be boring. Boring is good in migration work.
Step 5: Upgrade from 8.18.5 to 10.0.0
The move from 8.18.5 to 10.0.0 changed the nature of the work.
At this point, the upgrade was no longer only about the database. Custom code, controllers, services, routing, authentication, search, package replacements, and release scripts all needed review against the newer Umbraco version.
This is also the stage where the website should be tested as a working product, not only as a CMS that opens without errors.
Step 6: Upgrade from 10.0.0 to 10.8.11
After the move to Umbraco 10, the project was brought to 10.8.11 before going further.
Pages had to render correctly. Forms had to submit. Redirects had to resolve. Media links had to work. Permissions had to match editor roles. Integrations had to send the expected data to the expected place.
This test round gives the project a stronger base before the final move to Umbraco 13.
Step 7: Upgrade from 10.8.11 to Umbraco 13
The final step in this route was 10.8.11 to Umbraco 13, followed by the latest available patch in the Umbraco 13 line.
By this stage, the project had a useful upgrade record. The team knew which packages worked, which ones needed replacement, which fields needed recovery, which templates needed code changes, and which integrations needed extra testing.
That record is the value of a database-led Umbraco migration. It gives the business evidence before the next version choice is made. For some older Umbraco websites, version 13 can be a sensible landing point while the move to Umbraco 17 is planned. For others, it can be a tested step before continuing sooner.
Key checks for this migration path
Run health checks before upgrading from Umbraco 7 to Umbraco 8.
Upgrade old data types before migration, especially MediaPicker, MultiNodeTreePicker, and similar picker fields.
Inspect the database before treating empty fields as lost content.
Test the back office after every upgrade, including content, media, templates, forms, redirects, search, permissions, and integrations.
Keep notes on backups, scripts, package changes, recovery work, and test results for every version.
Need a second view on your Umbraco migration route?
If your website is still on Umbraco 7, 8, or 10, Phases can review the current CMS version, database condition, packages, custom code, editor workflows, redirects, forms, integrations, and hosting model. The output is a migration route that shows whether Umbraco 13 is a sensible stage, whether the site can move towards Umbraco 17, and which risks need testing before production work begins.
You can share the current Umbraco version, hosting details, package list, and any known pain points. A senior Umbraco engineer can then assess the route and explain what should be checked before a budget, timeline, or release plan is agreed.