What an Umbraco 7 to 13 Migration Actually Costs
April 14, 2026
Moving from Umbraco 7 to Umbraco 13 is a rebuild, not an upgrade. Content migrates with tooling; the site itself is reconstructed on the new platform. Any estimate built on upgrade assumptions will be wrong by a large factor.
Umbraco 7 reached end of life in September 2023. Organizations still running it are accumulating unpatched security exposure, and hosting and support options have narrowed.
Why the work is a rebuild
Three discontinuities between the platforms, each of which independently prevents a direct upgrade path.
- Umbraco 8 replaced the core. Document types, templates, and content structure from version 7 do not carry forward directly. The content model is reconstructed on the target platform, and content is then migrated into it.
- The framework changed. Umbraco 7 runs on .NET Framework; Umbraco 13 runs on modern .NET. Any custom server-side code is subject to the same constraints as any other .NET Framework migration, including package compatibility and the loss of
System.Web. - The package ecosystem did not carry over. Packages that were standard in Umbraco 7 (Archetype, Vorto, and the various grid and forms tools) have no direct equivalents. Each becomes a decision: replace with a modern equivalent, rebuild the functionality, or change the editorial approach.
In practice: templates are rewritten, package integrations are replaced or rebuilt, and custom code written against the Umbraco 7 API is rewritten against a different API.
A vendor describing this as a straightforward upgrade has either not performed one or is estimating from an earlier version of the platform. Obtain a written assessment before committing to a budget or a date.
Cost drivers, in order of impact
Custom development against Umbraco 7 APIs. The largest variable. Custom data types, custom back-office sections, event handlers, surface controllers, and anything touching the content service directly is rewritten. Inventory this first; the count of files referencing Umbraco namespaces is a usable initial proxy.
Third-party package replacement. Some packages have modern equivalents with comparable functionality. Others require rebuilding the capability, and a complex package with no successor can dominate the project scope. This inventory belongs in the first week of assessment, not in the build phase.
Content model complexity. A brochure site with a handful of document types and straightforward templates is materially cheaper than one with custom grid editors, nested content, member portals, or commerce. Document type count is a reasonable proxy, with nesting depth as a second factor.
Content volume. Migrating thousands of nodes requires tooling plus validation. The migration is automatable; verifying that complex or nested content arrived intact is not, and it takes time proportional to the model's complexity rather than to node count.
Design scope. A straight port of the existing design to new templates costs front-end time. A redesign executed concurrently adds a parallel project, and combining them makes it harder to isolate the cause of any post-launch problem.
Cost ranges
These assume a team with direct experience in both Umbraco 7 and modern Umbraco. A team learning the platform during the migration will take longer and will discover the platform incompatibilities mid-project.
- Small site. Under 20 document types, simple templates, minimal custom code, no member functionality: $15,000–$30,000
- Medium site. 20 to 50 document types, custom features, package dependencies, basic member functionality: $35,000–$75,000
- Large or complex site. Extensive custom development, member portals, commerce, many package dependencies, high content volume: $80,000 and up, with integration complexity the dominant variable above that floor
Evaluating proposals
Treat quotes materially below these ranges as an indicator that the platform discontinuity has not been priced. These migrations are consistently underscoped by teams that have not completed one, because the incompatibilities are not visible from the outside.
Three questions that separate experience from estimation:
- How is document type migration handled? A specific answer describes rebuilding the model on the target and migrating content into it. A vague answer describes an upgrade path.
- How are custom development rewrites approached? The answer should reference an inventory step producing a per-item disposition.
- What does content validation look like after migration? The answer should describe a verification method for nested and complex content, not a spot check.
The specificity of the answers is the signal. Vendors who have done this describe a sequence; vendors who have not describe an outcome.
Interim risk reduction
For organizations not ready to start, the objective is reducing exposure while planning proceeds.
- Place the site behind a web application firewall if it is not already
- Monitor for published vulnerabilities in Umbraco 7 and its dependency tree, and accept that no patches are coming
- Restrict back-office access to known networks
- Stop investing in new features on a platform scheduled for replacement
- Set a planning date, not just an intention
Emergency migrations triggered by a security incident cost more, take longer, and produce worse outcomes than planned ones, because the sequencing and the deadline are both set externally.
Working through a problem like this?
Describe the system and where it's stuck. I'll tell you what the work actually involves.
Get in touch