If your website runs on Umbraco 7 or 8, moving to Umbraco 17 involves more than installing a newer version.
The underlying technology has changed, the content management interface has been rebuilt, and older packages and content structures need careful assessment. Your existing content can often be retained, but the application around it needs adapting or rebuilding.
That makes this a migration project: preserving what matters, moving it into a supported platform and proving that everything works before launch.
Understanding that distinction helps you set a realistic budget, agree the right scope and avoid surprises during delivery.
Why is the move so significant?
There are three substantial changes between Umbraco 7 or 8 and Umbraco 17.
1. The underlying .NET platform has changed
Umbraco 7 and 8 belong to the older ASP.NET and .NET Framework generation. Umbraco 17 runs on modern .NET 10.
This affects application code, configuration, integrations and the way the website runs. Existing templates and custom functionality need review and reimplementation against the newer framework.
Umbraco’s own migration documentation makes this distinction clear: retaining content does not automatically migrate the code that renders pages or powers custom features. See Umbraco’s guidance on moving from version 8.
2. The backoffice has been rebuilt
The backoffice is the interface your team uses to create, edit and publish content.
Umbraco introduced a new backoffice architecture in version 14, replacing AngularJS with Web Components. Custom dashboards, property editors and other extensions built for the older interface need assessment and may require rebuilding.
This work can represent a substantial part of the migration for websites with heavily customised editing tools. Umbraco’s overview explains the backoffice changes.
3. Content structures need migrating
Moving content involves more than copying text and images.
Your current website may store page layouts in legacy editors, nested content structures or package-specific fields. Those structures need mapping to compatible editors in the destination.
Migration tools can help transform older structures, including moving legacy Grid content into Block Grid and Nested Content into Block List. Custom data may require additional migration logic. See Umbraco Deploy’s content migration documentation.
The objective is to preserve the meaning, relationships and usability of the content, including how editors maintain it after launch.
What can carry over?
A migration does not mean discarding everything you already have. Start by establishing which assets remain useful and how they can be retained.
| Existing asset | What to expect |
|---|---|
| Page copy and structured content | Usually candidates for migration, with mapping and validation |
| Images and documents | Often transferable, with checks on references, links and metadata |
| Website design | Can often be retained, although templates need adapting or rebuilding |
| URLs and SEO metadata | Should be explicitly mapped and preserved wherever practical |
| Content models | May be retained, adapted or replaced depending on editor compatibility |
| Custom application code | Requires review and reimplementation for the destination |
| Backoffice extensions | Older extensions may need rebuilding for the new architecture |
| Third-party packages | Need compatible versions, replacements or removal |
| Forms, member accounts and submissions | Require a specific migration and testing plan |
A useful distinction is between retaining a feature and retaining its implementation.
For example, your customer portal may still need the same account management journey. The code, authentication and integrations supporting that journey may need substantial changes.
Similarly, keeping your existing visual design can reduce design scope without removing the engineering work needed to render it on the new platform.
Do we have to redesign the website?
A redesign is optional.
If your existing design, navigation and content still meet user needs, the migration can focus on preserving that experience while replacing the underlying implementation.
If the website already has problems with accessibility, publishing or customer journeys, the migration may be a sensible time to address them.
Agree those decisions early. Adding a redesign midway through a technical migration changes the scope, testing requirements and delivery schedule.
A focused migration and a broader website redevelopment are both valid projects. They need different budgets and plans.
What does the migration process involve?
Assess the existing website
The first stage establishes what is actually running.
This includes reviewing the code, packages, content models, media, integrations, hosting and deployment process. It should also identify business-critical journeys and any functionality that lacks documentation.
Access to the source code, database, media and relevant systems is essential for a reliable assessment.
The output should be a recommended route, an initial scope, known dependencies and a delivery estimate.
Prove the migration approach
Before committing to the full migration, test representative content and functionality.
Choose examples that expose complexity: a page with legacy layout content, a multilingual section, a form with custom processing or a journey connected to another system.
This helps establish whether the proposed approach preserves the data and behaviour you need.
The technical route may involve supported intermediate migration steps or importing content into a fresh implementation. It should be selected around the actual website, rather than assumed from the starting version alone.
Build and migrate
The team then prepares the destination application, reimplements templates and functionality, and develops the required content transformations.
Migration scripts should be repeatable. Content will often continue changing on the existing website while development takes place, so a single early copy is unlikely to be enough.
This stage also covers compatible packages, integrations, hosting configuration and deployment.
Test with developers and content editors
Technical checks should be followed by testing with the people who use the platform.
Can editors find, update, preview and publish content? Do forms reach the correct destination? Do search, permissions and integrations behave as expected?
Content checks should verify relationships, formatting and links, alongside page counts. A successful import does not prove that every page is correct.
Rehearse and launch
Before launch, agree the final content transfer, any editing freeze, backups and recovery steps.
Check URLs, redirects, metadata, analytics and critical journeys. After release, monitor errors, form submissions and connected systems.
Launch should follow a rehearsed process with clear responsibilities.
How long should we allow?
For initial planning, think in weeks or months. The following are illustrative planning allowances, rather than delivery commitments:
| Example scope | Initial planning allowance |
|---|---|
| Compact website, retained design, standard content and few dependencies | Around 6 to 10 weeks |
| Larger website with custom editors, several integrations and more complex content | Around 10 to 16 weeks |
| Complex platform with membership, commerce, multiple languages or a substantial redesign | Four to six months or more |
An assessment may place your project outside these ranges.
Elapsed time also depends on your organisation. Access delays, content decisions, third-party suppliers and approval cycles can extend the programme even when development is progressing.
A realistic plan includes discovery, migration rehearsals, testing, editor training and launch preparation.
Can we keep our search rankings and URLs?
Preserving search visibility should be part of the migration scope from the start.
Record existing URLs, metadata, canonical tags and important landing pages. Preserve addresses wherever practical and implement relevant permanent redirects when they change.
Check internal links, sitemaps, robots directives and analytics before launch. Afterwards, monitor crawl errors, indexing and organic landing-page performance.
No migration can guarantee unchanged rankings. A documented URL and content plan helps control avoidable disruption.
Why move to Umbraco 17?
Umbraco 17 is a long-term support release, with end-of-life scheduled for 27 November 2028.
By comparison, standard support for Umbraco 7 ended on 30 September 2023, and Umbraco 8 reached end-of-life on 24 February 2025. See Umbraco’s official support schedule.
Moving to a supported release provides a maintained platform for future development. It also creates an opportunity to simplify content management and remove dependencies that no longer serve the business.
The benefits depend on the quality of the implementation and the maintenance that follows.
How Absurd can help
At Absurd, we start by assessing your existing website, including its code, content and integrations. We establish what can be retained, what needs rebuilding and which migration route makes sense.
As an Umbraco Gold Partner, we help organisations plan and deliver the move through implementation, content migration, testing and launch.