Migrate from Adobe Experience Manager to Drupal: what the work involves
Consider a team running an AEM 6.5 estate with several sites, a large DAM and approval flows built years ago. Core support for AEM 6.5 on-premise ends February 28, 2027, so the team has to decide well before then. The migration is mostly content, asset and workflow rebuilding, not a code port. Java components and Sling models do not carry over to Drupal, so the work is to map what editors author, rebuild the templates and blocks that render it, and recreate the approval paths editors depend on. Content itself can be extracted with the Package Manager export, but the packages arrive as Jackrabbit FileVault structures that someone must parse and load into Drupal's content model.
Internal platform and content teams usually own the decisions: which sites move first, which content types survive, and who signs off on editorial workflow. Most organizations bring in an implementation partner for the migration scripts, the theme and block build, and the cutover. Effort depends on three things: the number of components and templates in use, the volume and metadata quality of DAM assets, and how many workflow steps and multi-site rules must be reproduced. Ask any partner to inventory each of these in writing before agreeing a fixed scope, and confirm how the existing AEM Workflow and launch configurations will be documented.
Drupal core is licensed under GPL-2.0-or-later and there is no paid edition of Drupal itself, so the license line in the budget is zero. The recurring costs sit elsewhere: hosting, security updates, contributed modules such as the SAML Authentication module for single sign-on, and the partner or internal time to keep the site current. Check the Drupal core release schedule before choosing a target version, because Drupal 10 reaches end of life on December 9, 2026, and a project that finishes in 2027 should target Drupal 11 or later. Confirm that your hosting meets the PHP requirement for that version.
How AEM capabilities map to Drupal
This table maps each major AEM 6.5 capability to its closest Drupal equivalent and marks whether the move is largely clean or needs rework or separate tooling. Read the migration notes as a planning checklist, since most rows depend on the content model and the editorial process your team has today. Main takeaway: content structures and identity usually move cleanly, while DAM, forms and editorial workflow design need explicit decisions before cutover.
| AEM capability | Drupal equivalent | Migration notes (clean or needs rework or gap) |
|---|---|---|
| Page templates and components | Content types, paragraph types and Layout Builder or theme templates | Needs rework: component dialogs and Sling models must be redesigned as fields and paragraph types, and templates rebuilt in the theme. |
| Content fragments | Content types with entity references and view modes | Clean for structured fields: map fragment models to content types. Needs rework for nested variations and any AEM-specific headless delivery. |
| DAM assets | Media entities with the core Media module, or a separate DAM | Gap to confirm: core Media covers images and files, but AEM Assets features such as renditions, metadata schemas and asset processing need separate tooling or a confirmed contributed module. |
| Workflows and approvals | Content moderation and workflows modules with custom transitions | Needs rework: AEM workflow models and Workflow Launchers do not transfer, so define states, roles and transitions again and test them with editors. |
| Multi-site and language structure | Multisite setup with shared codebase, plus the core Language and Content Translation modules | Needs rework: map AEM language copies and live copies to Drupal sites and translation sets, and plan URL and redirect structure before content moves. |
| SAML and SSO authentication | samlauth module (8.x-3.14, supports Drupal 10.3 and later and Drupal 11) acting as a SAML service provider | Clean for most enterprise identity providers. Confirm your provider's configuration, attribute mapping and role assignment with your identity team. |
| OpenID Connect sign-in | OpenID Connect module with generic OAuth 2.0 and built-in provider clients, creating accounts on first sign-in | Clean for OIDC providers. Confirm how existing AEM author roles map to Drupal roles, because account creation on first sign-in does not carry over permissions. |
| Page editing | Core editing with content preview, plus Drupal Canvas visual page building (previously Experience Builder) | Gap to confirm: AEM's in-context page editor has no direct equivalent. Drupal Canvas is a newer option, so confirm it meets your authors' needs before committing. |
| Hosting | Drupal runs on Apache or Nginx with MariaDB, MySQL, PostgreSQL or SQLite, on infrastructure you control | Clean from a platform view, but you own hosting, backups, patching and PHP version upgrades, which AEM as a Cloud Service handles for you. |
Which exports, identities and integrations to move
An AEM 6.5 exit to Drupal has four workstreams that run in parallel and fail in different ways. Content, assets, identities and connected services each need their own inventory, owner and acceptance check before cutover. Treat the list below as the starting scope for your own estate, not a finished plan.
Package Manager content export
Content in AEM 6.5 is exported as zip packages in Jackrabbit FileVault format, scoped by filters you define in the repository. Each package carries the node tree and properties for the paths you select, which then become the source for a parser that maps pages and fragments into Drupal content types. Check that every content root in your filters is covered, that previous versions are excluded on purpose, and that the parser output matches a sample of live pages.
DAM asset files and metadata
Binary files and their AEM metadata, such as tags, renditions, descriptions and rights fields, travel separately from page content. Drupal stores assets as media entities with fields you define, so each metadata property needs a target field or an explicit decision to drop it. Confirm with the inventory that asset files, renditions and metadata are all complete, because a package export does not guarantee that every binary or custom property arrived intact.
Users and groups through SAML or OIDC
Do not copy AEM user accounts or password hashes into Drupal. Instead, connect Drupal to your existing identity provider with the contributed SAML Authentication module, which lets the site act as a SAML service provider, or the OpenID Connect module, which creates accounts on first sign-in. Map AEM groups to Drupal roles deliberately, and confirm which dormant or service accounts should be retired rather than carried forward.
Analytics, personalization and translation services
Tag managers, analytics pixels, personalization targets, translation connectors and search indexes usually sit in AEM templates or in code outside the content tree, so a content export will not carry them. List every outbound integration from your AEM templates and client libraries, then re-point each one to the Drupal theme, a module or the external service's new endpoint. Ask each service owner to confirm credentials and event naming before the parallel run starts.
The migration sequence from inventory to decommission
This sequence moves an AEM 6.5 estate to Drupal in controlled stages, so each site is proven on Drupal before traffic moves and AEM is switched off only after the agreed retention period. Each step produces a document or check that the next step depends on.
Inventory templates, components, assets, workflows and sites
Start by listing every site, template, component, content fragment type, DAM folder, workflow, launch and translation setup in the AEM repository. Your AEM developers and content owners should do most of this work, with DeployOpen or your Drupal team reviewing the list for what can be rebuilt as Drupal content types, paragraphs, media and views. The output is a component and template map that marks each item as migrate, rebuild or retire, plus an asset inventory with volumes and access rules. The step is done when content owners have signed off on what is retired.
Define the target Drupal architecture and multi-site structure
Decide how the sites will be organized in Drupal, including whether sites share one codebase with multisite or run as separate installs, how languages and translation are handled, and which contributed modules cover authentication, such as SAML or OpenID Connect where your identity provider requires them. Confirm the target Drupal major version against Drupal's release schedule and the PHP version each release requires. The output is a short architecture decision record that your security and platform teams approve before any build starts.
Build and accept a pilot site on Drupal
Choose one representative site, preferably one with a moderate number of templates and a clear owner, and migrate it using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, feeding in content exported from AEM Package Manager. Themes must be rebuilt rather than migrated, so budget frontend time for this. Run the migration repeatedly until content counts, URLs, media references and workflow states match the source. The output is a pilot acceptance report listing reconciled counts, open defects and the editors who signed off.
Rebuild editorial workflows and roles on Drupal
Recreate the approval paths, publishing roles and permissions that AEM workflows enforced, using Drupal's content moderation and role configuration. Test each path with real editors using the pilot site. Note that AEM workflow history and previous versions are generally not carried over in a standard export, so agree in advance which audit records must be kept elsewhere. The output is a workflow specification and a test log showing each approval path was exercised.
Run the remaining sites in parallel with content sync checks
Migrate the remaining sites in waves and keep AEM running in parallel while editors work in both systems for an agreed period. Schedule repeated delta exports, compare published content, media and metadata between AEM and Drupal, and record every mismatch with an owner. Your security team should confirm that Drupal hosting, backups and access controls meet your policies before production traffic moves. The output is a sync report per site showing zero unresolved content differences before cutover.
Cut over with URL redirects and DNS changes
Prepare a cutover runbook that lists the DNS changes, TLS certificates, cache purges and redirect rules that map old AEM URLs to new Drupal paths. Test the redirect map against a crawl of the live AEM sites and check search engine and analytics tracking. Run the cutover in a planned window with a rollback path that returns DNS to AEM. The output is a signed runbook, a redirect test report and a post-cutover checklist confirmed by the site owners.
Decommission AEM after the agreed retention period
Keep AEM in read-only or archived form for the retention period your legal, records and business teams agree, and confirm the retention length with your contract and compliance advisers. Export final snapshots, store them in your own archive, and confirm the archive can be read. Then cancel or stop the AEM environment and remove credentials and integrations. Check support dates for AEM 6.5 against Adobe's timeline before deciding how long the archive must stay operational. The output is a decommission record that lists what was archived, where, and who approved the shutdown.
How the migration changes with estate size and starting point
A single brand site with a modest number of components and templates is the most contained case. The content tree is usually one hierarchy, the asset library is small enough to review by hand, and the editorial team is often a single group. Most of the effort goes into rebuilding the component library and page templates in Drupal's theme layer and content types, and into agreeing which AEM features the site actually uses. Export scope is simple, so the first sequencing decision is usually whether to migrate content in one cutover or in a short parallel run.
- Component inventory: List each AEM component and count how many pages use it, so unused components are dropped rather than rebuilt.
- Content types: Map page types to Drupal content types with fields, and keep the number of paragraph types small enough for editors to follow.
- Theme rebuild: Plan the front end as a new Drupal theme, since AEM templates and Sling-based rendering do not carry over.
- Cutover: A single site usually allows one redirect map and one DNS switch after a rehearsal import.
- Hosting: Run a single Drupal instance on infrastructure you control, sized to traffic rather than to the old AEM footprint.
Before you start, confirm with your own team which AEM components and workflows are actually in use on the live site, because a small site can still hide custom components that need a full rebuild.
A multi-site, multi-language estate with a large DAM is the case where scope grows fastest. Each site may have its own tree, but shared components, shared assets and translation links between language versions create dependencies that must be understood before any import runs. Drupal's multisite model and language layer can represent this structure, but the decisions about shared versus site-specific content need to be made early, because they shape the content model and the migration order.
- Shared versus local content: Decide which blocks, taxonomies and assets are global and which belong to a single site, before mapping anything.
- Translation records: Confirm how AEM language copies and their translation status will be exported and linked to Drupal translations.
- DAM volume and metadata: Plan asset migration in batches by folder or site, and verify metadata and renditions on a sample before the full run.
- Sequencing: Migrate a shared core first, then sites in an order chosen by traffic or business risk, with each site tested against its own redirects.
- Governance: Assign owners for each site so that editorial permissions and roles are rebuilt per site, not copied from AEM groups.
Ask the implementation partner to show how a sample multi-language page moves end to end, including its translations and assets, before agreeing the schedule.
An estate with heavy AEM workflows, approval chains, launches or Adobe Forms depends on processes that sit outside page content. Drupal can express approval steps through the content moderation and workflow ecosystem, but AEM workflow models, custom process steps and form logic are code assets that must be documented and redesigned, not exported as content. This case adds a discovery phase and usually separates the content migration from the process rebuild, so that each can be tested on its own.
- Workflow inventory: Document every AEM workflow model, its triggers, participants and custom steps, and mark which ones are still needed.
- Forms decision: Decide whether forms move to a Drupal form solution, a separate form service or a remaining Adobe product, since Forms data and rendering do not map one-to-one.
- Process ownership: Assign business owners to approve the redesigned workflows, because approval rules often exist only in configuration.
- Integration points: List systems called by workflows, such as translation services or publishing hooks, and rebuild each integration with its own tests.
- Audit trail: Confirm which approval records must be retained and how they will be preserved from the AEM environment.
Before committing to a schedule, ask which workflows and forms are business-critical, and whether any of them must keep running in parallel during the transition.
What drives cost and duration, and how to keep each down
An AEM to Drupal move is priced and scheduled by a handful of drivers that interact: how much is being moved, how messy the source is, and who does the work. Each card below names one driver, why it raises effort, and what to ask for in a written quote so the cost components stay visible.
Component and template count
Every AEM component, template and editable area usually needs a Drupal equivalent: a content type, a paragraph or block type, or a view mode. Estates with many near-duplicate components cost more to map than the number suggests, because each variant has its own dialog fields and rendering logic. Reduce effort by consolidating components before the move and asking the partner to price the mapping as a list of units in the quote, so you can cut scope.
Asset volume and metadata quality
DAM migration cost rises with the number of binaries, renditions, and the completeness of AEM metadata such as tags, titles, rights and usage notes. Assets with missing or inconsistent metadata need either manual review or rules that guess, and both take editorial time. Clean metadata in AEM before export, decide which renditions are regenerated in Drupal, and agree in writing whether the partner or your team owns the review of exceptions.
Workflow complexity
AEM workflows that include approvals, translation hand-offs, scheduled publishing or custom Java steps do not carry over automatically. Each workflow must be redesigned using Drupal content moderation, state transitions and any contributed modules you choose, and each step needs test cases with the editors who use it. Limit the first release to the workflows that businesses rely on, and treat the rest as later phases.
Number of sites and locales
Each additional site, brand or language multiplies the work for information architecture, redirects, translated content and menu structures. Drupal's multi-site approach is a shared codebase with separate configuration and content, so shared components reduce duplication only if they are designed early. Ask the partner to state how many sites and locales are in scope and how translations will be migrated and checked.
Integrations and authentication
Connections to CRM, marketing tools, search, commerce and identity providers are often the longest part of a migration because each one has its own data contract and failure modes. Authentication is a common example: a Drupal site that must sign users in through your identity provider can use the contributed SAML Authentication module or OpenID Connect module, and each choice needs testing against your identity setup. Inventory every integration and mark it as rebuilt, replaced or retired.
Team skills and cost components
Costs fall into a few groups: internal staff time for content, decisions and testing, partner fixed-scope work for export, mapping and build, hosting, and recurring support and upgrades. Drupal core and contributed modules are GPL and carry no license fee, so the recurring spend is mainly hosting, people and support. Internal PHP and Drupal skills reduce the ongoing support line, and a written quote should separate one-time migration work from recurring hosting and retainer fees.
What usually goes wrong and how to prevent it
What happens if AEM workflows and components are not mapped before the build starts?
Unmapped scope is the most common cause of late surprises. Teams discover custom workflows, approval chains, scheduled activations and bespoke components only after the Drupal build is underway. Prevent it by inventorying every AEM component, template, workflow model, launcher and servlet that editors touch, then tagging each item as rebuilt, replaced by a contributed module, dropped or deferred. Agree that inventory in writing before estimating work, and treat any item without an owner as open scope.
How do you stop asset metadata from being lost during the DAM move?
Asset files usually move easily, but their metadata, renditions, tags, rights fields and folder context often do not. Export assets and their properties separately from content, map each AEM metadata schema to Drupal media fields, and confirm which rights and licensing fields must survive for legal or brand reasons. Run a sample migration of several hundred representative assets and compare checksums, dimensions, tags and usage references before the full run.
Will changing URL structure break search rankings and inbound links?
Yes, unless redirects are planned as a deliverable. Drupal's path aliases and content types rarely mirror AEM's page tree, so URLs often change even when content is identical. Export the current URL list from analytics and server logs, map each old path to a new one, and implement 301 redirects in your web server or a redirect module. Keep the sitemap, canonical tags and search console properties updated, and check redirect coverage on the highest-traffic pages before cutover.
Why do PHP and Drupal version changes matter during a multi-year build?
Drupal versions move on fixed schedules, and a project started on one version can land on an end-of-life branch before launch. According to the Drupal core release schedule, Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Drupal 12 requires PHP 8.5 or later, per the Drupal.org PHP requirements page. Decide the target major version at project start, pin PHP and database versions in your hosting plan, and budget for bugfix and security releases that arrive monthly and on the third Wednesday cadence.
What causes editors to resist the new Drupal authoring experience?
Adoption gaps appear when editors lose the AEM page editor, in-context previews or familiar review steps and no one trained them on the replacement. Involve a group of editors in content model reviews early, map each editing task they perform today to a Drupal equivalent, and test the authoring screens with real drafts from your content. Plan role-based training, a written editorial guide and a support path for the first months after launch. Ask your Drupal partner to show how Drupal CMS features, such as its visual page builder, fit your authoring needs, and confirm they are stable for your use.
How long should AEM and Drupal run in parallel, and what does that cost?
Plan the parallel run as a funded phase, not an afterthought. Both platforms stay live while content, redirects, integrations and approvals are verified, and both carry hosting, licences or support, and staff time. The length depends on how many sites, locales and integrations you migrate and how often content changes during the transition. Ask for a written cutover plan that names the freeze window, the delta sync method for content changed after export, the rollback criteria and who signs off each stage.
Can our own team handle the migration without outside help?
Some teams can, especially where they already run Drupal and have staff who know the Migrate modules and Drush. Most gaps come from skills that are thin on the team, such as parsing FileVault packages, rebuilding workflows and running security checks. Before deciding, list the roles you need: Drupal architect, migration engineer, frontend developer, security tester and editorial lead. Mark which ones you already have, and ask any partner for a fixed-scope proposal that lists deliverables and responsibilities in writing.
Does a migration to Drupal remove the need for security testing?
No. Moving to a new platform introduces new modules, integrations and hosting layers that need testing before launch. Plan application and API testing of the new site, review contributed modules and their security advisories through the Drupal Security Team process, and check SSO integrations such as SAML or OpenID Connect configuration. Schedule a test after the first full content load and again before cutover, and track findings to closure.
How DeployOpen scopes and runs an AEM to Drupal migration
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For an AEM 6.5 to Drupal move, that means agreeing the content scope, component mapping and asset plan in writing before rebuilding, then handing over a Drupal estate your team can operate after the project closes.
How we scope
- Inventory AEM sites, content paths, templates, components, workflows and DAM folders before any build work starts.
- Agree in writing which sites, locales, content fragments and assets move, and which are retired or left in place.
- Confirm the target hosting, PHP and database versions, plus where the Drupal site will run in your environment.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins; ask for the scope document in any quote.
How we build
- Map each AEM template and component to Drupal content types, paragraphs or layout components, and record the decisions.
- Build the Package Manager export and import pipeline, then test it on a subset of pages before full runs.
- Move DAM assets with metadata and redirects, and rebuild editorial workflows and multi-site structure in Drupal.
- Test content accuracy, URL redirects, access rules and authentication, including SAML or OpenID Connect integration where your identity provider requires it.
How we hand over
- Document the content model, migration scripts, theme structure, deployment steps and rollback procedure for your team.
- Deliver backup and restore runbooks for the Drupal database and file system, tested before cutover.
- Train editors and administrators on the rebuilt workflows, roles and multi-site setup against the agreed scope.
- Provide a list of open items, retired AEM components and features that were not carried over, so nothing is left implicit.
How we support
- Run post-cutover checks on redirects, search indexing and content parity against the signed-off inventory.
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the migration.
- Plan Drupal core and contributed module upgrades around the published Drupal release schedule with your team.
- Confirm with us any compliance evidence you need; DeployOpen prepares systems and records, while independent auditors issue any attestations.
