Exporting content from Sitecore starts with serialization, not a backup
If you face a renewal, a SitecoreAI decision or a data residency requirement, know this first: Sitecore Content Serialization can pull content items, roles and users into YAML files, but xDB, personalization rules and analytics have no documented export path. That split decides your migration plan more than any other factor. The serialized files give you a portable copy of the content tree and its supporting definitions, which an open-source CMS team can read and map. Everything outside that tree must be rebuilt from scratch or archived separately.
The export is a file-based copy, not a database dump. The Sitecore CLI command sitecore ser pull writes items from a running instance into the file system, and the output lands in a serialization folder relative to each module file. Module files, configured with includes and excludes, decide which parts of the tree are captured. A content item that sits outside a module's include rules will not appear in the YAML, so review those files before you run the pull. Run sitecore ser diff afterward to confirm what the files contain against the live instance.
Plan for the gaps now. Ask your Sitecore partner or account team, in writing, what a documented export path exists for xDB contact data, personalization rules, experience analytics and email marketing content, and whether any of it can be archived in a readable format. Your legal and records teams should decide how long those records must be kept, because once the instance is retired, the rebuilt tools will not hold the historical data. Treat the serialized YAML as your content archive and test a restore into a non-production environment before you rely on it.
What Sitecore Content Serialization exports and how
This table lists each data type that Sitecore Content Serialization covers, the command and file format used to export it, and the settings that control its scope. Read the scope rows first, because module files decide what is included. The main takeaway is that serialization captures the content tree you configure, while xDB and personalization data need a separate export plan.
| Data type or setting | What serialization does | What to confirm |
|---|---|---|
| Content items | Serialized to YAML files with sitecore ser pull, written to the project file system | Which item paths your module files include and exclude |
| Roles | Can be included in serialization through module configuration | Which roles your team relies on and whether each is listed in includes |
| Users | Can be included in serialization through module configuration | Whether user accounts are in scope and how you handle sensitive account data |
| File format | Each serialized item is stored as a YAML file that can be diffed and reviewed | Whether your review and version control workflow reads YAML cleanly |
| Default folder | Stored by default in a serialization folder relative to the module file | The folder path your module file sets in your own project |
| Includes and excludes | Module files define which items, roles and users are in scope | Item-level limits depend on the module configuration your team has in place |
| Commands | sitecore ser pull exports; push, diff, watch and package commands sit alongside it | The CLI version your team runs and the commands your pipeline uses |
| xDB, personalization rules and analytics | Not covered by content serialization; the SitecoreAI migration guide says xDB data and personalization must be rebuilt | A separate export or rebuild plan, confirmed with Sitecore and your analytics owner |
How module files decide what leaves Sitecore
Serialization scope is set by module files, so an export only contains what those files name. Each module file declares the items, roles and users to include and the paths to exclude. When the team runs sitecore ser pull, the CLI writes YAML for whatever the module files select and nothing else. Content that sits outside the declared tree stays in the Sitecore database and never reaches the file system. Before any pull, the team should read every module file and write down, in plain language, which site roots, template folders, media libraries and security items it is meant to capture. Compare that list with the content tree in the Sitecore content editor so the scope is a decision, not an accident of how the files were first written.
Next, audit for drift. Look for includes that point at paths that have since been renamed or moved, excludes that are broader than intended, and content created by editors under a root that no module file covers, such as landing pages added to a new branch of the tree. Run sitecore ser diff against the instance so differences show up before anything is pulled, and check that roles and users are included only where the team intends them to leave the instance. Confirm the scope with the owners of each site, because they usually know about content that the module files do not mention.
An incomplete module file is the most common cause of a silent gap. The pull finishes without errors, the YAML folder looks full, and the team assumes the estate is captured. The risk is that a missing include removes whole branches from the export with no warning. Treat the first export as a hypothesis to test: count items in the Sitecore tree under each root, compare with the serialized files, and keep the report with the migration record. Anything still unexplained after that comparison is a scope gap to fix before the exit depends on the export.
What has no export path and what to do about it
Content Serialization moves items, roles and users out of Sitecore, but the data that drives personalization and marketing sits in other systems. Sitecore's migration guide says xDB data, email marketing content and personalization do not migrate to SitecoreAI and must be rebuilt. The cards below cover each gap, what to archive now, and what to confirm with Sitecore for your own version.
Contact and interaction data in xDB
xDB holds contact profiles, interaction history and the visitor data that segments and rules depend on. Serialization does not export it, and Sitecore's migration guide says xDB data does not migrate to SitecoreAI. Before any decommissioning, ask Sitecore which xDB collections and exports your version supports, and whether you can take a full copy. If you need the history, plan a separate archive with its own retention and access controls, and record who approved it.
Personalization rules and segments
Personalization rules, segments and goals are tied to xDB and the Sitecore rules engine, so they do not carry over as data. Document each active rule, its audience, the content it changes and its success metric from the Sitecore console before you change anything. Then rebuild the logic in your new CMS or a targeting service. Treat the rule inventory as a deliverable, because it is the only record of what each visitor experience did.
Analytics and reporting history
Historical analytics reports and dashboards are generated from xDB and Sitecore analytics, not from content items. Export the report data you need for audit or trend comparison while the instance is still running, in whatever format your version allows. Then load the historical figures into an open-source analytics store, such as Matomo, so future reporting does not depend on Sitecore. Mark clearly which periods come from which system.
Email marketing content and send history
Email marketing content, templates and send history from XP's email marketing features sit outside the content tree that serialization covers. Export the templates you still need as HTML and copy the subscriber lists under your own privacy basis, then confirm with Sitecore which email components your version exposes. Sitecore's migration guide notes that email marketing content does not migrate to SitecoreAI, so plan a rebuild in a self-hosted tool such as Mautic.
Forms, submissions and consent records
Form definitions can be serialized, but submitted data and consent records are stored separately in the Sitecore database. Those records often carry legal and retention obligations, so they need an owner before migration starts. Ask Sitecore what export options exist for form submissions in your version, and decide where the archive will live. Map each form field to its new target before the cutover so no submission data is lost in transit.
The sequence for a complete export and how to verify it
This sequence turns a Sitecore estate into a version-controlled set of YAML files, with a check at each stage that proves the export is complete before anything leaves the source instance. It also makes clear what must be archived separately, because Content Serialization does not carry it.
Inventory every module file and its includes
A Sitecore developer lists each serialization module file in the solution, then records which item paths, roles and users each one includes and excludes. The output is a written inventory, reviewed by the developer who owns the Sitecore solution, that shows which parts of the content tree are in scope. You know this step is done when every path you expect to migrate maps to at least one module file, and any gap is either fixed or recorded as out of scope. Confirm the current include and exclude syntax against the Sitecore Content Serialization structural overview before you edit anything.
Confirm the serialization folder and its location
The developer checks where the serialization folder sits relative to each module file, since Content Serialization stores YAML there by default. The check is a directory listing of the project's serialization folder that matches the module inventory from the previous step. If the folder is missing items or sits outside source control, fix the path now, because a wrong location produces an incomplete export that looks successful.
Run a pull against a non-production instance first
The developer runs the Sitecore CLI command sitecore ser pull against a non-production instance that holds a recent copy of the content. Running it here first keeps the source of truth untouched and shows how long the operation takes in your environment and whether any module file errors out. You know it worked when the command completes without errors and the serialized YAML files appear in the expected folders. Repeat the pull against the production-equivalent instance only after this run is clean.
Commit the YAML to version control
The team commits the serialized YAML to the repository in a dedicated export branch, with the instance name, date and module inventory noted in the commit message. This creates an immutable record that the content team, auditors and the target platform team can all reference. The check is that the repository history contains one commit per pull, and that a fresh clone reproduces the same file tree. Store the repository in infrastructure you control, not only with a hosted Git provider you do not manage.
Run a diff to compare the export with the instance
The developer runs sitecore ser diff against the instance to confirm that the files on disk match the items in Sitecore. Any difference listed means the export is stale or that an item changed after the pull. The check is an empty diff result for every module in scope. If differences remain, pull again, commit the update and repeat the diff until the result is clean, then record the final commit as the export baseline.
Archive the data that serialization does not carry
The team takes separate archives of data outside the serialization scope, including xDB contacts and interaction data, analytics, personalization rules, email marketing content and any database or media storage that sits beyond the YAML files. Each archive gets a checksum and a short written record of what it contains and who approved it. The check is that every archive opens and its checksum matches the stored value. The Sitecore migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, so these archives are the only copy you will have of that material.
Verify item counts and media references in the target
After the YAML is loaded into the target platform, the migration team compares item counts per content type against the diff baseline and checks that every media reference resolves to a file that exists. Mismatches are logged and traced back to a module file or to a media path. The output is a signed-off reconciliation sheet for each site and language. This verification is the evidence that the export is complete, so keep the sheet with the commit baseline and the archives.
Questions teams ask before exporting from Sitecore
Can our own team run Sitecore Content Serialization without outside help?
Yes, if you have developers who already work with Sitecore and can run the Sitecore CLI against your instance. Content Serialization is a documented developer tool: the command sitecore ser pull writes items from a Sitecore instance to the file system, and push, diff, watch and package cover the rest of the workflow. The harder part is judging what the module files should include, which depends on how your solution was built. Teams with no Sitecore developers usually need a partner for the first export and the mapping work. Confirm your team's skills against the Sitecore documentation before deciding.
What drives the effort of a Sitecore content export?
Effort follows the shape of your estate rather than a fixed step count. The main drivers are:
- Module file complexity: how many includes and excludes you maintain, and how many items each one scopes.
- Media volume: the number of assets and how they are stored.
- Number of sites and languages: each site, language version and shared content tree adds mapping and verification work.
- Custom templates and renderings: items that depend on custom code need review before they can be read by another system.
Ask for a written inventory of these four items before agreeing on scope, since they determine most of the cost of the export.
What access and setup does an export need from our side?
You need read access to the Sitecore instance you export from, a working Sitecore CLI installation in the solution, and the module files that define the serialization tree. You also need developer time to run the pull, review the YAML output and check that the folder structure matches your module scopes. Access to the source code repository is important because the serialized files should be reviewed alongside it. Confirm with your Sitecore administrators which environment holds the authoritative content, and whether production or a staging copy is the right source for the export.
How long does a Sitecore serialization export take?
No duration is documented for this process in the supplied Sitecore material, so any number you hear should be checked against your own environment. The time depends on how many items fall within your module scopes, how many languages you export, and how much review your developers need before the output is trusted. Ask for a timeline based on your inventory and a trial pull on a copy of the instance, and treat that trial as the basis for planning.
Does Sitecore Content Serialization export media files and binaries?
The documented behavior of Content Serialization describes items, roles and users written as YAML files, configured by includes and excludes in module files. Whether media binaries, such as image and document files, are written to the file system in your version and configuration is not covered by the supplied facts, so confirm it in the Sitecore documentation and in a trial export. If media files are not included, plan a separate export of the media library, and check that the references in the YAML still resolve after the move.
What happens to xDB history, personalization rules and analytics during export?
They do not come out through Content Serialization. Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, which must be rebuilt. Serialization covers content items, roles and users, so contact data, visitor history, analytics and personalization rules stay behind in the XP environment. Keep the XP databases under retention until you have decided how to archive that data. Your compliance team should confirm the retention and privacy obligations that apply to contact records before any deletion.
Should we export content before deciding on a replacement platform?
Usually yes, because a serialized export of content items is useful regardless of where the content ends up. It gives you a versioned copy of the content tree, a way to review what is in scope, and evidence of what was exported. It does not replace the planning work: templates, renderings, forms and personalization still need decisions. Treat the export as a first milestone with a written scope, so the decision on the target platform is based on a real inventory rather than assumptions.
What to plan before the Sitecore contract ends
Most of the export work is decided before the final pull. The decisions below sit with different owners, from engineering and content operations to legal, and each one changes what you can export and when. Confirm contract terms with your own legal team before acting on any of them.
Confirm version and export tooling
Record the exact Sitecore version in production, along with the Sitecore CLI version and the serialization module files your team uses. Check that the CLI release you plan to use supports that version, because the sitecore ser pull workflow depends on the project structure and module configuration in place. Run a test pull against a non-production copy and compare the file count and tree with the live content tree before you rely on it.
Confirm retention rights for analytics
Ask Sitecore in writing what happens to xDB contacts, interaction data and analytics reports when the contract ends, how long they stay available, and in what format they can be retrieved. Sitecore's migration guide states that xDB data does not migrate to SitecoreAI, so treat any export of this data as a separate request, not a by-product of content serialization. Your privacy team should review whether any of this data is personal data that needs its own retention decision.
Set a content freeze window
Agree a date after which editors stop changing content, so the final serialized pull matches what goes live on the new platform. Publish the freeze to content owners and check that scheduled publishing jobs and in-flight workflow items are cleared or moved. Keep a short change log for the freeze period so that any edit made after the final pull can be replayed by hand.
Budget for personalization rebuilds
Personalization rules, experience variants and email marketing content do not carry over to SitecoreAI, according to Sitecore's migration guide, and they will not appear in a serialized content export in a form you can reuse. List every personalized component, rule and campaign, then estimate the rebuild as a separate workstream with its own owner. Ask implementation partners to price this work in the written scope rather than folding it into the content migration.
Agree the target platform first
Choose the target CMS and hosting model before the final pull, because the export format should match what the importer expects. Confirm which content types, media, users and roles the new platform will receive, and decide who owns access control after cutover. A written target decision also gives your implementation partner a fixed scope to quote against.
Verifying the export before you rely on it
This sequence checks that the serialized Sitecore tree matches what is live, that roles and users match the directory of record, and that the team leaves behind a signed inventory others can audit. Each step produces a record you can reuse later.
Freeze the source instance before comparing
The export owner pauses content publishing and structural changes on the source instance for the duration of the comparison, and records the time, the instance name and the Sitecore version in the export log. Without a freeze, every later difference is ambiguous, because you cannot tell whether an item changed after serialization or was wrong from the start. The step is done when the change freeze is announced to editors and the log entry is signed by the export owner.
Run ser diff against the live tree
A developer runs the Sitecore CLI diff command from the project root against the source instance, using the same module configuration that produced the YAML files. The output lists items that differ between the file system and the live tree, and the team saves that output as a dated file in the export folder. The step is complete when the diff is empty for every included module, or when each remaining difference has a written explanation such as a known exclusion in the module file.
Confirm module includes and excludes match the scope
The export owner reviews each module file against the agreed scope, checking that the includes capture every site root, template folder and media library in scope, and that excludes remove only what was deliberately left out. A mismatch here is the most common cause of a tree that looks complete but misses a site. The step is done when the reviewed module list is saved alongside the diff output with a reviewer's initials and date.
Sample items across sites and languages
A content reviewer selects a sample of items from each site and each language version, including pages with workflow states, placeholders and linked media, then opens the same items in the live editor and in the serialized YAML. They compare field values, language versions and publishing dates, and log each mismatch with the item path and language. The step is done when every sampled item matches or has a logged defect, and the sample list is kept so a second reviewer can repeat it.
Check roles and users against the directory of record
A security engineer compares the serialized role and user files with the identity directory that actually governs access, such as the corporate directory or SSO provider, and not with the local Sitecore accounts alone. Accounts that are disabled in the directory but present in the files, and groups missing from the files, are logged as findings for remediation before any import. Remember that serialization covers items, roles and users as configured in your module files, so confirm that scope and treat any account handling as a separate review. The step is done when each finding has an owner and a disposition.
Record an inventory and checksums
The export owner generates a file inventory of the serialized folder, listing each file path with a cryptographic hash, and stores it with the diff output, the module list, the sample results and the findings log. The hash inventory lets anyone later prove that the archived files have not changed since sign-off. The step is complete when the bundle is written to storage that the migration team controls, with a read-only copy kept separately.
Obtain a signed-off acceptance
The content owner, the technical lead and the security reviewer each sign the verification record, confirming the scope, the diff result, the sample outcome and the accepted exceptions. Signatures should name the exact bundle version by its inventory hash so the sign-off cannot drift from the files. The step is done when the signed record is stored with the bundle and the source freeze is lifted.
Keep the evidence for later compliance readiness
The verification bundle becomes evidence of how the export was scoped, checked and accepted, which can support later compliance readiness work, such as preparing records for an assessment by an independent auditor. This record does not itself make the export compliant or certified, and an auditor decides what evidence suffices. Confirm with your assessor which records they expect, how long they must be retained, and where they must be stored. The step is complete when the bundle is indexed in your records system with its retention rule.
Where the exported content can go next
The YAML files that Sitecore Content Serialization writes are a structured source for an import, not a finished migration. Items, their fields and their parent paths can be read from those files and loaded into an open-source CMS such as Drupal, Wagtail or Strapi. The decisions that matter sit in that import: which Sitecore template becomes which content type or page model, how fields map to the target's data types, how multi-language versions are represented, and how media references are rewritten. None of that happens during sitecore ser pull. Treat the export as the input to a mapping exercise that someone must design, test and sign off before cutover.
Rendering work is a separate stream from content work. Sitecore renderings, placeholders and the presentation layer do not become content in the YAML in any useful form, so each target needs its own component or template rebuild. The sibling migration guides cover this in detail: Migrate from Sitecore to Drupal, Migrate from Sitecore to a headless Strapi stack, Migrate from Sitecore to Wagtail and Migrate from Sitecore to Umbraco. Read the one that matches your team's language and front-end plans, then check its scope against the module files you exported. If your serialization includes only part of the tree, the guide's assumptions about content coverage will not hold until you widen the includes.
Before you pick a target, confirm three things with your own team: which serialized items are live content and which are configuration, whether roles and users in the export are needed in the new platform or should be recreated, and which personalization, forms and marketing data must be sourced from elsewhere. Those answers determine whether the import is a content-only job or a larger program. Ask any migration partner to show how they will map a representative sample of items before agreeing to a fixed scope, and confirm the exact export and import commands for your Sitecore version in the official documentation.
Closing gaps after the first export
This loop finds the items and media that the first serialization pull missed, fixes the module scope that caused each miss, and leaves a written record of every exception so the export can be repeated and audited.
Compare the export against the live tree
Run
sitecore ser diffagainst the source instance for each module, so the team can see which items differ between the Sitecore database and the YAML files on disk. The engineer who owns the serialization project does this, and the output is a list of item paths that are present in Sitecore but absent from the file system, or present in both with different content. The step is complete when every module has been compared and the list is saved with the export branch.Sort misses by cause
Group each missing or stale item into one of three causes: the path falls outside a module include, an exclude pattern removes it, or the item was edited after the pull. Module files are where the tree is scoped, so most misses trace back to a path pattern that is too narrow. The content owner should confirm which items are current content and which are test or leftover data. The step is complete when every item on the list has a cause written next to it.
Adjust includes and excludes in module files
Widen the include path for items that belong to the site, or remove an exclude that is hiding them. Keep changes small and tied to one module at a time, so a later diff can show the effect of each change. The developer who maintains the module files makes the edit, then reviews it with the content lead to confirm the scope matches the site structure. The step is complete when the module file change is committed on its own.
Re-run the pull and repeat the diff
Run
sitecore ser pullagain for the affected modules, thensitecore ser diffa second time. Check that the items from the list now appear as YAML files and that no new unexpected items were pulled in by the wider scope. Items that are still missing go back to step two. The step is complete when the diff shows only the exceptions that have been agreed and documented.Handle media that did not serialize
Serialization covers item definitions, so media files in the Media Library need a separate check. Compare the media items referenced by serialized content against the blob files and assets the team has copied to the target environment. Confirm with the Sitecore administrator how the source blobs are stored and whether they can be copied directly. The step is complete when every referenced asset either exists in the export location or is listed as an exception with its path and reason.
Record every exception
Create a single exceptions log in the export repository that lists each item or asset left out on purpose, the module file that scopes it, the reason, the owner who approved the exclusion, and the date. Include items that do not export at all, such as xDB contacts, analytics data and personalization rules, which the export does not carry. The step is complete when a reviewer can read the log and see why each gap exists without asking the team.
Freeze the export and confirm sign-off
Once the diff shows only documented exceptions, tag the repository state and store the exception log beside it. Ask the content owner and the migration lead to sign off on the scope in writing, and confirm with the target platform team that the tagged export can be loaded. The step is complete when the tag, the sign-off record and the exceptions log are stored together and any later change to the source is tracked as a new delta.
How DeployOpen works on this
DeployOpen plans and delivers a Sitecore data exit inside your own infrastructure, starting with a written inventory of what serialization can carry and what must be rebuilt or retired. Engagements are fixed-scope, so the boundaries of the export are agreed before any extraction work begins.
How we scope
- Inventory the Sitecore instances, module files and serialized trees that will feed the export
- Record which items, roles and users fall inside or outside the include and exclude rules
- Agree in writing which xDB, personalization and analytics data is out of scope and why
How we build
- Configure serialization runs and produce YAML output in a version-controlled repository
- Test the export against a copy of the instance and diff results before accepting them
- Load serialized content into the target open-source platform in your own accounts or data centers
How we hand over
- Deliver a field-level mapping document, export logs and a list of unmigrated data categories
- Document the rebuild work for personalization rules, forms and analytics as separate items
- Walk your teams through the repository layout, module files and repeatable export steps
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Confirm with your team which Sitecore version and data retention rules apply to the exit
- Agree the support scope and response expectations in the same written statement of work
