Optimizely CMS 13 Content Transfer & Environment Sync: Moving Content Safely After Upgrade

Your CMS 13 upgrade is deployed, the code compiles, and the editors are ready to work — then you try to move content between environments and nothing behaves the way it used to. The export file that opened fine in CMS 12 fails on import, version history shows up missing, or approval states silently reset to draft. Content transfer is the step teams treat as a formality until it quietly costs them hours of rework.

Content movement between development, staging, and production has always been part of Optimizely CMS life. But the mechanics changed meaningfully with the move to .NET Core and CMS 12/13: new export/import providers, a different package format, a reworked DXP environment sync model, and legacy transfer tools that disappeared. This guide explains what actually changed in CMS 13 content transfer, what gets lost in a naive sync, and the runbook that moves content between environments safely.

What Actually Changed in CMS 13 Content Transfer

The headline of every CMS upgrade is the new editor experience, but the transfer layer is where migrations quietly go sideways. Three things changed in CMS 12/13 that affect how content moves between environments.

The export/import pipeline was rewritten for .NET Core. The old CMS 11-era export provider and package format don’t survive the move to .NET Core unchanged. Export files produced by legacy tooling — or by half-migrated environments still running mixed assemblies — frequently fail to import into a clean CMS 13 instance. The new pipeline serializes content differently, and providers that were custom-built against the old abstraction need to be rebuilt against the new IContentExportProvider / IContentImportProvider contracts.

The DXP sync model changed. If you run Optimizely DXP (SaaS), the way environments sync changed alongside the platform. The Content Transfer feature and the environment synchronization flows now operate on the CMS 13 data model, with different expectations around what travels automatically (content, assets, and settings) versus what you must move yourself (typically users, roles, scheduled jobs, and some configuration).

Legacy tools disappeared. Transfer approaches that depended on deprecated APIs, the old web services layer, or version-specific database moves no longer work — and some fail silently, copying content but dropping the metadata that makes it usable in production.

The Three Ways Content Moves in CMS 13

There are three legitimate mechanisms for moving content in CMS 13, and each fits a different scenario. Picking the wrong one is the most common source of “lost” content after an upgrade.

Export/import (UI or API). The built-in export/import creates a content package you can move between any environments — on-prem or DXP. This is the right tool for one-off moves, partial content sets, and migrations between unrelated environments. The new API surface (ContentExport, ContentImport) lets you script it, which matters for repeatable transfer jobs.

DXP Content Transfer / environment sync. For DXP customers, platform-level transfer moves content between the DXP environments (integration/preproduction/production) through the portal. This is the highest-fidelity path for DXP-to-DXP moves because the platform understands its own data model — but it’s not a universal tool, and it doesn’t cover everything.

Custom transfer code. Teams with complex needs — selective content, reference rewriting, custom property mapping — build their own transfer logic on top of the content APIs. This is powerful and also the easiest to get wrong, because you inherit responsibility for every dependency the built-in tools handled for you.

What Gets Lost in a Naive Transfer

The export/import tools in CMS 13 are good at what they do — moving content items. They are not magic, and a naive transfer drops the same categories of data every time:

Assets and references. Pages and blocks export, but binary assets can be skipped or re-linked incorrectly when the import target resolves media differently. Broken image links in production are the #1 visible symptom of a rushed transfer.

Version history and approval states. Many teams are shocked to discover their imported content arrived as a single version with workflow status reset. If your editors rely on version history or staged approval workflows, the transfer plan must explicitly verify versions and workflow states survived — or accept the reset and plan around it.

Configuration that lives outside content. Scheduled jobs, user roles, URL segments, and some site settings don’t ride along in content export. Teams that assume “content transfer” includes these end up debugging missing functionality in production.

Content that exists only in code. CMS 13 content types defined in code — blocks, page types, and their properties — must be deployed to the target environment before content import, or the import fails or lands half-populated.

The Safe Content Transfer Runbook

A safe move between environments is a data migration with integrity requirements, not a copy-paste. This runbook works for CMS 13:

1. Inventory before you export. Map what needs to move: content trees, media, settings, scheduled jobs, workflows. Note which items are code-defined (they deploy separately) and which are purely data. Most teams discover content living in places they forgot — blocks in global shared folders, media libraries referenced by multiple sites.

2. Deploy code first, then content. Push the CMS 13 code, content types, and initialization modules to the target environment before importing any content. Importing content into an environment that doesn’t yet know the content types produces partial imports that are painful to clean up.

3. Export with a snapshot mindset. Use the new export API or UI to produce a clean package from a stable source environment. Don’t export from a machine mid-deployment, and record the export timestamp and source environment so the package is reproducible.

4. Import into staging first — always. Validate the transfer in a staging environment before production. This catches asset resolution, reference, and workflow issues while the blast radius is still zero. Verify the import log for warnings; CMS import logs are honest about skipped items, and skipping is the silent failure mode.

5. Verify integrity, not just item count. After import, check the things that actually break: media URLs resolve, internal links point at imported (not orphaned) content, version counts match expectations, and approval states are what editors need. A spot-check of five important pages beats a “1,234 items imported” summary line.

6. Cut over deliberately. Plan the production move as a timed event: final export, maintenance window, import, integrity sweep, and rollback path. The rollback path is important — keep the previous environment intact until editors confirm production content is correct.

Full Sync vs Delta vs Selective: Choosing the Strategy

Not every environment relationship needs a full re-transfer. Match the strategy to the relationship:

Full sync — the right default for dev-to-staging alignment after an upgrade, where you want environments to converge. Accept the downtime; it’s a one-time cost.

Delta transfer — for ongoing pushes of recently changed content. Only viable once you have a verified baseline, because deltas inherit every assumption of the baseline transfer.

Selective transfer — for moving specific sections (a new campaign site, a landing page cluster) without touching the rest. This is where custom transfer code earns its keep, and where reference handling needs the most care.

What This Means for Your Team

Content transfer after a CMS 13 upgrade is not a checkbox — it’s the point where the upgrade becomes real for your editors. A transfer that drops versions or breaks media links creates a week of cleanup and erodes confidence in the new platform before anyone experiences its benefits. Budget for it, run it deliberately, and verify the things that matter to your editors rather than trusting the summary counts.

The good news: with the right runbook, CMS 13 content transfer is predictable. The export/import pipeline, once you understand its boundaries, moves content reliably — and the DXP sync path handles the environment-to-environment flow cleanly. The risk is in the parts that don’t ride along automatically, and those are exactly the parts a deliberate transfer plan accounts for.

How geniusOS Can Help

geniusOS has moved content between Optimizely CMS environments through multiple 12-to-13 upgrades — including asset-heavy sites, multi-site deployments, and workflow-driven publishing models. We audit your transfer requirements, rebuild custom export/import providers against the CMS 13 contracts, and run the full sync runbook with integrity verification before production cutover.

We’ll make sure your content — assets, versions, approval states, and all — arrives intact, so your editors land in a working CMS 13 on day one.

Planning a CMS 13 upgrade and worried about your content? Talk to our team and we’ll map your transfer path before you touch production.