Moving a site into a new CMS changes more than where the text lives. It changes what editors can express, what developers can reuse, and what visitors can find.
On a recent rebuild, I kept coming back to the same request: use the actual content, then make the design work for it. The new site needed a stronger visual direction, but that was not permission to replace detailed pages with short summaries or internal planning notes.
That distinction matters before you write the import script.
A migration can preserve every route and still lose much of what made those routes useful. The missing pieces might be explanations, captions, relationships between pages, or the context around a call to action. A fresh CMS makes those losses easier to overlook because the new structure looks so tidy.
Here is how I would approach the content model before committing to the new layout.
Start with the questions each page answers
A screenshot tells you how a page looks. It does not tell you everything the page does.
For each existing route, I want a short inventory of the questions it answers: who this is for, what is offered, what someone needs to know before taking the next step, and where that next step leads. Then I want the actual source material beside it: copy, media, captions, downloads, links, and any expandable sections.
A sitemap is a starting point. It will not necessarily reveal content behind tabs, gallery links, or buttons that lead to another useful page.
The inventory should distinguish three decisions:
- Keep: the information still belongs, even if its presentation changes.
- Revise: someone has explicitly approved an editorial change.
- Retire: the information is intentionally removed, with a reason and an owner.
“Did not fit the component” is not a fourth decision.
I would keep source references in the migration worksheet rather than putting editorial uncertainty into public copy. Questions for the business belong in the review process. Visitors should not have to read the migration team's working notes.
Let real content challenge the first design
It is easy to design a card with a short title, a two-line description, and a perfectly cropped image. It is harder to use that card when the real title is longer, the explanation needs several paragraphs, and the image has a subject near the edge.
That is useful friction. It tells you what the design has to support.
Before multiplying a layout across the site, I would try it with three real examples: a simple page, the longest page, and a page with unusual media or related information. If all three require exceptions, the model probably reflects the mockup more closely than the content.
Sometimes the answer is a better layout. Sometimes it is an optional section or a separate page type. Sometimes the copy genuinely needs editing. Those are different decisions, and combining them into “clean up the content” hides who is responsible for each one.
Separate reusable facts from page composition
Consider a fictional training business with courses, instructors, locations, and course landing pages.
The location address should not be copied into every course page. The explanation of why a particular course suits a beginner should not be squeezed into a generic location record either.
I would separate the model into two layers:
Shared records | Page composition |
|---|---|
Course name and relevant details | Introduction and narrative order |
Instructor profile | Selected instructor feature |
Location details | Location section in this page's context |
Media with captions and usage notes | Gallery selection and presentation |
In Payload, relationship fields can connect documents, and blocks can hold an ordered mix of different schemas. Those are useful building blocks for this separation; they do not decide the right content model for you. Payload relationships · Payload blocks
The question I keep asking is: if an editor changes this fact, where should that change appear? If the answer is “everywhere,” a shared record may make sense. If the answer depends on the page's story, keep that context in the page.
Give editors flexibility with a purpose
“Everything is editable” can become a surprisingly difficult interface.
An editor who wants to add a gallery should not have to choose arbitrary margins, rebuild a grid, or decide which combination of colours is accessible. But they should be able to choose the images, write captions, reorder them, and decide where the gallery belongs.
I would start with a small set of meaningful blocks: an introduction, an image-and-copy section, a gallery, a related-items section, and a clear next step. Add a new block when real content demonstrates a different need.
Keep layout behaviour in the design system. Keep editorial choices in the CMS. Where a choice crosses that boundary, offer a few named options with useful previews instead of a pile of low-level styling controls.
The same principle applies to rich text. Use it for the writing that benefits from flow. Do not bury every reusable fact inside it, and do not split every sentence into a field just because you can.
Treat migration as a mapping, not a rewrite
For each source item, record its destination and any deliberate transformation. A small worksheet is enough:
Source | Destination | Decision |
|---|---|---|
Course introduction | Page introduction block | Preserve copy; adjust headings |
Repeated address | Location relationship | Consolidate after checking consistency |
Photo captions | Gallery item captions | Preserve alongside the correct image |
Old enquiry link | Page call to action | Map to the equivalent destination |
This is an illustrative example, not a report of a completed migration.
The mapping makes a useful review conversation possible: what changed, why did it change, and who agreed? It also prevents an automated importer or coding agent from treating summarisation as a harmless implementation detail.
If URLs change, maintain an explicit old-to-new map as well. Google's site-move guidance recommends preparing that mapping and configuring redirects; it also advises separating major changes where possible. A CMS move does not require a new URL for every page. Google Search Central: site moves
Test the model with an editor's job
Before calling the model finished, try a few ordinary changes: correct an address, add a gallery image, reorder a section, and add a new page using existing patterns.
Watch where the editor needs developer help. Watch where a shared edit has surprising consequences. Watch where the only way to express the content is to misuse a field.
Those are model problems worth fixing while the structure is still small.
A redesign can be more ambitious than the old site. It can be faster, clearer, and far more expressive. But the source content is not filler to pour into the new components at the end. It is one of the inputs that tells you which components you need.
That is the order I want to protect: understand the content, design the model, then make the experience better.