Moving Your Blog Off WordPress or Contentful Without Losing Five Years of Posts
Real migration infrastructure for moving a WordPress or Contentful archive into ContentOS already exists in our backend — here's what it does, and why it isn't a button you can click yet.
This one is worth being precise about: what's described here is real, tested backend infrastructure — not a feature you can reach from the content app today. We'd rather explain it honestly as architecture in progress than let a reader think there's a migration button waiting for them.
The problem migrations always get wrong
The single most common way a CMS migration goes badly isn't the parsing — it's running the import before anyone has actually looked at what's about to be created. Four hundred posts land in a new system, half of them malformed, and now there's cleanup work that's worse than starting over.
The design we've built for this
Inside content-ops-worker — the backend we internally call ContentOS — there's a real migration pipeline that parses both WordPress export files (the standard WXR format) and Contentful space exports, and deliberately splits the process into two separate steps:
Preview first. Nothing is written. The preview step parses your export file and returns a total count, anything it had to skip, any warnings worth your attention, and a sample of the first several items — titles, slugs, status, and content length — so you can sanity-check the parse before committing to anything.
Import second, and only when you choose to. The actual import runs as a distinct step, batching writes rather than doing one database round-trip per post, checking for slug collisions across the whole batch up front rather than one at a time, and recording where each imported item came from — which export, which original ID — so if you need to reconcile or re-run the migration later, that provenance is still there.
Why we're telling you about something you can't use yet
This is exactly the kind of infrastructure that's easy to build badly under time pressure — skip the preview step, run everything in a loop of individual writes, don't record where anything came from — and exactly the kind of infrastructure that's expensive to fix later once teams are relying on it. We built it right the first time specifically because migration is a one-shot trust moment: if a team's first experience moving five years of posts into a new system loses data or silently mangles half of it, there's no second chance to make that impression.
There's no UI wired to this yet, and no public route a reader could point their own export file at today. When that changes, it'll be because the preview/import discipline above is already proven — not because we cut it to ship faster.