This Umbraco 7 to 13 migration used a database-led approach, with validation between each version stage. This article records the route followed, the legacy data issues encountered, and the checks used before moving forward.
The website contained years of content, media, document types, data types, templates and custom functionality. For this project, the team chose to work through the database migration route. The approach for another website should be assessed against its content structures, packages and custom code.
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.
Before using this migration route
The versions listed here record the route used for this project. Confirm suitable patch versions, package compatibility and database prerequisites for your own implementation.
Database migration is one part of the work. Templates, custom code, media files and configuration also need migration or adaptation.
Umbraco 13 reaches end of life on 14 December 2026. If it forms part of your migration route, plan the next supported stage alongside it. Our Umbraco 13 extended support article explains XLTS where additional time is needed.
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.
See the official Umbraco 7-to-8 content migration guidance for prerequisites, property-editor limitations and known migration issues.
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.
The official Umbraco 8-to-10 migration guidance explains the separation between content migration, file migration and custom-code changes.
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
Keep the migration record alongside the application: package decisions, recovered fields, code changes and test results help the team assess the next stage.
If the route continues beyond version 13, read our Umbraco 13 to 17 upgrade planning article for the architectural and backoffice considerations involved.
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.
Discuss your Umbraco migration route
The right route depends on your current version, database, packages, custom functionality and hosting.
Explore Phases’ Umbraco upgrade services to discuss your existing website and the work needed to move forward. Share your current version, hosting details, package list and known issues to give the technical review a useful starting point.
