Migrate from Sitecore to Umbraco

How to migrate from Sitecore to Umbraco without losing content or control

A .NET team leaving Sitecore usually does so because a renewal, a SaaS-only forward path or a data center requirement has made the current estate hard to keep. The good news is that content and media move through documented paths, while renderings, forms, personalization and marketing data have to be rebuilt in Umbraco. Plan the project around that split from day one, because the content transfer is the smaller part of the work. Sitecore's own migration guide makes the same point for its SaaS pathway: xDB data, email marketing content and personalization do not migrate and must be rebuilt. The work is usually run by internal .NET developers who already know C#, the Razor views and the Sitecore solution structure, supported by an implementation partner for the parts the team has not done before. Your developers can map templates to document types, rebuild renderings as views or headless components and own the hosting. A partner typically adds migration tooling experience, hardening and cutover support. Confirm in writing who owns the item-to-content mapping, the media rules and the test sign-off, since those decisions are where projects drift. Effort and risk depend mostly on how many custom renderings, pipelines and Sitecore-specific services the estate contains, and on how much personalization and form logic the business relies on. Those are the items to inventory first. Before committing, check which Umbraco version you target and its support dates in the Umbraco end-of-service policy, and confirm whether licensed add-ons such as Umbraco Forms or Umbraco Engage are needed for your forms and personalization needs.

Which Sitecore capabilities map cleanly to Umbraco and which need rework

This table compares the main Sitecore XP and XM capabilities with their Umbraco equivalents and marks each as clean, needs rework or gap. Read the rows as a planning aid: clean means a direct structural match, needs rework means the logic or front end must be rebuilt, and gap means no equivalent ships in Umbraco. Forms and personalization carry per-domain licensing, so price them with the domain count in mind.

Sitecore capability	Umbraco equivalent	Migration status
Templates	Document types and compositions, defined in code and synced with Umbraco Deploy on Umbraco Cloud	Clean: fields map well, but inheritance and shared fields need a deliberate composition design
Items and content tree	Content nodes in the Umbraco content tree, with content and structure exported as data	Needs rework: Sitecore item IDs, versions and language variants must be re-keyed and checked against the new tree
Media library	Umbraco media library with media types and folder structure	Clean: files move, but metadata, alt text and reference links require scripted mapping and verification
MVC renderings and layouts	Razor views and partial views, or a headless frontend consuming the Content Delivery API	Needs rework: presentation logic, placeholders and rendering parameters are rebuilt, not ported
Sitecore Forms	Umbraco Forms, a licensed add-on that runs unrestricted locally but needs a valid license on a public domain	Needs rework: form definitions are rebuilt; licenses are sold per domain and cover subdomains, so confirm domain count
xDB personalization and analytics	Umbraco Engage, a licensed marketing add-on for personalization, analytics and A/B testing	Gap in data: xDB contacts and interaction history do not migrate; rules are rebuilt, and Engage also needs per-domain licensing
Roles, users and workflows	Umbraco users, user groups and permissions, configured in the back office	Needs rework: Sitecore roles are not carried over automatically; map each permission set deliberately

What Sitecore data carries over and what stays behind

Sitecore's own migration guide says the SitecoreAI path does not carry xDB data, email marketing content or personalization, and those must be rebuilt. The same limits apply when you move to Umbraco, so treat them as the baseline for scoping. Content Serialization is the part that does move. The Sitecore CLI serializes items to YAML, and in the scope of this migration that means your content tree, templates, renderings, media item references, and the roles and users you choose to include. Those YAML files are the input for mapping templates to Umbraco document types and content to Umbraco nodes, and for deciding which module files you actually need. Confirm with your own instance which modules and item paths are serialized, because a partial tree produces a partial import.

Analytics, contact profiles and personalization rules have no export path through serialization. Before you scope anything, ask your Sitecore administrators for a list of active personalization rules, marketing definitions, forms, and any email campaigns that still hold content, then record which ones are live and which are dormant. On the Umbraco side, page templates, Razor views or headless components replace renderings, and the Content Delivery API exposes content as JSON only after you enable it in configuration. Forms and personalization need their own decisions. Umbraco Forms and Umbraco Engage are licensed add-ons, so check their current license terms against your public domains and environments before you assume they replace Sitecore Forms or XP personalization. The migration cost therefore depends heavily on how much behavioral data and rule logic the estate contains, which is an inventory question to answer first.

Which data and integrations to inventory and rebuild

Sitecore estates rarely fail on content volume alone. The risk sits in the parts that do not move cleanly: the content model, media references, identities, forms, search and the systems that receive data from the site. Inventory each of these before you pick a migration method, and treat the list as the basis for a fixed scope.

Items and templates as the content model

Sitecore templates, fields and standard values define what editors can author, so they become the first thing to map. Export the serialized item tree and list every template, its base templates and its field types, then decide which become Umbraco document types, element types and compositions. Check which fields hold rich text, links or multilist references, because those need explicit conversion rules. Confirm with your team which items are content and which are site configuration, since only content should be imported as content.

Media files and their references

Media library items are stored as files and metadata, and content often points to them by identifier rather than path. Inventory every media folder, file type and size, and find each place a page, component or rich text field references an asset. Plan how references are rewritten so links do not break after the move. Ask your Sitecore administrator which media items are restricted or generated on demand, because those need their own handling.

Users and roles to recreate

Sitecore users, roles and security rules should not be imported into Umbraco. Instead, define the editor and approver groups you need in Umbraco's user and group model and assign permissions from your identity provider or a documented process. Record which Sitecore roles grant publishing, workflow approval or access to specific content trees, because those rules must be rebuilt deliberately. Confirm with your security team how accounts are provisioned and removed.

Forms and their submissions

Sitecore Forms definitions, field rules and stored submissions behave differently from Umbraco Forms. Inventory each live form, its validation, notification emails and downstream destinations, and decide which historic submissions must be retained and for how long. Umbraco Forms requires a valid license on a public domain, so confirm licensing for every production and test domain before rebuilding. Treat submission data as personal data and agree on its storage location in writing.

Search and indexes

Sitecore search indexes are generated from the item tree and must be rebuilt against the new content model. List each index, its scope and any custom crawlers or computed fields. Decide whether Umbraco's search stack, a self-hosted engine such as Meilisearch or OpenSearch, or a database query meets the requirement, and confirm the chosen engine's capabilities in your own environment before committing to it.

External integrations such as CRM and analytics

CRM connectors, analytics tags, marketing triggers and custom API calls usually sit in Sitecore code or configuration, and each one has its own contract. Inventory every outbound and inbound integration, the data it sends, its authentication method and its owner. Confirm each vendor's current API terms and data processing agreement in your own environment, since these are not covered by the CMS migration itself. Plan parallel running for integrations that receive form or personalization data.

Migration sequence from inventory to Sitecore decommission

This sequence moves one Sitecore estate to Umbraco in controlled stages, with each stage producing a written artifact that the next stage depends on. It ends with Sitecore switched off only after content, traffic and sign-off have been verified in the new platform.

Inventory templates, renderings and integrations
Your architects and Sitecore developers list every template, rendering, placeholder, module, pipeline processor, Forms definition, personalization rule and external integration that the sites depend on. Owners are assigned for each site and integration. The output is a field-to-property map that pairs each Sitecore template field with a planned Umbraco document type property, plus a list of components marked as rebuild, retire or keep. The step is done when the business owners have signed off that list.
Build a pilot on one site section
Choose one site section with representative templates, media and at least one form, and build it in Umbraco with document types, Razor views or a headless frontend on the Content Delivery API. Confirm whether the Content Delivery API must be enabled in configuration and whether member authentication is needed for protected pages. Test editor workflows with the content team, not only developers. The output is a working pilot with a written list of gaps that the wider build must close, and it is done when editors can complete their normal tasks in it.
Import content and media with validation
Export content from Sitecore using the serialization and content paths your team has confirmed, then transform items into Umbraco content nodes and move media into the Umbraco media library. Run imports in a non-production environment first and repeat them until the results are stable. Validate counts by site, language and content type, check broken internal links and confirm that every media file resolves. The output is a reconciliation report listing source items, imported nodes, skipped items and reasons for each exception, and the step closes when the business owners accept the exceptions.
Rebuild forms, personalization and marketing data
Rebuild each Sitecore Forms definition with Umbraco Forms or another chosen tool, and confirm the licensing model for your public domains before go-live. Map Sitecore personalization rules and analytics to Umbraco Engage or other tools only after confirming what each one covers. Note that xDB contacts, analytics history and personalization rules do not carry over to SitecoreAI, and assume the same for any export you plan to make. The output is a signed list of replacement tools with owners, licenses and data retention decisions.
Run both systems in parallel
Keep Sitecore serving production traffic while Umbraco serves a defined subset of traffic or a staging copy for internal and partner review. Compare page rendering, search indexing, redirects, form submissions and tracking tags between the two. Log each defect with an owner and a closure date. The output is a parallel-run log with defect status, and the step is done when no open defects block cutover.
Freeze content and cut over
Agree a content freeze window with editors, then run a final delta import, repeat the validation from the earlier import step and confirm DNS, CDN, certificates and redirects in the Umbraco hosting target, whether that is your own infrastructure or Umbraco Cloud. Record the rollback procedure before the switch. The output is a signed-off content freeze window and a cutover checklist with timestamps, and the step closes when the business owner confirms the live site.
Decommission Sitecore after verification
Keep Sitecore in read-only mode for an agreed retention period so that audit questions and missing content can still be answered. Then archive databases, serialized items, media and configuration under your records policy, revoke Sitecore access and retire the servers and licenses. Confirm with your compliance lead which evidence must be kept. The output is a decommission record listing archives, access revocations and license terminations, and the step is complete when that record is signed by the owner of the Sitecore platform.

Self-hosting Umbraco or moving to Umbraco Cloud

Self-hosting keeps the Umbraco application, database and media on servers, virtual machines or containers that your organization runs. Umbraco is MIT licensed, so the CMS itself carries no license fee, but your teams take on the platform duties that a managed service would otherwise handle. Current Umbraco CMS documentation requires .NET 10.0 or higher and supports SQLite or SQL Server, so the database choice is one of the first decisions to make.

Runtime and patching: Your team installs and patches the .NET runtime, the operating system, the web server and the Umbraco packages.
Database: SQL Server suits production estates with existing database operations, while SQLite fits small installations; confirm which your database team will back up and restore.
Media and file storage: Uploaded media lives on the server or in storage you configure, so backup and disaster recovery plans must cover it.
Environments: You build the Development, Staging and Production pipeline yourself, including how content and structure move between them.
Hosting controls: Network placement, TLS certificates, logging and access control sit inside your own security program.

Before committing, confirm with your infrastructure team that your data center or cloud account meets the .NET 10 and database requirements and that someone owns each of these duties after go-live.

How Umbraco Forms and Engage licensing changes the rebuild

The licensing terms for Umbraco Forms and Umbraco Engage shape how you rebuild Sitecore Forms and personalization, because both add-ons are free to run locally but need a license once they serve a public domain. Umbraco Forms runs unrestricted on a local machine, and on a public domain it requires a valid license. Licenses are sold per domain, cover subdomains, include two development or testing domains, and apply to one license per installation. If your Sitecore estate runs forms on several sites, count each public domain separately before you assume one purchase covers them all.

Umbraco Engage follows a similar pattern but with different domain allowances. Its license covers one production domain plus up to two development or testing domains, and Engage is the component that carries the personalized experiences, analytics, A/B testing and targeted campaigns you are replacing from Sitecore XP. Map each Sitecore site to a planned public domain, then mark which add-on each site needs. Ask Umbraco to confirm current pricing, renewal terms and whether a license count changes for staging and preview environments, because the figures in product documentation can change between releases.

Before you budget, write the domain inventory into the migration scope: production, subdomains, staging, and any preview hosts that the Content Delivery API serves. Ask your Umbraco partner or reseller to quote each add-on against that list, and confirm how the licenses renew and whether they follow the domain or the installation if you move between self-hosting and Umbraco Cloud. Treat these terms as current only until you verify them directly with Umbraco.

What usually goes wrong in a Sitecore to Umbraco move

Most Sitecore to Umbraco projects stall in the same few places: data that was assumed to move, renderings that were underestimated, and inheritance and media that were never mapped. The cards below cover the risks that recur and the checks that catch them before cutover.

Assuming personalization data migrates

Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, which must be rebuilt. Teams planning an Umbraco move often assume the same rules, audiences or visitor history will carry over with the content. Inventory every personalization rule, segment and campaign in the XP instance and assign each one a rebuild owner, whether that is Umbraco Engage, a separate analytics tool or a retired feature. Confirm the scope in writing before the first content import.

Underestimating rendering rework

Sitecore renderings, placeholders and MVC views do not convert to Umbraco views automatically. Each rendering needs a decision: rebuild as a Razor view and partial, or move the frontend to a headless application that reads the Content Delivery API. Count renderings and components early, classify them by complexity and include the front-end effort in the plan. Teams that scope only the content import usually discover this gap during user acceptance testing.

Unmapped template inheritance

Sitecore templates often inherit from base templates, and standard values set defaults that editors rely on. Umbraco document types support compositions, but a flat copy of inherited fields creates duplicate properties and broken editor experiences. Export the template tree, draw the inheritance graph and map each base template to a composition before creating document types. Confirm the property alias and data type for every field, because aliases become the keys that the Content Delivery API returns.

Media reference breakage

Sitecore media items are referenced by GUID inside rich text fields, link fields and renderings. Moving the files without rewriting those references leaves images and downloads broken on pages that look fine in the editor. Build a reference map from Sitecore media IDs to Umbraco media items, rewrite rich text links during import and run a crawl of the published site against the old URLs. Ask the implementation partner to show the crawl report before cutover.

Content Delivery API left disabled or exposing drafts

The Umbraco Content Delivery API is opt-in and must be enabled in configuration. When a headless frontend is built on it, teams sometimes enable it without reviewing preview access. Per the Umbraco documentation, unpublished content is returned for preview only with an API key, and protected content is served only when member authentication is enabled. Review the configuration in each environment, restrict preview keys to the editing team and test that draft pages cannot be read anonymously.

Cutover without a content freeze

Editors who keep publishing in Sitecore during the final import create content that exists only in the old system. Without a defined freeze window, the last import misses those changes and the team reconciles them by hand after launch. Agree a freeze date, run at least one full dry-run import with a delta comparison, and document who may publish during the window. Confirm the rollback path and keep the Sitecore environment readable until the new site has been stable for an agreed period.

Questions teams ask before moving from Sitecore to Umbraco

What drives the cost of moving from Sitecore to Umbraco?

The cost is driven by the size and shape of the Sitecore estate, not by the Umbraco license, which is free under the MIT license. The main cost components are the people who rebuild the site (internal developers, an implementation partner or both), hosting, the migration of templates, items and media, the rebuild of renderings, and the replacement of Sitecore Forms and personalization. Costs rise with the number of sites, languages, custom modules and integrations. Ask any partner for a fixed-scope quote that separates one-time migration work from recurring hosting, support and upgrades, and that states which paid Umbraco add-ons are included. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

How long does a Sitecore to Umbraco migration take?

No duration can be given without a scope review, because the timeline depends on how many sites, page types, languages and integrations the Sitecore estate contains. Ask for a timeline in the written scope, and check that it covers content and media migration, frontend rebuild, testing, cutover and a stabilization period. Your own Sitecore content inventory, template count and module list are the inputs that make an estimate reliable. Umbraco's own lifecycle dates should also shape the schedule, as described in the lifecycle question below.

What does the internal team need to provide for the migration?

The internal team needs to supply knowledge of the Sitecore content model, the business owners who approve content and editorial workflows, access to the Sitecore environments and media library, and developers who can review .NET code. Someone must also own the decisions on personalization, forms and analytics, which do not move automatically. Editors need time for content validation after import. The more of this knowledge is documented before the project starts, the less time the external team spends rediscovering it.

Can our own developers migrate from Sitecore to Umbraco without a partner?

Yes, a capable .NET team can do the migration in-house, because Umbraco is a C# CMS and uses familiar .NET tooling. The work requires experience with ASP.NET Core, the Umbraco document type model, the Content Delivery API if you choose a headless frontend, and production operations. Teams usually underestimate the content and media transfer, the rebuild of Sitecore-specific renderings and the security review. A partner is most useful for a fixed-scope assessment, for hardening and for handover documentation. Decide early which parts your team will own after go-live.

What happens to xDB, personalization and Sitecore Forms during the move?

Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, which must be rebuilt, so the same planning applies to an Umbraco move. Umbraco Engage provides personalization, analytics, A/B testing and targeted campaigns, but running it on a public domain requires a valid license covering one production domain and up to two development or testing domains. Umbraco Forms runs unrestricted locally but needs a valid license on a public domain, sold per domain, and includes two development or testing domains with one license per installation. Confirm these licensing terms with Umbraco before you budget for them. Existing xDB contact data should be exported and reviewed for retention and consent before any decision to keep or drop it.

How do Umbraco lifecycle dates affect the migration plan?

Umbraco 17 is the LTS release published on November 27, 2025, with end of life on November 27, 2028, end of Extended Long-Term Support on November 27, 2030 and end of service on Umbraco Cloud on November 27, 2031. Umbraco 13 reaches end of life on December 14, 2026, so new projects should target Umbraco 17 and existing Umbraco 13 sites need a planned upgrade. Umbraco's end-of-service policy also says hosting continues on Umbraco Cloud through Extended Long-Term Support, a phase of up to 24 months, and that projects can then run on dedicated resources for 12 months after XLTS ends. Plan the cutover and the post-launch support window around these dates.

Should we self-host Umbraco or use Umbraco Cloud?

Self-hosting gives you control over the data center or cloud account, network boundaries and backups, and it requires your own operations team, patching and monitoring. Umbraco Cloud is a fully managed service on Microsoft Azure with automatic backups, a global CDN, HTTPS and Development, Staging and Live environments, synchronized with Umbraco Deploy. Choose self-hosting when residency or network rules require it, and Umbraco Cloud when your team prefers a managed platform on Azure. Either way, the Umbraco project code is the same MIT-licensed code, so you can move between the two models with a planned process. Confirm hosting, backup and recovery terms directly with Umbraco or your host.

What are the Umbraco system requirements for a self-hosted build?

Current Umbraco CMS documentation requires .NET 10.0 or higher and supports installation with a SQLite or SQL Server database. Plan your server, database and .NET runtime upgrade paths before development starts, and confirm that your security tooling, monitoring and build pipelines support .NET 10. The Content Delivery API is opt-in and must be enabled in configuration, and it returns unpublished content only for preview with an API key, so review these settings as part of your security design. Check the official requirements page for the current list of supported database versions before you commit to an architecture.

Official Umbraco and Sitecore references for the migration plan

Start with the Umbraco requirements page before you size anything. It settles the runtime baseline for planning: current Umbraco CMS documentation requires .NET 10.0 or higher and supports installation on SQLite or SQL Server. Check that your hosting, build agents and database standard match that baseline, and confirm which Umbraco version your target environment will run. The Umbraco CMS requirements documentation is the place to verify this against the version you choose, since the page reflects the current release line.

Next, read the Umbraco end-of-service policy alongside the release dates. Umbraco 17 is the LTS release published on November 27, 2025, with end of life on November 27, 2028 and end of service on Umbraco Cloud on November 27, 2031. Umbraco 13 reaches end of life on December 14, 2026. Those dates set the upgrade horizon for a self-hosted estate and the hosting window if you choose Umbraco Cloud. The end-of-service policy also explains the Extended Long-Term Support phase, so ask your team to write down which dates trigger the next upgrade project.

Three pages settle the feature decisions. The Content Delivery API documentation explains that the API is opt-in, must be enabled in configuration, returns unpublished content only for preview with an API key and serves protected content only when member authentication is enabled. Engage and Forms licensing require their own review: the Umbraco Engage licensing page and the Umbraco Forms licensing model both tie licenses to public domains, so confirm the domain count for production, subdomains and test environments before you price those add-ons. On the Sitecore side, Sitecore's XM/XP to SitecoreAI transition guide is the baseline for what the SaaS path requires and what it does not carry over, so use it to confirm the gap list your team builds from.

How DeployOpen scopes and runs a Sitecore to Umbraco migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including Umbraco on your cloud accounts or data centers. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

We inventory Sitecore templates, items, renderings, media, roles and forms to decide what maps to Umbraco document types and what must be rebuilt.
The written scope names the Umbraco version, database (SQL Server or SQLite), hosting model and whether the frontend uses views or the Content Delivery API.
We record which Sitecore XP features, such as xDB, personalization and email marketing, are out of scope and which need a separate tool or license.

How we build

We map Sitecore templates to Umbraco document types and compositions, then migrate items and media into content nodes and the media library.
We rebuild renderings as Umbraco views or a headless frontend that reads the opt-in Content Delivery API, with preview access controlled by API key.
We test content parity, URLs, redirects, forms and editor workflows in a non-production environment before any cutover is scheduled.

How we hand over

We deliver runbooks for deployment, content migration reruns, backups and rollback, plus configuration and environment documentation.
We train editors and developers on document types, content publishing and the Content Delivery API, using your own content and environments.
We document which licensed add-ons, such as Umbraco Forms or Umbraco Engage, need valid licenses on your public domains and who holds them.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so Umbraco version changes are planned against published end-of-life dates.
We can prepare upgrade plans for the next Umbraco LTS release, including .NET runtime changes, before the current release reaches end of life.
We confirm with you, in writing, whether a self-hosted or Umbraco Cloud model fits your data residency and operations requirements before handover.