What Happens to Your Content When You Leave the CMS?
Every CMS demo shows how content gets in. Almost none show how it gets out. Run the CMS migration export before you buy, because it decides whether leaving costs a week or a quarter.
On This Page
Every CMS demo is built around getting content in. A field appears, a preview renders, a page goes live, everybody nods. Nobody opens the export screen. Three years later, when the renewal arrives at a number nobody likes, or the product is acquired and the roadmap moves somewhere you were not going, the export screen is the only one that matters.
So treat the exit as a purchasing criterion, ranked next to price and roles rather than filed under "migration, later". The useful question is not whether the system has an export button. It is what a CMS migration export actually returns: which fields, in which shape, with which relationships intact, with which media, and whether that answer changes on the plan you can afford.
Ask a vendor to run one during the trial and send you the file. It is a five-minute request and it ends evaluations, rarely because anybody lied. Most vendors have simply never been asked, and the person on the call genuinely does not know what comes out.
The question sits directly on top of the storage decision, files in a repository or records behind a hosted API, which our parent company sets out in Git-based CMS or API-based CMS. Storage decides how expensive leaving is. The content model decides how much of what you carry out is still worth anything when it lands.
The exit is part of what you are buying
Nobody chooses a CMS expecting to leave it, which is precisely why the exit gets no scrutiny. The evaluation is run by people imagining the good years: the new page types, the faster publishing, the tidy interface. Leaving belongs to a future team, possibly a future company, and it never makes the scorecard.
Then the day arrives. Usually it is not dramatic. The vendor raises seat pricing, or deprecates the field type your whole site depends on, or your traffic grows past a plan boundary, or the agency that built the thing stops answering. Nothing has broken. You just want out, and now you find out what "we support full export" meant.
What it costs is not the licence. It is the number of hours a person spends copying content from one window into another, and that number is set by decisions made years earlier. A rebuild of the site itself is scoped, estimated and finite. Retyping four hundred pages because the export returned rendered markup is none of those things, and it lands on whoever is least able to refuse it.
Does the export include every field, or only the ones the public site renders? Does it include media files, or only the URLs pointing at your account? Does it include drafts, scheduled entries and revision history? Is it available on the plan we are buying, and is it self-service? A vendor who answers all four in writing is usually a vendor worth buying from.
What a CMS migration export actually contains
Fields, not pages
A good export hands you the content model, not the website. Each entry arrives as named fields with their values: heading, summary, body blocks, publish date, author, category, image reference. Nothing about presentation, because presentation is the part you are replacing. This is the direct payoff of having modelled fields that survive a redesign rather than one large rich-text box per page, and it is the single strongest predictor of whether the next migration is scripted or manual.
The format barely matters. JSON, YAML, Markdown with front matter, a set of CSV files, an XML dump: all of them are workable if the structure is there. What matters is whether a developer can read one record and know, without guessing, which piece is the pull quote and which piece is the body.
The gap between a good export and a weak one
Both exports produce a file. They produce very different second months. This is the comparison to hold in your head while a salesperson is telling you that export is supported.
| What is being exported | A structured export returns | A weak export returns | What the gap costs you |
|---|---|---|---|
| Body content | Typed fields and block structure | One rendered HTML string per page | Every page reformatted by hand at the next redesign |
| Images | Original files, with alt text and captions | URLs pointing at the old account | Broken images the day billing lapses |
| Relationships | Stable identifiers on both sides of the link | Display names only | Author, category and related-item links rebuilt by hand |
| Taxonomies | The full tree, with slugs and parents | A flat list of labels | Archive and filter URLs that no longer resolve |
| Page metadata | Titles, descriptions, canonicals, redirects | Nothing, or a partial plugin dump | Search visibility rebuilt from memory |
| Dates and authorship | Original publish date, author, revision history | The export date stamped on everything | A ten-year archive that looks written last Tuesday |
| Unpublished work | Drafts and scheduled entries, status intact | Published entries only | Half-finished work quietly lost |
What quietly goes missing
Certain things almost never come out, and none of them announce their absence. You discover them weeks after the migration, when somebody asks a question the new system cannot answer.
- Revision history. Almost universally left behind. If knowing who approved a sentence matters to you legally, that history is not a nice-to-have and you should say so before signing.
- Drafts and scheduled entries. Many exports filter to published status by default. The work in progress is the work people care about most on the day of the switch.
- Alt text and captions. Stored against the media library rather than the entry, so an entry-level export drops them and nobody notices until an accessibility review does.
- Redirects created inside the CMS. Years of accumulated slug changes, often held by a plugin with its own storage and its own export, which is to say usually no export at all.
- Per-entry search overrides. Custom titles, descriptions and canonical settings live in a separate table more often than not, and they are the difference between a quiet migration and a loud one.
- Form submissions and comments. Rarely part of a content export at all. Decide deliberately whether you need them, then export them separately or accept losing them.
The HTML blob trap
Here is the failure that costs the most and looks the most harmless. The export runs, the file is large, every page is present, and each one contains a single field called content holding several thousand characters of markup: wrapper divs, inline styles, class names from a theme you are abandoning, absolute links to the old domain, and occasionally a shortcode that means nothing outside the system that generated it.
That file is technically a complete export. It is also close to useless. You cannot restyle it, because the styling is baked in. You cannot re-render it into a new layout, because there is no structure to render. You cannot reliably script the clean-up, because page builders and pasted word-processor documents produce markup that varies page by page. What you can do is open each page and rebuild it, which is the outcome the export was supposed to prevent.
The trap is set long before the migration, on the day someone chose an editor with one big rich-text field because it felt flexible. It is flexible. That is the problem. Flexibility at the input end becomes ambiguity at the output end, and ambiguity is what makes automated conversion impossible.
An export that returns rendered markup is not an export. It is a printout, and printouts get retyped.
The honest concession: for a small brochure site of twenty pages, none of this matters much. Twenty pages of markup can be cleaned up in an afternoon, and the modelling discipline would have cost more than the rescue. The trap only bites at volume, on sites with a real archive, which is exactly the kind of site whose owners assume they will never move.
Media, alt text and everything attached to an image
Most content exports do not contain a single image. They contain URLs, and those URLs point at the system you are leaving. As long as the account stays open everything looks fine, which is how teams reach launch day on a new platform while still paying the old vendor to serve their photographs.
Get the original files, at original resolution, not the resized derivatives the old theme happened to generate. Derivatives are sized for a layout you no longer have. Then get the things attached to each file: alternative text, captions, credit lines, focal points and any usage note somebody recorded. Alt text in particular is expensive to recreate, because writing it properly means looking at every image and thinking about it, which is a person-week nobody budgeted.
File names carry weight too. If your images are named with something descriptive rather than a random identifier, keeping those names means keeping whatever image search visibility they earned. Renaming everything to a hash during migration is a decision, not an accident, and it should be made on purpose.
Relationships are the part that does not travel
A page is rarely alone. An article has an author, a category, a series, three related articles and a call-to-action block that belongs to a campaign. Those connections are records in a join table, and a flattened export renders them as text: the author becomes a name string, the category becomes a label, the related items disappear entirely. Sites built on properly structured custom post types feel this hardest, because they have the most relationships worth keeping.
The test is simple. Open two records in the export and ask whether a script could reconnect them without human judgement. If the article says "Priya" and the author record says "Priya", a script has to guess, and it will guess wrong the day a second Priya joins. If both carry the same stable identifier, reconnection is mechanical.
Ordering is the other half of this, and it is the half people forget. Curated sequences, pinned items, a hand-arranged navigation, the order of steps inside a how-to: all of it is data, all of it is invisible in a flat file, and all of it gets rebuilt from screenshots if nobody exported it deliberately.
URLs, redirects and the archive
Content is only half of what you are carrying out. The other half is the set of addresses that content lives at, and it is the half that decides whether the move is invisible to visitors or a bad quarter. Old URLs, old redirects, and the mapping between them are the working material of any website migration, and none of them are usually inside the content export.
Build the inventory from three places before you cancel anything: the last sitemap the old system published, the server or platform access logs, and any redirect table held by a plugin. Reconcile them into one list, then decide a destination for every row. That artefact is the redirect map, and it is the document the whole migration hangs on. Our note on the checklist that protects rankings covers the sequencing; the point here is that you cannot build the map after access has been switched off.
Deep archives deserve their own decision. A decade of posts is not automatically worth moving, and moving it badly is worse than retiring it cleanly, which is the argument we make in migrating ten years of pages. What you cannot do is make that call after the export window has closed. Take everything out first, then choose what to publish, because deletion is always available later and extraction is not.
One practical note from the technical SEO side: keep the old redirects as well as the old URLs. Sites that have moved before are carrying chains, and dropping the first hop breaks links published by other people years ago. Those links are not yours to break.
The export test to run during the trial
This takes an afternoon and it is the most useful afternoon in any CMS evaluation. Do it with real content, not with the sample data the vendor seeds, because sample data is always modelled perfectly.
- Load three genuinely awkward pages. Your longest article, a page with a table and embedded media, and one entry that links to several others. Not the homepage.
- Run the export yourself. If you have to raise a support ticket to get a copy of your own content, that is the answer to the whole question and you can stop here.
- Open the file and find the body. Is it structured blocks, or one long string of markup? This is the moment the HTML blob trap either appears or does not.
- Follow one relationship end to end. Take the article, find its author reference, then find the author record. If either side is a display name rather than an identifier, note it as manual work.
- Look for the images. Actual files, or links back to the vendor? Then check whether alternative text and captions came with them.
- Check dates, authorship and drafts. Original publish dates intact, or everything stamped today? Are unpublished entries present at all?
- Import it into something else. Even a throwaway script that reads the file and prints one page proves the format is machine-readable. Everything before this step is inspection; this step is proof.
Systems that keep content in the repository pass this test by construction, because the export is a clone you already hold on three laptops. A workspace like Acrosite works that way: it generates the files, commits them to GitHub and triggers the configured deployment, so the content sits in your own repository at every moment rather than in a database you can request a copy of. That shape does not suit every team, but it removes this whole category of risk.
Of the seven, step seven is the one that gets dropped and the one that finds real problems. Reading an export tells you what the vendor intended. Importing it tells you what they built. Give somebody two hours and a throwaway script, and make the result part of the decision, not part of the post-mortem.
If you are already inside a system with no clean way out
Most people reading this are not choosing anything. They are three years into something, and the answer to every question above is worse than they would like. That is a recoverable position, but only if you stop treating extraction as something that happens on migration day.
Start extracting now, while nothing is urgent and everyone is still on good terms. Pull a full export this month and store it somewhere you control. Pull the media library separately. Write down the redirect table. Run the same job on a schedule so the copy stays current. None of that commits you to leaving, and all of it converts an unknown cost into a known one.
Then fix the modelling, page type by page type, ahead of any move. Every page you convert from a wall of markup into named fields is a page the next migration handles automatically. Doing that inside a system you already know is far cheaper than doing it during a platform change, when everything is unfamiliar and everyone is tired.
And the reversal, because there is one. If your content genuinely has no future value, a microsite that will be replaced wholesale or a campaign that ends in eight weeks, none of this discipline earns its keep and you should buy on convenience alone. The rule applies to content you expect to still be publishing against in five years. If you are weighing a specific platform and want a second read on what its export really gives you, tell us what you are running and we will tell you what we would test first.
Common questions.
What should a CMS export actually include?
A usable export includes every content field as structured data rather than rendered markup, the original media files with their alternative text and captions, stable identifiers for relationships between entries, the full taxonomy tree, per-entry metadata such as titles and canonical settings, original publish dates and authorship, and unpublished drafts. Anything missing from that list becomes manual work later, usually measured in person-weeks.
Why is exported HTML content a problem?
Exported HTML carries the old design inside it: wrapper elements, inline styles, theme class names and absolute links to the previous domain. Because the structure is presentational rather than semantic, a script cannot reliably tell a pull quote from a paragraph, so the content cannot be re-rendered into a new layout. Teams end up rebuilding pages by hand, which is the cost the export was meant to avoid.
Do images come with a content export?
Usually not. Most content exports contain image URLs pointing back at the platform you are leaving, so pages look correct until that account closes. Ask for the original files at full resolution, exported separately, along with alternative text, captions and credit lines. Alternative text is the costliest item to recreate, because doing it properly means reviewing every image individually.
How do I keep redirects when moving to a new CMS?
Build a redirect map before you lose access to the old system. Combine the last published sitemap, server or platform access logs, and any redirect table held by a plugin into a single list of live URLs, then assign every row a destination on the new site. Keep existing redirect chains as well as current URLs, because older links published elsewhere still point at the earliest addresses.
When is the right time to test a CMS export?
During the trial, before any contract is signed, using your own awkward content rather than the vendor sample data. Load a long article, a page with tables and embedded media, and an entry with relationships, then run the export and try importing it somewhere else. That afternoon costs almost nothing and regularly removes a shortlisted vendor from consideration.
Is CMS lock-in ever acceptable?
Yes, when the content has a short life. A campaign microsite that ends in eight weeks, or a page set due for wholesale replacement, does not justify the modelling discipline portability requires, and buying on convenience is the right call. Lock-in only becomes expensive for archives you expect to keep publishing against for years, where the volume makes manual recovery impossible.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.