Migrate from Adobe Experience Manager to Wagtail: what the move involves
Wagtail can carry a content-heavy AEM Sites estate, but component logic, digital asset management and forms need their own plans. If your AEM 6.5 sites are mostly page-based publishing with structured content, a Django team can usually rebuild the page model in Wagtail. The decision you face now is timing: core support for on-premise AEM 6.5 ends on February 28, 2027, and extended support with critical fixes only runs until February 28, 2028. Work backward from those dates to set the date by which you must have cut over or chosen a bridge option, then decide whether the Python team will own the CMS after launch.
In most projects the work is split between internal Python and Django developers, who own the models, templates and deployment, and an implementation partner who handles discovery, the content migration tooling and the first build. Your own editors and content owners should take part early, because they decide which AEM components become StreamField blocks, which templates collapse into one, and which legacy pages are retired. Ask any partner to show how they will map each AEM component's Sling model or dialog logic to a Wagtail block and template, and to list which AEM features they consider out of scope. Confirm with your team whether the AEM Assets repository, AEM Forms or any Adobe-hosted integrations sit outside Wagtail's core and need a separate replacement or a retained service.
The main risks are underestimated component logic, asset metadata loss and a late discovery that some AEM workflows or personalization depend on Adobe tooling. Wagtail's content workflows and moderation cover many editorial approval paths, but you should test them against your real sign-off chain before you commit. Effort depends on the number of templates, locales, sites and assets, and no duration in this section is a commitment. Ask for a written scope that lists each component, workflow and integration, and check the Wagtail release schedule so you choose a long-term support line that matches your upgrade cadence.
Which AEM capabilities map to Wagtail, and which need rework
This table compares the AEM Sites capabilities that content teams use most with their Wagtail equivalents. Read each row as clean (a direct equivalent exists), needs rework (the capability exists but your content model, templates or integrations must change) or gap (Wagtail does not provide it, so a separate tool is needed). The main takeaway is that page and content authoring map well, while DAM and forms need separate decisions.
| Capability | Wagtail equivalent | Status |
|---|---|---|
| Page and component authoring | Page models with StreamField blocks for structured content in the editor | Needs rework |
| Templates and page trees | Django page models organized in a page tree; AEM component and template definitions must be re-modeled as Python classes | Needs rework |
| Multi-site | Built-in multi-site support with a site record per hostname and shared page trees | Clean |
| Localization | Built-in multi-language support; confirm how your translation vendor workflow connects before cutover | Needs rework |
| Content workflows and moderation | Built-in workflows and moderation, with approval steps configured in code; confirm they match your AEM approval chains | Needs rework |
| Image handling and focal points | Integrated image management with focal points for cropping; large AEM DAM libraries need a separate import plan | Needs rework |
| Headless content delivery | Headless API for delivering content to separate frontends | Clean |
| Search | Integrated search with the Elasticsearch or PostgreSQL backend; PostgreSQL is the simpler starting option | Clean |
| AEM Assets (DAM) and digital asset workflows | Not replaced by Wagtail; use a separate digital asset management tool or object storage with metadata | Gap |
| AEM Forms and adaptive forms | Not replaced by Wagtail; use a dedicated forms or e-signature tool | Gap |
Migration sequence from inventory to decommission
This sequence moves an AEM 6.5 Sites estate to Wagtail in controlled stages, so each step produces a verifiable artifact before the next one starts. The final stage shuts AEM down only after content, URLs and editors have been confirmed on the new stack.
Inventory templates, components, page trees and integrations
Your AEM architects and content owners list every editable template, component, page tree, workflow and integration, including the Assets and Forms modules in use. The team marks which items carry business logic in Sling models or Java code and which are pure authoring structure. The output is an inventory sheet with a usage count per template and a named owner for each integration. The step is done when the content owners sign off that nothing in production is missing from the list.
Build a pilot site on Wagtail
Choose one representative section of the site, ideally one with a mix of templates and a modest asset volume, and rebuild it in Wagtail. Your Python and Django developers model each component as a StreamField block, define page models for the section, and configure the multi-site and locale settings the pilot needs. The output is a working pilot with a documented component-to-block mapping that editors have tested in the Wagtail admin. The pilot is complete when editors can publish, preview and revert pages without developer help.
Export content and parse AEM packages
Export page content, fragments and assets from AEM using Package Manager with filters scoped to each site root, then parse the Jackrabbit FileVault packages with a script your team writes or your implementation partner provides. The parser maps node properties to Wagtail page fields and StreamField JSON, and writes asset files to the new media store with their metadata. The output is an import log that lists every page, asset and failed record, with a reconciliation count against the AEM inventory. Confirm with the AEM administrator that the export covers the versions and locales you need, since previous versions are not included in the package export.
Run a parallel environment with redirects and monitoring
Load the full import into a staging Wagtail instance and run the old and new sites side by side while editors work in both. Build a redirect table that maps every legacy AEM URL to its new Wagtail path, and test it against a crawl of the live site and the analytics referrer list. Add uptime, error rate and broken link monitoring on the new site before any public traffic moves. The output is a signed-off redirect table and a monitoring dashboard with alert owners. The step is complete when the crawl reports no unmapped URLs that return an error to visitors.
Cut over DNS and workflows
Schedule the cutover window with the business owners, freeze content changes in AEM, run a final incremental import of content changed since the last export, and switch DNS or the load balancer to Wagtail. Confirm that the moderation workflows, approval groups and notification emails work in production with real editor accounts. The output is a cutover runbook with a rollback path that the team has rehearsed. The step is done when the business owners confirm the live site, the redirects and the editorial workflows against the checklist.
Retain AEM read-only and archive evidence
Keep the AEM environment in read-only mode for a retention period set by your legal, records and compliance teams, and export the archives of pages, assets and workflow history they require. Record which data was migrated, which was retired and where any personal data now sits, so auditors can trace it. The output is an archive manifest and a decommission approval signed by the data owner. Confirm the retention period with your records team before you start this step, because it determines when AEM can be shut down.
Decommission AEM and close the license
After the retention period ends and the archive is verified, shut down the AEM author and publish instances, revoke service accounts and remove the integrations that pointed at them. Notify Adobe under your contract terms and confirm the license end date with your procurement team. The output is a decommission record that lists retired hosts, revoked credentials and the final license status. The step is done when no production traffic, scheduled job or integration still calls an AEM endpoint.
How AEM components become StreamField blocks
The core translation is from AEM component types and their dialogs to Wagtail StreamField block types and page models. In AEM, an author drops a component onto a page, fills in a dialog, and the component's HTL template decides how the result renders. In Wagtail, each reusable pattern becomes a Python block class (a StreamBlock or a custom Block) with typed child fields, and a page model declares which StreamFields an editor can fill. Decide the mapping at the level of the page model first: which AEM page templates become Wagtail page types, and which components become blocks inside a StreamField versus fields on the page. Nothing in the Wagtail toolchain converts AEM component nodes into blocks automatically, so the mapping is a design task that your team or implementation partner owns.
Authoring intent is lost wherever AEM relied on behavior that has no direct StreamField counterpart. Examples to inventory include inherited design and style settings in AEM's style system, editable template policies, component-level access rules, and dialog logic that shows or hides fields based on other values. A block can hold a structured value and validate it, but cross-component relationships and layout rules must be rebuilt in templates or custom blocks. Editors will also notice changes in how they place content: StreamField presents an ordered list of typed blocks, so a page built from free-positioned or nested AEM layouts will need a different arrangement. Plan short retraining sessions around the new block picker, block ordering and previews, and document which AEM behaviors editors will no longer have.
Settle the component inventory before any content or asset moves. Export the list of component resource types, the templates that use them, and the number of live pages per component, then mark each one as a block, a page field, a snippet or retired. Retiring components is often the cheapest decision in the whole project, and it is easier to make while the inventory is short. Confirm the Wagtail version and Django version your team will standardize on against the Wagtail release schedule, because block and template choices should match a supported release. Agree the inventory and the block design in writing with the content owners, and treat any AEM component without an owner as a risk to resolve before migration begins.
What data moves, and which integrations need rebuilding
Content and pages leave AEM through documented export paths, but the Wagtail side has to be rebuilt in its own terms. Each card below covers one piece of the move and marks whether it needs rebuilding, reconfiguring or retiring. Confirm the AEM export scope and every integration owner before estimating the work.
Content and page export
Pages, components and content fragments leave AEM as Jackrabbit FileVault packages exported with Package Manager, scoped by filters you define. Those packages hold node structure and property values, not rendered HTML, so a parser has to map AEM component properties onto Wagtail page models and StreamField blocks. Check which component resource types carry real content and which are only layout, and confirm with your AEM developers whether previous versions are included in the scope you export.
Asset migration into image models
Images from the AEM DAM become Wagtail image records, and their renditions are regenerated by Wagtail rather than copied. Focal points are not carried over automatically, so the editorial team should review cropping on key hero images after import. Keep the original file paths and checksums in a mapping table so references in content can be resolved and verified after the move.
Document migration into document models
PDFs, spreadsheets and other downloadable files move into Wagtail's document model, which stores files on the configured storage backend. Metadata such as titles, tags and collection membership must be mapped explicitly, because AEM folder structure does not translate one to one. Confirm file size limits and the storage backend your hosting team will run before the first bulk import.
Redirects and URL structure
Public URLs from the AEM site tree must map to Wagtail page paths, or search engines and inbound links will break. Build a redirect map from the crawled URL list and the exported page paths, and test it against sitemaps and analytics referrers. Plan to retire old paths only after redirects have been monitored for a full crawl cycle.
Search integration
AEM's search index and any Solr or third-party search service must be rebuilt. Wagtail offers integrated search backed by Elasticsearch or PostgreSQL, so the decision is which backend your operations team can run and monitor. Confirm relevance requirements, faceting and language analyzers with the content owners before cutover.
Analytics, translation and forms
Tag managers, analytics snippets and translation connectors often sit in AEM templates and must be reconfigured in Wagtail templates. Translation workflows that run through an external vendor need new connectors or a manual export and import step. Forms built with AEM Forms are a separate product and are not replaced by Wagtail, so confirm whether a Wagtail form module or a separate form service fits each use.
How the move differs by estate size and starting point
A single public site is the most direct case for Wagtail. The page tree, templates and editorial workflow map onto Wagtail's page models and StreamField, and a small Django team can often own the whole stack. The main work is turning AEM components into StreamField blocks and deciding which content fragments become snippets. Wagtail's content workflows and moderation cover most publishing approvals, and its integrated search and image focal points handle common needs without extra services.
- Component mapping: Each AEM component type becomes a StreamField block or a page model. Components with heavy dialog logic usually need a simplified editing model.
- Page tree: The AEM content tree is rebuilt as Wagtail page models and a single site root, with redirects from the old paths.
- Workflows: Wagtail's moderation and workflow features cover single-stage and multi-stage approvals for most public sites.
- Search and images: Built-in search with PostgreSQL or Elasticsearch and image focal points replace the AEM search and rendition setup.
- Usually outside the move: AEM Sites licensing, AEM-hosted Dispatcher configuration and any AEM-only marketing integrations.
Confirm with the content owners how many templates the site actually uses and which AEM features editors rely on day to day before estimating the rebuild.
An institutional estate with several sites and languages depends on how AEM language copies and site hierarchies are structured today. Wagtail supports multi-site and multi-language setups, so the work is mostly in designing the site and locale hierarchy before any content moves. Translation workflows, fallback rules and shared navigation need explicit decisions, because AEM's live copy and translation connectors do not carry over automatically.
- Site hierarchy: Wagtail sites map to AEM site roots. Shared components and global navigation are modeled once and reused across sites.
- Locales: Each language is configured as a locale, and page translations are created from the source page. Fallback behavior must be defined per site.
- Shared content: Snippets hold content that appears on several sites, such as footers, legal text and contact details.
- Translation management: AEM translation connectors are usually replaced by an external translation management system that exchanges content through the API.
- Usually outside the move: AEM translation connectors, the translation vendor integration and any Multi Site Manager rollout logic that lives in AEM configuration.
Ask the team which sites share templates, which languages each site publishes and where translations are produced today, because those answers set the size of the hierarchy design.
Some AEM estates depend more on Assets and Forms than on page authoring. Wagtail has an image and document model with focal points and collections, but it is not a digital asset manager with AEM Assets' metadata, rendition and review features. Forms are not a Wagtail product either, so the form logic and any forms-driven processes need a different home. These estates can still move, but the project usually splits into a Wagtail content move and a separate asset and form decision.
- Images and documents: Wagtail stores images and documents with collections, tags and focal points. Large libraries with complex metadata, rights data or usage tracking may need a separate DAM.
- Renditions: Wagtail generates renditions on request. Confirm the specific crop and format sizes the sites need.
- Forms: AEM Forms workflows, adaptive forms and document generation usually stay in a separate system such as a form builder or a document service.
- Asset migration: Exports from AEM Package Manager carry asset binaries and metadata that must be mapped to Wagtail fields or to the chosen DAM.
- Usually outside the move: AEM Assets, AEM Forms and any digital asset workflows tied to them.
Before committing, ask the owners how many assets exist, how they are licensed and tagged, and which forms run in production, because those answers decide whether Wagtail covers the content move alone or whether a separate DAM and form platform is needed.
Running AEM and Wagtail in parallel, then cutting over
Keep AEM as the single authoring source for the whole pilot period, and treat the Wagtail site as a read-only consumer of content until cutover. In practice, that means editors keep working in AEM's page editor and DAM while a scheduled export job, built from the Package Manager output described in the export page, feeds a staging Wagtail instance. Each sync run should rebuild StreamField blocks from the same component mapping used in the pilot, so a page edited in AEM on Monday appears in Wagtail on the next run without anyone retyping it. Confirm with your AEM team which replication agents and workflow launchers they rely on today, because any automation that writes to AEM after cutover will need a new owner.
Plan the editorial freeze as a short, named window in which AEM stops accepting new publishes for migrated sections, and agree its length with the content owners before the window opens. During the freeze, run one final export, import it into Wagtail's staging instance, and compare page counts, image renditions and document links against the AEM source. Ask the team to confirm which content types are excluded from the freeze, such as forms or campaign pages. Wagtail's content workflows and moderation can carry the approval steps forward, so decide which roles approve in Wagtail before the freeze, not during it.
Test every URL before DNS changes. Crawl the legacy AEM site, export the full URL list, and check each path against Wagtail's staging host, including redirects for renamed or restructured pages, multi-site hostnames and language prefixes. Keep the rollback plan simple: retain the AEM publish environment and its DNS record, document the exact steps to point traffic back, and agree who has authority to trigger it. The cutover checklist should cover DNS and TLS certificates, redirect verification, search indexing, analytics tags, sitemap submission, the final content diff, and a named on-call contact for the first days after launch. Confirm the retention period for the AEM environment with your licensing and support team before you commit to a rollback window.
What goes wrong in AEM to Wagtail moves, and how to prevent it
Most failed AEM to Wagtail projects fail on scope that was never written down, not on the framework itself. The cards below cover the risks that tend to surface late, from editorial workflow and asset scope to URLs, translations and operations, each with the check to run before cutover.
Editorial workflow nuance lost
AEM workflows often encode approval steps, launch scheduling and rollback rules that editors rely on without documenting them. Wagtail provides content workflows and moderation, but the stages, reviewers and notifications must be rebuilt deliberately. Before build starts, export the workflow models from AEM, interview editors about exceptions, and write each stage as a Wagtail workflow task with a named owner. Test one full publish, reject and revert cycle with real editors.
DAM and Forms scope underestimated
Teams often scope the content migration as pages only and discover late that AEM Assets metadata, renditions, asset workflows and AEM Forms have no direct Wagtail equivalent. Wagtail handles images with focal points and documents, but digital asset management and form processing need separate components or services. Inventory every asset type, rendition and form in writing, then decide per item whether it moves, is replaced by a named tool, or is retired. Ask the implementation partner to list these as explicit deliverables.
Broken URLs and lost search equity
AEM sites often use deep paths, selectors and extensions that do not match the page tree a Wagtail site will produce. Without a mapping, search rankings, bookmarks and inbound links fail silently. Build a URL inventory from server logs and analytics, map each legacy path to a new Wagtail page or a permanent redirect, and run crawls on both sites before and after cutover. Keep the redirect map under version control so it can be audited and extended after launch.
Translations not mapped to locales
AEM language copies, translation jobs and fallback rules do not carry over automatically. Wagtail supports multi-language sites, but locale trees, translated page relationships and fallback behavior must be designed and tested. Confirm which languages are live, which pages are translated versus machine or partially translated, and how translators will work in the new system. Verify that each locale renders, links resolve within the correct language, and hreflang or sitemap output matches the new structure.
Component logic not mapped to StreamField
AEM components combine markup, dialogs, policies and Sling models, and not every one becomes a clean StreamField block. Copying templates literally often produces blocks that editors cannot configure or that carry hidden logic into the frontend. Catalog components by editorial use, group them into a small set of blocks with defined fields, and move business rules into Django models or views. Review the block library with content editors before page migration starts.
Operations skills not in place
Running Wagtail on your own infrastructure means owning Django upgrades, database backups, search indexing, media storage and security patching, tasks AEM teams often outsource through Adobe or a partner. Confirm who on your staff can operate Python services, and whether that capacity is in place before cutover. Agree on the supported Django versions, the Wagtail release line you will follow, and the backup and restore tests you will run. Write these into a runbook so support does not depend on one engineer.
What drives the cost and duration of the move
This table lists the factors that most change the effort of moving an AEM 6.5 estate to Wagtail, with why each matters and how to keep it under control. Read it before requesting a scoped quote, because each driver should appear as a line item in the written scope. The main takeaway is that one-time migration work scales with component, site, asset and workflow counts, while hosting, upgrades and support recur for as long as the site runs.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Component count and complexity | Each AEM component, template and dialog must become a StreamField block, template or snippet. Components with nested logic, custom Sling models or heavy client-side behavior take longer to map and test. | Inventory components by usage on live pages, retire unused ones before migration, and merge near-duplicates into shared blocks. |
| Number of sites and locales | Each AEM site tree, language copy and launch-state rule needs its own page tree, translation mapping and multi-site configuration in Wagtail. Locale fallback and URL structure add testing. | Confirm which sites share templates and which locales are actually maintained, and migrate the smallest set of live locales first. |
| Asset volume and metadata | Images, documents and renditions must be exported, deduplicated, re-indexed and linked to pages. Large DAM libraries with poor metadata take longer to clean and verify. | Audit asset usage, archive unreferenced files, and agree a metadata schema before export so that imports are not repeated. |
| Integration count | Analytics, personalization, forms, search, translation services and marketing tools that read or write AEM data each need a replacement or a rebuilt connection. AEM Forms and DAM workflows are not replaced by Wagtail alone. | List every integration with its owner and data flow, decide which are retained, and confirm that each replacement exists before scope is fixed. |
| Workflow complexity | Wagtail provides content workflows and moderation, but multi-stage approvals, scheduled launches and cross-site review rules often need custom configuration and testing with editors. | Document the current approval chain and launch rules, then reduce it to the stages editors actually use. |
| Editor training and change management | Authors used to AEM's page editor need time to learn the Wagtail admin, block-based editing and new preview behavior. Training time is effort that is easy to leave out of estimates. | Ask for training sessions in the scope, run parallel pilot content, and budget for a short period of post-launch editor support. |
| Forms and DAM in scope | If AEM Forms or AEM Assets features are part of the estate, the move becomes a wider replacement project with separate tools, data stores and compliance evidence. | Decide early whether Forms and DAM are in or out of scope, and where they are out, name the replacement system in the written scope. |
| One-time migration work | Discovery, mapping, content import, template build, testing, redirects, editor training and cutover are paid once for the project. Work scales with the drivers above. | Ask each quote to show discovery, build, data migration, testing and cutover as separate deliverables with acceptance criteria. |
| Recurring hosting, upgrades and support | Hosting, database and search operation, Wagtail and Django upgrades, security patching, and support continue after launch. Wagtail publishes feature releases and LTS releases on a fixed schedule, so upgrade effort recurs. | Choose a supported LTS line, confirm the support model for security fixes, and ask for a written retainer or internal ownership plan for upgrades. |
Questions teams ask before moving from AEM to Wagtail
What does a migration from AEM to Wagtail cost?
Labor is the main cost, because Wagtail is BSD-3-Clause licensed and free for open and closed-source use, so the software carries no license fee. The work falls into discovery and content inventory, rebuilding AEM components and templates as StreamField blocks and page models, Python and Django development, scripted migration of pages, images and documents, redirects, search setup, testing and editor training. Most of that is one-time. Hosting, security patching, Django and Wagtail upgrades, and support recur. Costs rise with the number of component types, sites, languages, asset volume and custom AEM integrations. When you request a quote, ask for an itemized scope that lists which components are rebuilt, which content migrates automatically, what is excluded and what upgrades cover.
How long does an AEM to Wagtail migration take?
No single duration fits every estate, so ask for a timeline in a written scope rather than relying on a general number. The schedule depends on how many page templates and component variants exist, how many sites and locales must launch, how clean the AEM content is, and how many custom integrations must be rebuilt. The external deadline matters most. Adobe lists core support for on-premise AEM 6.5 until February 28, 2027, and extended support with critical fixes only until February 28, 2028, according to its AEM 6.5 support timeline. Wagtail's own schedule also shapes the plan, since the 8.3 LTS is scheduled for May 4, 2027. Start on a supported LTS line and confirm which version your build targets before work begins.
What must our internal team provide for an AEM to Wagtail move?
Your team supplies the knowledge and access that no implementation partner can supply alone. Expect to provide:
- A content owner for each site who can approve page types, navigation and taxonomy
- Editors who test authoring flows in StreamField and sign off on moderation workflows
- Read access to the AEM repository, exports, templates and component documentation
- Decisions on the search backend, either Elasticsearch or PostgreSQL, and on the hosting model
- DNS records, redirect rules and analytics configuration for cutover
- A named product owner who can settle scope questions quickly during the build
Can our own team run Wagtail after the migration?
Yes, if the team has Python and Django skills and can own patching, backups, monitoring and upgrades. Wagtail runs on Django, and the repository lists support for Django 5.2.x, 6.0.x and 6.1.x, so the team must track both Django and Wagtail versions. Wagtail ships a feature release every three months and an LTS release typically once every four feature releases, so a steady upgrade routine is necessary. Confirm before go-live who handles security response, on-call coverage and editor support. If capacity is limited, the work can be split: your staff manage content and daily administration, while a partner holds a retainer for upgrades, testing and incident support. DeployOpen offers ongoing support under retainers, scoped in writing.
Can AEM Assets and Forms move to Wagtail?
Wagtail covers most public-site publishing needs, but it does not replace AEM Assets or AEM Forms as products, so plan those capabilities separately. Wagtail includes image handling with focal points and document management, which can carry most site imagery and PDFs. Advanced digital asset management, such as complex metadata governance, many channel renditions and deep Creative Cloud workflows, needs its own decision. Adaptive forms and multi-step form workflows also need a dedicated tool or a Wagtail form package that you test against your requirements. Inventory the AEM Assets and Forms features your teams use today, then confirm whether Wagtail or a separate DAM and forms system covers each one before you commit to a single platform.
What Wagtail support options exist through Torchbox and the community?
Wagtail is developed in the open on GitHub, so community help comes through public issues, discussions and project documentation. Torchbox, Wagtail's primary sponsor, offers commercial support and hosting, which gives an organization a contracted route to fixes and service terms. The Wagtail repository lists NASA, Google, Mozilla, MIT, NBC, BMW and US and UK government organizations among its users, which shows production use at scale but not the support terms any one of them receives. Ask Torchbox for the written support scope, response expectations, hosting terms and the Wagtail versions covered. DeployOpen can plan, implement and support Wagtail under fixed-scope engagements and retainers, and can work alongside a vendor support contract if you hold one.
How do Wagtail LTS releases affect upgrade planning?
LTS releases give you a longer runway between major upgrades, so plan your upgrade cycle around them. Wagtail typically publishes an LTS release once every four feature releases, and each LTS is supported for eighteen months. Wagtail 7.4 LTS, released May 4, 2026, has security support until November 2, 2027. Wagtail 8.3 LTS is scheduled for May 4, 2027, with support until November 6, 2028. Feature releases arrive every three months, so teams that stay on feature releases must upgrade more often. Check the Wagtail release schedule before choosing a launch version, and budget upgrade testing into each cycle.
Does moving to Wagtail change our compliance evidence?
Yes, the platform change alters the evidence you must produce, so update controls and records as part of the migration. Wagtail does not carry a certification of its own, and the hosting, identity, logging, backup and change processes around it determine most of your evidence. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask your assessor early which control areas change, including access control, change management for Django and Wagtail upgrades, backup and restore testing, logging, and the content approval workflow that replaces AEM's.
How DeployOpen scopes and runs an AEM to Wagtail migration
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an AEM to Wagtail move, that means agreeing the content, template and asset scope in writing first, then building and handing over a Wagtail site that your own team can run.
How we scope
- Inventory AEM page templates, components, content fragments and DAM folders that the Wagtail site must reproduce.
- Agree in writing which sites, locales, workflows and AEM Assets or Forms features are in scope and which stay out.
- Confirm the target hosting, database and search choices, plus which Django and Wagtail versions your team will maintain.
How we build
- Map each AEM component to a StreamField block or page model, with a documented field-by-field mapping.
- Script the export from AEM Package Manager and the import into Wagtail images, documents and page trees, with reruns logged.
- Test redirects, multi-site routing, search and moderation workflows against the agreed scope before any cutover.
How we hand over
- Deliver the Wagtail codebase, deployment configuration and runbooks in your own repositories and infrastructure.
- Document content model decisions, migration scripts, known gaps and any AEM features that were not replaced.
- Train your Python and Django developers and editors on the authoring model and the upgrade path for the Wagtail release you adopt.
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 after handover.
- Ask any provider to confirm, in writing, who maintains the Wagtail upgrade cycle and backups once the project closes.
