Migrate from Sitecore to Wagtail

Migrate from Sitecore to Wagtail: what moves and what gets rebuilt

If your Sitecore XP or XM estate has to run in your own data center or cloud account, Wagtail can carry most of the content and page structure, but not the marketing stack around it. Templates, items, media and the site tree map well to Wagtail page models, StreamField blocks and its multi-site and multi-language settings. Experience Database (xDB) data, personalization rules, email marketing content and Sitecore Forms do not move as they are and need separate rebuilds. Sitecore's own migration guide says the SitecoreAI path does not carry xDB data, email marketing content or personalization either, so plan that work as a distinct workstream whatever CMS you pick.

Start with an inventory of your templates, renderings and sites. Each Sitecore template with a stable field set usually becomes a Wagtail Page subclass, and renderings that are structural usually become StreamField blocks. Renderings that depend on Sitecore personalization or on data sources tied to xDB need a decision on what the Wagtail equivalent should be before any code is written. Confirm with your team which serialized YAML modules hold content and which hold only configuration, because that determines what you import and what you recreate by hand. Check how your Sitecore sites use languages and fallback rules, and map them to Wagtail's locale and site configuration before you build page trees.

In most projects the CMS migration is done by a platform or integration team with Django and Python skills, working alongside the Sitecore developers who know the content model and a marketing team that owns forms, campaigns and analytics. Ask any implementation partner to name who will own the import scripts, the block design, the redirect map and the replacement for each Sitecore feature, and to confirm the scope in writing before work starts. Effort and risk depend mainly on the number of templates, languages and custom renderings you have, so get those counts from your own estate rather than from a generic estimate.

Which Sitecore capabilities map to Wagtail, and which need rework

This table compares the main Sitecore XP and XM capabilities with their Wagtail equivalents and marks where rebuild work or separate tools are needed. Read the Wagtail column as a starting point, and confirm feature parity against your own templates, renderings and editorial workflows before committing to a scope.

Sitecore capability	Wagtail equivalent	Rework needed
Templates and renderings	Page models as Python classes, with StreamField blocks for reusable components	Yes: each rendering becomes a block or template, and item-level presentation logic is rewritten in Django templates
Multi-site setup	Built-in multi-site support through Wagtail sites and root pages	Partial: confirm how your site roots, hostnames and shared content map to Wagtail's site model
Multi-language setup	Built-in multi-language support for page translations	Partial: confirm locale structure, fallback rules and translation workflow in your environment
Editorial workflows	Content workflows and moderation for approval steps before publishing	Partial: approval chains and roles from Sitecore workflows must be re-created and tested
Media and images	Image handling with focal points for cropping, plus document support	Partial: confirm how Sitecore media library folders and metadata move into Wagtail collections
Search	Integrated search backed by Elasticsearch or PostgreSQL	Partial: confirm search relevance and facet needs against your current Sitecore search setup
Personalization and rules	Not provided by Wagtail	Gap: needs a separate personalization tool or application logic
Marketing automation and email	Not provided by Wagtail	Gap: needs a separate tool such as Mautic for campaigns and journeys
Forms	Not provided as a Sitecore Forms equivalent in core	Gap: needs a forms package or a separate form service, with data handling confirmed
Analytics and xDB data	Not provided by Wagtail	Gap: needs a separate analytics tool and a plan for historical data, which typically does not migrate

Which data can be exported from Sitecore and what has no export path

Sitecore content can leave the platform in a usable form, but the scope depends on what you serialize and which modules you include. Anything that lives in analytics, contact data, personalization or third-party connections has no direct export path into Wagtail and needs a separate plan.

Serialized items and YAML trees

Sitecore Content Serialization writes items, templates and renderings to YAML files in your source repository. For a Wagtail migration these files are the working inventory: each template becomes a candidate page model and each item tree becomes a page hierarchy. Check which module files are included in the serialization config, because a tree left out of the modules will not appear in the export. Confirm with your Sitecore team which items are content and which are presentation code.

Media library and binary assets

Serialized YAML describes media items but does not carry the image or document binaries in the same way, so you need a separate download of the media files from the Sitecore media library or the file system behind it. Plan a Wagtail image and document import that keeps original file names, alt text and focal point data where they exist. Ask your team to confirm how media is stored in each environment before the import script is written.

Roles, users and permissions

Serialization can include roles and users, but those records describe Sitecore security, not Wagtail permissions. Map Sitecore roles to Wagtail groups, page-level permissions and workflow stages by hand. Do not import user accounts with passwords, and confirm with your security team how editor identities will be created in your Django identity provider.

xDB contacts and analytics

Experience Database data, including contacts, interaction history and analytics, has no migration path into Wagtail. The Sitecore migration guide for SitecoreAI says xDB data is not migrated, and the same gap applies here. Decide early whether historical visitor data is archived as read-only exports, kept in the old platform until retirement, or dropped with documented legal review. Any new analytics tool needs its own consent and retention design.

Personalization rules and email content

Personalization rules, audience segments, experience-based variants and email marketing content do not carry over. The SitecoreAI migration guide states that personalization and email marketing content must be rebuilt. For Wagtail, this means writing segmentation logic in Django views or a separate service, and rebuilding campaigns in a dedicated email tool. Inventory each rule and campaign and record its business owner before the rebuild starts.

Search, forms and CRM integrations

Sitecore search indexes, form submission handlers and CRM hooks are custom code tied to the old platform. Each one needs a Django replacement: a search backend in Wagtail, form pages built on Wagtail forms or a separate form service, and CRM connectors written as Django signal handlers or queued tasks. Inventory every outbound call in the Sitecore code base, including webhooks, and confirm the target system and credentials for each before cutover.

How Wagtail page models and StreamField replace Sitecore renderings

In Sitecore, a template defines the fields on an item, and renderings placed into placeholders on a page decide what the front end displays. In Wagtail, the equivalent unit is a Python class that subclasses Page. Each Sitecore template becomes one page model, with its fields declared as Django model fields or Wagtail panels such as FieldPanel. Template inheritance usually maps to abstract base page classes, and the parent-child rules that Sitecore enforces through insert options become parent_page_types and subpage_types on each model. Inventory the templates before writing code: list every base template, every standard field, and every item that is used as a data source rather than a page, because those often need a snippet or a plain Django model instead of a page. Confirm with your Wagtail developers which template fields are truly per-page content and which are shared settings, since that split decides where the model lives.

Renderings and placeholders have no one-to-one Wagtail counterpart, and this is where most of the rebuild effort sits. The usual approach is to give a page a StreamField whose blocks correspond to the components an editor places on a page: a hero, a text block, a call to action, a form embed or a listing. Each block is a StructBlock, ChoiceBlock or similar class with its own fields, and the front end renders each block through its own template. A Sitecore placeholder that holds several renderings in a fixed order usually becomes one StreamField, while a placeholder that holds a single rendering may stay a plain field. Renderings that pull data from another item become a PageChooserBlock or SnippetChooserBlock. Expect to decide, rendering by rendering, whether the logic belongs in the block, in the page model or in a shared service.

Serving the front end is a separate choice. Wagtail renders pages through Django templates, which fits teams that want server-side pages with the Python stack and a single deployable application. Wagtail also ships a headless content API, so a Next.js or other JavaScript front end can fetch the same page models as JSON. Pick one path per site or per section, because mixing both in the same templates adds maintenance cost. Wagtail supports Django 5.2.x, 6.0.x and 6.1.x, so confirm which Django version your target platform, hosting image and internal Python standards use before you pin a Wagtail release. Check the Wagtail release schedule for the Wagtail versions that match that Django line and their support windows.

The migration sequence from inventory to Sitecore decommission

This sequence moves a Sitecore estate to Wagtail in stages, so each site is proven on the new platform before Sitecore is switched off. Every step ends with a named artifact that the next step depends on.

Inventory templates, renderings, sites and integrations
Start by listing every template, rendering, site definition, language, workflow and external integration in the Sitecore solution, including the module files that define the serialized tree. Your Sitecore developers and content owners should review the list together, because renderings that look like layout often carry business logic. The output is a template-to-model map and an integration register that names the owner of each item. The step is done when every site and language has a line in the map and each integration has a decision: rebuild, replace or retire.
Design Wagtail page models and StreamField blocks
Translate the template map into Wagtail page models, with a parent page type for each site section and StreamField blocks for repeated components such as heroes, cards and promotional panels. Decide early which content is shared across sites and which is site-specific, because that choice shapes the site root and locale structure in Wagtail. Your Python developers and an editorial lead should review the models against real pages. The output is a model specification and a list of blocks, and the step is done when editors have approved the content structure for each page type.
Build a pilot site on Wagtail
Choose one bounded site, ideally one with few languages and few integrations, and build it on Wagtail with the models and blocks from the previous step. Configure multi-site and multi-language settings, workflows and moderation, and image handling so the pilot exercises the features your estate depends on. The pilot is also the place to test search and the rendering layer. The output is a running pilot on a staging environment with a written list of gaps, and the step is done when stakeholders accept the pilot as a basis for the full migration or document why they do not.
Import serialized content and media
Parse the Sitecore Content Serialization YAML files and map items to Wagtail pages, fields to model attributes and rich text to StreamField blocks. Import media separately, carrying over file names, alt text and focal points where the source provides them, and record every item that could not be mapped. Run the import against a staging database several times until the output is stable. The output is an import report that lists imported, transformed and rejected items with reasons. The step is done when content owners have reviewed a sample of each page type and signed off the report.
Run Wagtail and Sitecore in parallel
Keep Sitecore serving production traffic while Wagtail serves the migrated sites on a separate hostname or in a controlled test environment. Compare rendered pages, search results, forms and analytics tags for each migrated site, and track differences in a shared defect list. Note what Sitecore personalization and xDB covered, because those behaviors must be replaced separately and cannot be verified by content comparison alone. The output is a parity log and a defect list with owners. The step is done when every critical template has passed comparison and the business owner accepts the open items.
Cut over with a signed-off redirect list
Before switching DNS or the reverse proxy, build a redirect map from every indexed Sitecore URL to its Wagtail equivalent, including language prefixes, media paths and retired pages. Test the redirect list against a crawl of the live site and confirm that search engine references and key external links resolve. Agree a rollback path with the platform owner before the change window. The output is a signed-off redirect list and a cutover runbook. The step is done when the redirect list has been reviewed by the SEO and content owners and the rollback has been rehearsed.
Decommission Sitecore after the retention period
Once the migrated sites have run in production without critical defects, export a final archive of Sitecore databases, serialized items, media and logs, and store it under your retention policy. Confirm with your compliance team which records must be kept and for how long, and remove Sitecore servers, licenses and integrations only after that review. Ask your Sitecore licensing contact in writing what notice applies to ending the subscription or support. The output is a decommission record and a verified archive, and the step is done when the archive restores successfully in a test environment.

How the migration changes with estate size and starting point

A single site in one language is the simplest case for Wagtail. The Sitecore template tree can usually be flattened into a smaller set of Wagtail page types, with a clear home page, section pages and detail pages. Renderings that repeat across pages are a good fit for StreamField blocks, so a hero, a card grid or a call to action becomes one reusable block definition instead of many view variants. Because there is only one locale, the import is mostly a question of mapping items and media, and the team can validate the page tree against the live site before any cut-over.

Page model design: Keep one page model per distinct layout and move shared fields into StreamField blocks rather than duplicating templates.
Import effort: Serialized YAML items map to page types and blocks, and media moves into Wagtail's image and document models with focal points set where editors need them.
Parallel running: A short overlap is usually enough to compare pages, redirects and search results, since there is no second locale to check.
Editorial workflow: Confirm whether editors need moderation and approval, because Wagtail's workflows are set per page tree.
Redirects: Export the Sitecore URL list early so redirects can be tested before go-live.

Before committing, ask your partner to confirm the effort in writing against your actual item count and rendering inventory.

What drives migration cost and duration

This table breaks the Sitecore to Wagtail migration into its cost components, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to structure written quotes so that vendors price each workstream separately. Wagtail is BSD-3-Clause, so no software license fee applies, and the main cost is the people and infrastructure that build and run the site.

Cost component	One-time or recurring, and who is paid	What drives it up or down, and what to ask for in a quote
Discovery and mapping	One-time. Paid to the implementation team for auditing templates, renderings, sites and languages.	Drivers: number of sites, languages and templates. Ask for a written mapping inventory and a list of Sitecore features in scope.
Django and Wagtail build	One-time. Paid to Python and Django developers for page models, StreamField blocks and front-end templates.	Drivers: number of distinct renderings and custom components. Ask for the block library scope and which Django versions (5.2, 6.0 or 6.1) the build targets.
Content and media import	One-time. Paid for scripting the YAML import, transforming items and migrating images and files.	Drivers: content volume, serialization quality and image focal point rework. Ask how dry runs, reconciliation reports and rollback are handled.
Multi-site and multi-language setup	One-time. Paid for Wagtail site and locale configuration, routing and translation workflows.	Drivers: number of locales and whether translations are already in Sitecore. Ask for the locale list and the editorial workflow to be configured.
Personalization and form rebuilds	One-time for rebuild, recurring for any third-party service. Paid to developers and to vendors of analytics or form tools.	Drivers: how many personalization rules and forms exist. Sitecore's migration guide says personalization and xDB data are not migrated and must be rebuilt. Ask which rules are retired and which are rebuilt.
Hosting and operations	Recurring. Paid to your cloud or data center, plus any managed Torchbox hosting or support contract if chosen.	Drivers: traffic, search backend (Elasticsearch or PostgreSQL), backups and Django upgrade cadence. Ask for a written hosting model and support hours.
Training and editorial handover	One-time for initial sessions, recurring when new editors or developers join. Paid to internal staff or trainers.	Drivers: editor count and change in editing model. Ask for documentation of the Wagtail admin, workflows and moderation setup.

What usually goes wrong when Sitecore content moves to Wagtail

Most failed Sitecore-to-Wagtail moves do not fail at the content import. They fail where Sitecore logic, URLs, language variants and marketing features were assumed to carry over unchanged. The cards below cover the risks that recur and the checks to run before cutover.

Renderings with embedded logic

Sitecore renderings often hold code-behind, data source lookups, placeholder rules and conditional display that never existed as content. In Wagtail these become page models, template tags or StreamField block logic written in Python. Inventory every rendering that reads context, queries other items or switches output by user state, and assign each one a Django home before any content is imported. Treat a rendering with no clear owner as a design gap, not a copy task.

Lost URL structure and redirects

Sitecore item paths, friendly URL rules and link manager entries define how search engines and bookmarks reach pages. Wagtail derives URLs from the page tree and slugs, so a restructured tree silently breaks inbound links. Export the live URL map from your analytics and Sitecore link database, decide which paths are kept, and load 301 redirects in Wagtail's redirects module before DNS changes. Confirm that canonical tags and sitemaps reflect the new routes.

Incomplete multi-language content

Sitecore language versions can be partially translated, fallback-dependent or stored as separate items per culture. Wagtail's multi-language support works through locale-aware pages, so a source that exports only default-language content will produce empty or mislabeled pages in other locales. Count translated items per language from the Sitecore side, define the fallback rule your editors expect, and test each locale's navigation, hreflang output and search indexing on the target site.

Python and Django skills gaps

Wagtail is built on Django, so the team that maintains templates, page models and migrations needs Python and Django experience, not only front-end or .NET skills. Teams that ran Sitecore on .NET often underestimate how much custom code moves into Python models, forms and management commands. Assess the skills you have before choosing a timeline, and ask any implementation partner who will own the Django code after handover. The Wagtail release schedule also sets Django version support, which the team must track.

Treating personalization as lift-and-shift

Sitecore personalization rules, xDB profiles and campaign logic do not move into Wagtail. The Sitecore migration guide states that SitecoreAI does not migrate xDB data, email marketing content or personalization, and Wagtail has no built-in equivalent. Teams that map rules to page variants without a defined audience model end up with pages that behave differently for every visitor. List each active rule, decide whether it becomes a segmented block, an analytics-driven experiment or a dropped feature, and assign a separate tool for it before cutover.

Forms and submissions left behind

Sitecore Forms submissions, their field mappings and any downstream CRM or email hooks rarely appear in a content export. Wagtail needs form pages or a form library built with its form builder, and the submitted data must land in a store you control. Inventory each live form, its validation rules, its recipients and its retention requirement, then test submission end to end in staging, including file uploads and confirmation emails.

Questions teams ask before moving from Sitecore to Wagtail

How much effort does a Sitecore to Wagtail move take?

Effort depends mostly on how much of the Sitecore estate is in scope and how far the rendering layer changes. The main drivers are the number of templates and renderings, the volume of media and multilingual content, the count of sites that share components, and whether personalization, forms and analytics must be rebuilt rather than retired. Each Sitecore template maps to a Wagtail page model, and each rendering maps to a StreamField block or a template include, so a large component library adds design and testing work. Ask any partner for a written scope that lists sites, languages, content types, integrations and the marketing features to rebuild before comparing figures.

How long does the migration take, and why does it vary so much?

Duration is set by scope, not by the CMS itself. Teams with a small number of sites and a simple component set move faster than estates with many brands, custom Sitecore modules and years of serialized content. Timing also depends on decisions the client must make, such as the URL structure to keep, which personalization rules to retire, and how editors will be trained. Ask for a timeline tied to named milestones (content model, import rehearsal, editorial acceptance, cutover) and check which dependencies sit with your team.

What does the client team need to provide?

Expect to supply access to the Sitecore environment and its serialized YAML, a current inventory of sites, languages and workflows, and named business owners who can approve content models and page designs. You will also need hosting accounts for Django and PostgreSQL, a decision on search (Elasticsearch or PostgreSQL), an identity provider for editors, and a content freeze or delta plan for cutover. Early access to the people who own forms, consent and analytics avoids rework later.

Can our own developers do the migration without an outside partner?

Yes, a capable internal team with Python and Django experience can do the work, and Wagtail documentation and its community are open to everyone. The harder parts are reading Sitecore serialization, rebuilding renderings as components, and running tests against real content volumes. Many teams split the work: internal staff own the content model and editorial process, while an outside party handles the import pipeline, hardening, backups and upgrades. Decide this against your staff's Django skills and the time available.

What happens to xDB data and personalization?

Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, and those must be rebuilt. Wagtail is a CMS, so it does not bring its own visitor profiles, personalization rules or campaign engine. Most teams keep visitor analytics in a separate self-hosted tool and rebuild segments and campaigns in a marketing platform, then feed simple audience rules into Wagtail templates. Confirm exactly which XP features your site uses, because some have no direct equivalent and need a product decision.

Can Wagtail run several sites and languages from one installation?

Yes. Wagtail supports multi-site and multi-language setups, so one installation can serve several domains with shared components and separate page trees. Each site can have its own root page, and localization can be used for translated content. Ask your architects to test how translated pages, shared snippets and access rules behave under your locale count and editorial workflow, because multi-language structure is one of the decisions that is hardest to change later.

How do support and upgrades work with the Wagtail release schedule?

Wagtail ships a feature release every three months, and an LTS release typically comes once every four feature releases with eighteen months of support. Wagtail 7.4 LTS was released May 4, 2026 and has security support until November 2, 2027, while Wagtail 8.3 LTS is scheduled for May 4, 2027 with support until November 6, 2028. Plan upgrades on LTS lines where possible and budget regular testing. Wagtail supports Django 5.2.x, 6.0.x and 6.1.x. Commercial support is available from Torchbox, the primary sponsor, and DeployOpen can offer upgrade retainers scoped in writing.

How DeployOpen scopes and runs a Sitecore to Wagtail migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Sitecore to Wagtail move is scoped in writing before any build starts. The work covers the page model, content import, multi-site and multi-language setup, and the handover of a Django codebase your team can run.

How we scope

We inventory the Sitecore templates, renderings, sites and languages that the Wagtail page models must replace.
We agree in writing which content, media and workflows move, and which personalization or forms need separate tools.
We confirm the Django and Wagtail versions, database and search backend that match your hosting and support plan.

How we build

We map Sitecore templates and renderings to Wagtail page models and StreamField blocks, then test them with real editor scenarios.
We build the import path from your Sitecore serialized YAML and media files, and rerun it until the output matches the source.
We configure multi-site and localization, then run security testing and document the hosting controls for your review.

How we hand over

We deliver the codebase, deployment runbooks, backup and restore procedures, and editor documentation as listed in the written scope.
We walk your Python and operations staff through running Wagtail and Django, including how to apply upgrades.
We record which Sitecore features were not migrated, so your team knows what was rebuilt and what was retired.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, and the retainer scope is also agreed in writing.
Confirm with us which Wagtail release line, including any LTS version and its support end date, your site will run on.

Migrate from Sitecore to Wagtail