Guide
How to write a website brief that gets you accurate quotes
The quality of your brief determines the quality of your quotes.
The Blog
What happens to your content when you move to a headless CMS
Guide
The technology change is straightforward. The content restructure is where the real work happens.
When businesses start exploring a move from WordPress to a headless CMS, the conversation usually focuses on performance, flexibility, and frontend technology. Those are all valid reasons to make the switch.
But the question that doesn't come up early enough is: what happens to all our existing content?
The answer isn't complicated, but it does require planning. Content migration is one of the most underestimated parts of a headless CMS project, and when it's rushed or ignored, it creates problems that show up months after launch.
Here's what the process actually looks like.
Your content doesn't just copy across
In WordPress, most content lives in a single rich-text editor, one big block of HTML per page or post. Headings, images, lists, and custom layouts are all mixed together in that one field.
A headless CMS works differently. Content is structured into discrete fields: a title field, a subtitle field, a body field, an image field with alt text, a CTA block with its own heading and link. Each piece of content has its own place.
This is what makes a headless CMS powerful, structured content can be delivered to a website, an app, a digital display, or anything else that calls the API. But it means your existing WordPress content needs to be unpacked and reorganised to fit the new structure.
That's not a five-minute job. It's a deliberate process that needs to happen alongside the build, not after it.
The content model comes first
Before any content moves, the first step is defining the content model, the structure of fields and blocks that your content will live in.
This is a collaborative process between your team and your developer. It involves decisions like: What types of content do you publish? What fields does each type need? What's reusable across pages and what's unique? Do you need flexible layout blocks, or is a fixed structure fine?
Getting this right upfront saves significant time later. A well-designed content model means your team can update and publish content confidently without touching code. A poorly designed one means constant developer involvement for routine changes.
For more on how headless CMS content structures work and when they make sense, see our headless CMS guide.
Migration options: Manual vs. Automated
For small sites, under 30 pages, manual migration is usually the most practical approach. Your team or your developer reviews each page, maps the content to the new structure, and enters it into the headless CMS. It's hands-on, but it's also an opportunity to review and improve content that may be outdated.
For larger sites, 50+ pages, hundreds of blog posts, or complex content types, automated migration scripts can extract content from WordPress and map it to the new CMS structure. This is faster but requires developer time to build and test the scripts, and you'll still need a manual review pass to catch formatting issues.
Most business websites fall somewhere in between. A hybrid approach, automated extraction with manual cleanup, is typically the most efficient.
Migration prep
What to do before the migration
The best time to audit your content is before the move, not during it. A few things to sort out early:
- 01Identify what's worth migrating.
Not everything needs to come across. Old blog posts with no traffic, outdated service pages, and placeholder content can be archived rather than migrated. Less content to move means less work and a cleaner starting point.
- 02Decide who's responsible for content.
Migration stalls when nobody owns it. Assign someone on your team to review and approve content as it's moved. This doesn't have to be a full-time job, but it does need a name attached to it.
- 03Plan for redirects.
Your URL structure will likely change. Every old URL needs to redirect to the correct new URL, or you'll lose any SEO value those pages have built up. Your developer should handle this as part of the migration plan, not as an afterthought after launch.
- 04Prepare new content early
If you know certain pages need rewriting, and most businesses have at least a few, start that work before the migration. Don't wait until everything else is done and then rush the copy.
- After the migration
Once content is in the new CMS, the focus shifts to your team learning the system. A headless CMS with a well-designed content model should be straightforward to use, but it's different from WordPress, and your team will need a proper walkthrough.
Good handover includes documentation specific to your setup, a training session covering the tasks your team will do most often, and a support window for questions that come up in the first few weeks.
The goal is that within a month of launch, your team is publishing and updating content independently, without needing to call a developer for routine changes.