What you can export from Adobe Experience Manager, and what you cannot
If your AEM 6.5 renewal, support date or exit decision is driving this work, start by treating Package Manager as a tool for moving repository content, not for copying the whole instance. Package Manager exports repository content as Jackrabbit FileVault zip packages, and you choose what goes into each package with filters that define the paths to include. Version history, some runtime configuration and anything held in systems outside the JCR repository, such as external databases, search indexes, workflow engines tied to other services, third-party integrations and user credentials, need separate handling. Plan those as their own inventory items before you assume the packages are complete.
The export is a working copy for import, not a full backup of the running instance. It gives you a structured snapshot you can parse and load into a target CMS such as Drupal or Wagtail, but it will not restore a broken AEM author or publish server. Keep your existing backup and disaster recovery process running until the cutover is complete and the old environment is retired. Confirm with your AEM administrator which backup method your team already uses, and whether it covers the file system, the repository and the database that sits beneath it.
Before you run a large export, check the package filters against your site tree, your DAM folders and your content fragment models, and record which paths you deliberately excluded. Ask Adobe or your partner to confirm the exact export options and package sizes for your version and service pack, because these depend on your estate. The useful check is a small test package from one site section, imported into a scratch environment, compared item by item with the source. That test shows the gaps early, while the decision on what to rebuild is still open.
Which AEM data types export, by method, format and limits
This table shows how each main AEM data type is packaged, which filter scope applies and what the export leaves out. Read it as a checklist for planning separate packages per data type. Confirm every limit against your AEM version and Adobe's current Package Manager documentation before you run an export.
| Data type | Export method | Format and scope | Limits to confirm |
|---|---|---|---|
| Pages | Package Manager with a filter on the site content root | Zip package in Jackrabbit FileVault format, with a filter.xml listing the content paths | Only the current revision of each page is included, and page version history is not exported |
| Components | Package Manager with a filter on the component definition paths | Zip package holding component definitions, usually under /apps or /libs | Component rendering code is Java or HTL that must be rebuilt in the target CMS, so the package carries structure, not behavior |
| Content fragments | Package Manager with a filter on the DAM path where fragments are stored | Separate zip package, kept apart from page content and DAM binaries | Fragment models and their data should be checked in the package, and any references to other assets need a separate pass |
| DAM assets | Package Manager with a filter on the DAM folder, one package per folder or batch | Zip package containing asset binaries and metadata, in FileVault format | Package size and file count grow quickly, so split large folders into several packages and confirm the upload limits for your version |
| Tags | Package Manager with a filter on the tag repository path | Zip package of tag nodes with titles, descriptions and IDs | Tags referenced by pages or assets must be exported too, or those references break on import |
| Editable templates | Package Manager with a filter on the templates configuration path | Zip package of template definitions and their allowed components | Templates define structure only, so policies and style configuration need confirmation in your installation |
| Workflow and user data | Not covered by a standard content filter, so confirm with Adobe | Handled outside the content packages, if at all | Users, groups, workflow instances and permissions must be confirmed separately, with a plan for re-creating them in the target system |
Why previous versions and some data do not come with the package
A Package Manager export carries the current state of the paths you select, and little else. Version history, user accounts, in-flight workflows, OSGi configuration and third-party integrations sit outside that scope, so each needs its own decision before the source environment is retired.
Version history stays behind
Package exports capture the current revision of each node under the selected filters, not the version history that AEM keeps for pages and assets. Decide now which history you need, such as legal holds or published-page revisions for audit. If you need older states, export them separately, for example by capturing a snapshot of published pages or by archiving the source repository before decommissioning. Confirm with your AEM team which retention settings apply in your environment.
User accounts and groups
Users, groups and their permissions live in the repository's security area and are not part of a content package scoped to content paths. Your Drupal or Wagtail target needs its own accounts, and passwords cannot be moved in the export. Build a list of active editors, their roles and their groups from your identity provider or the AEM user console, then map each role to a target role before cutover.
Workflow instances in flight
Running workflow instances, such as approvals waiting on a reviewer, are runtime state rather than content. A package carries the workflow model definitions only if you include them, not the open instances. Before the final export, ask editors to finish or cancel pending approvals, then record the open items in a spreadsheet so they can be recreated manually in the new CMS.
OSGi configuration
Settings for services, replication agents, dispatcher-related values and other OSGi components are typically stored in configuration nodes that you must choose to package deliberately. Some values are environment-specific or hold secrets that should never leave the source system. Document each configuration that affects behavior, such as URL mappings, translation settings and cache rules, and rebuild the equivalent in the target platform.
Third-party integrations and audit data
Connections to translation vendors, analytics, search indexes, forms tools and external APIs are configured outside the content tree and often rely on credentials that cannot be exported. Audit logs and replication history are also separate records. Inventory every integration with its owner and endpoint, and export audit logs to your own archive if compliance requires them. Confirm with each vendor how their keys can be rotated for the new platform.
The export sequence and how to verify each package
This sequence turns a loose AEM content estate into a set of Package Manager exports, each with a recorded inventory and a verification result, so the source instance can be retired only after the content has been checked. The steps run on a copy or staging author instance, not on production.
Inventory the content paths and dependencies
The content owner and an AEM developer list every content root in scope, including site trees, the DAM folder structure, content fragment models and fragments, tags, and the configuration nodes that pages depend on. Record which paths belong to each site and which ones are shared across sites. The output is a written inventory with one row per root path and an owner for each. The step is done when the owner signs off that nothing in production content sits outside the list.
Define separate filters for each package
Write one Package Manager filter set for site content, one for assets, and one for content fragments, so each package can be imported, tested and rolled back on its own. Keep filter files in version control next to the inventory. Confirm the filter paths against the inventory, and check that the content fragment filter includes the models it depends on. The output is three filter definitions, each traceable to inventory rows.
Prepare a copy or staging author instance
Run the exports against a copy or staging author instance refreshed from production, so that the live site is not affected by heavy read operations and the source stays unchanged during export. Note the date of the copy and any content changes made after it, because those changes will not be in the packages. The output is a documented source snapshot that the verification steps can refer to.
Run the Package Manager exports
An AEM administrator builds each package from its filter set in Package Manager, then downloads the zip. Use the same filter file for every run, and record the AEM build version, the package name and the time of each build. Remember that Package Manager exports the current revisions of nodes, so previous versions of pages and assets are not included and must be exported or archived separately if they are needed. The output is three zip files in Jackrabbit FileVault format, each with a build record.
Record checksums and package contents
Generate a SHA-256 checksum for each zip and store it beside the package in a controlled location. Open each package's META-INF folder and the filter definition to confirm the root paths match the inventory. Produce a list of every file path inside the package, plus a count of content nodes and binary files. The output is a manifest per package, and the step is done when the checksum and manifest are filed with the inventory.
Sample pages and assets against the source
Select a sample of pages across each site and a sample of assets across the main DAM folders, then compare them with the source instance. Check the page titles, text properties, component properties, asset metadata, renditions and tags, and open a few referenced assets to confirm the binaries are present. Choose the sample with the content owners so that high-traffic and high-risk pages are included. The output is a signed sample log with each mismatch recorded and resolved before the next step.
Compare node counts and references
Parse each package with a script that counts nodes by type and lists every reference, such as asset links, fragment references, tag references and internal page links. Compare those counts and the reference list with the same queries run against the source. Investigate any difference, since missing references usually point to content outside the filters. The output is a reconciliation report that lists counts by type and any unresolved references. The step is complete when the report has no unexplained differences.
Retire the source only after sign-off
Before any AEM instance is decommissioned, the content owner, the migration lead and the security owner review the inventory, checksums, sample log and reconciliation report together. Archive the packages, manifests and reports in storage the organization controls, with retention set by its own records policy. Confirm with legal or compliance teams that the archive meets their requirements. The step is done when the sign-off is recorded and the archive location is documented.
How to parse the packages for import into Drupal or Wagtail
A FileVault package is not an import format that Drupal or Wagtail reads directly. Each package holds XML descriptors, typically .content.xml files, that describe nodes and properties in the AEM repository, plus binary files for assets and renditions. Parsing turns that structure into records your target system can create. Plan this as a transformation step with its own developer time, separate from the export itself. The export only moves the raw material out of AEM, and the mapping work starts once you open the packages.
Start with a mapping table that links each source path pattern to a target content type. For Drupal, the usual route is a custom source plugin built on the core Migrate framework, with the Migrate Drupal UI modules available for upgrade-style runs, so each content path becomes a migration with its own field mappings. For Wagtail, a Django management command that reads the XML and creates page models through the API is the common pattern. Keep asset binaries and content records in separate passes. Import images and documents first so content records can reference them by ID. Confirm with your developers which AEM component properties carry the text you need, because AEM stores many values as component-specific properties that the mapping must name explicitly.
Record the original AEM path for every migrated page and asset in a column or field you can query later. These source paths are the input for your redirect map, so losing them forces guesswork when you rebuild URLs. Decide early whether redirects live in the new CMS, at the web server, or in a separate table, and test a sample of old URLs against the new site before cutover. Ask your team to confirm how the packages will be stored and versioned during parsing, because re-running a migration with changed mappings is normal and each run should be repeatable.
What to plan before the AEM contract ends
Renewal and termination decisions for AEM 6.5 depend on dates that fall well before the contract ends. Each card below names one decision, the document that should record it, and what to check before the export starts.
Core and extended support dates
Core support for on-premise AEM 6.5 runs until February 28, 2027, and extended support with critical fixes only runs until February 28, 2028. Record in the renewal order which date your contract assumes, and whether the vendor or partner will confirm in writing that patches and security fixes continue through the export window. Ask how the support end date affects the license term you sign.
Full export run and verification plan
Plan a trial export of the whole content tree, DAM and content fragments before the final run, then time it and record the package sizes and any filters that failed. Keep the verification checklist in the project plan, covering node counts, page counts and sample renders on the target. Ask the vendor or partner to commit in writing to the export method and the acceptance criteria.
Retention rules for exported packages
Exported packages contain your editorial history and customer-facing content, so they need a named owner, an encrypted storage location and a retention period set by legal and records teams. Record where the packages live, who can read them and when they are deleted. Confirm that the retention rules also cover the copies made during test runs and the parsed intermediate files used for import into Drupal or Wagtail.
Access to the source instance
Your team needs read access to the AEM author and publish instances, the Package Manager console and any replication or workflow data for the full export window. Record the account names, the access expiry date and the change control rule for the source system. Confirm in writing who can take a snapshot or restore a backup if an export fails near the contract end.
Vendor or partner delivery terms
Put the deliverables in a signed statement of work: the export packages, the file inventory, the mapping documentation and the verification report. State who parses the packages, what format the output takes and how defects found after handover are handled. Ask for a fixed scope and written timelines before any work starts, so the export is not left to an open-ended engagement.
Questions buyers ask before exporting AEM content
How much does exporting content from AEM cost?
The export itself is a download from Package Manager, so the cost sits in the work around it. Expect one-time costs for AEM admin time to define filters and build packages, engineering time to parse FileVault XML and map it to the target structure, asset handling, and QA and sign-off. Recurring costs come from the target hosting, not from the export. Volume, the number of component types, custom components with bespoke properties, asset count and size, locales, and any requirement to keep version history all push the cost up. Ask for a quote built from a written scope that lists the filters, estimated volumes by content type, the deliverables, whether binaries are included, and the acceptance criteria.
How long does an AEM content export project take?
No duration applies to every estate, so ask for a schedule rather than a generic figure. The timeline depends on repository size, the number of packages and filter sets, how many custom components need mapping, and whether asset binaries move in the same pass. Plan the export inside the AEM lifecycle: core support for on-premise AEM 6.5 ends on February 28, 2027, and extended support with critical fixes runs until February 28, 2028, according to Adobe's support timeline. Work backward from those dates, and ask any provider for phases with dependencies, test cycles and sign-off gates in the written scope.
What does the export need from our AEM team?
Three things make the export work, and each needs a named person:
- Package Manager access on the author instance with rights to create, build and download packages. Confirm with your AEM administrator which roles and paths are permitted.
- Repository knowledge of the content tree, templates, components, the paths that hold content fragments and the DAM folder structure, including which sites and locales are live.
- Sign-off from content owners on what is in scope, plus a reconciliation sample they check after import.
Without these, the team will spend time discovering scope that should have been agreed up front.
Can an internal team export AEM content without outside help?
Yes, for a small, well-understood repository with an administrator who already uses Package Manager and a developer comfortable reading XML. The work gets harder with several sites, many custom components, legacy paths or a large asset library. Before deciding, confirm who will build the filter sets, who will write the parser, how the team will verify the result, and how much time those people can release from current work. If you want outside help, DeployOpen plans and implements self-hosted platforms under fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope.
Are AEM assets and content fragments exported the same way?
No. Treat them as separate workstreams with separate filters and acceptance tests. Content fragments are structured data that map to content types or models in the target system. DAM assets are binary files with metadata, folder structure and renditions, and they need a decision on which renditions to keep and how to store the files. Package Manager scopes both through filters, so define one filter set for fragments and another for assets, then confirm that the asset metadata and references survive the move. Ask the provider to show how asset links are rewritten in content.
Why are previous versions missing from AEM content packages?
Package Manager packages carry the current content under the filters you choose, and previous versions are not included. If audit, editorial or legal requirements depend on history, decide that before export and capture it another way, such as a documented archive or an agreed snapshot. Confirm the retention requirement with your compliance lead and your records owner, and record the decision in the scope document. Do not assume that an import will recreate revision history in the target CMS.
How do we parse AEM packages for import into Drupal or Wagtail?
AEM packages are zip archives in Jackrabbit FileVault format. Unzip them, then read the metadata and the content XML under the jcr_root folder to find node types, properties and child nodes. Map each node type to a Drupal content type or a Wagtail page model, and map component properties to fields or StreamField blocks. Drupal's core Migrate modules provide a framework for this, but the source plugin for AEM packages is usually custom, so confirm that scope with the team doing the work. Test the importer on a subset of paths before running the full set, and keep the scripts under version control so the import can be repeated.
Doing the export in-house or with an implementation partner
Your AEM administrators should run the export themselves, because they hold the repository access, the service accounts and the Package Manager permissions that the work depends on, and because they know which content trees carry business meaning. Keep ownership of credentials, the decision on which paths and content types leave the repository, and the final sign-off on what the new system must hold. Confirm with your Adobe contact which AEM 6.5 deployment you run (on-premise, Managed Services or another setup), since that determines who can reach the author and publish instances and where the packages can be stored.
A fixed-scope engagement with an implementation partner typically covers the parts that take the most specialist judgment: writing filter definitions for each package, building the scripts that parse FileVault packages into the target structure for Drupal or Wagtail, running verification that compares counts, paths and asset checksums between source and target, and documenting what was exported, what was excluded and why. The written scope should name each deliverable, the target platform, the content trees in and out of scope and the acceptance checks. Ask any partner to state in that scope whether it includes work that touches your production instances. Verification output and documentation support your own review, but they are not an audit report or a certification, and you should ask your auditors what evidence they expect from a migration.
Cost is driven by the number of content trees, the volume of assets, the number of locales and the amount of custom component logic that the parsing scripts must handle. Your internal costs recur in the form of admin time and storage for packages, while a partner quote is usually a one-time figure tied to the agreed deliverables, with optional retainers for later support. Before you sign, ask for the list of deliverables, the verification method, who holds the scripts and documentation after handover and what happens if the export reveals content your scope did not anticipate.
How DeployOpen scopes and delivers an AEM export
DeployOpen treats an AEM export as a fixed-scope engagement with written deliverables, not a one-off script. We agree which content trees, asset folders and content fragment models are in scope, then build, test and document the packages so your team can take them into the target platform.
How we scope
- Inventory the content trees, DAM folders and content fragment models your team needs to keep, with owners named for each.
- Agree the Package Manager filter sets in writing, including which paths are excluded and why.
- Record which previous versions, workflows and user-generated data are outside the export so expectations are set before work starts.
How we build
- Create Jackrabbit FileVault packages scoped by the agreed filters, and keep assets and content fragments in separate packages.
- Write parsing scripts that turn package contents into structured files ready for import into Drupal or Wagtail.
- Test each package on a copy of the AEM 6.5 instance and check counts, paths and binary references against the inventory.
How we hand over
- Deliver a field-level mapping document and a record of every package, filter and checksum used in the export.
- Document known gaps, such as content that did not export cleanly, so your editors and developers know what to rebuild.
- Walk your technical team through re-running the export, so the process does not depend on DeployOpen staying involved.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial export is delivered.
- Retainers can cover re-exports during a staged cutover, when content keeps changing on the AEM side.
- Confirm with DeployOpen in the written scope which support hours, response terms and exit tasks apply to your engagement.
