By Mehdi HassanMost CMS migrations copy the old content model: every Webflow collection becomes a Sanity type, every WordPress custom field becomes a Payload field. It's fast and it feels safe. It also carries every past mistake into the new system. This framework takes the opposite approach, starting from what your pages need to say. It sits alongside our headless CMS migration guide, which covers the platform side of moving.
What is content modeling for a CMS migration?
Content modeling for a CMS migration is deciding which content types, fields and relationships the new CMS will have, before any content is moved. It's the blueprint the import scripts, the front end and your editors all depend on, so a weak model costs you every day after launch.
The model answers practical questions. Is a customer story a page or a reusable entry? Does a testimonial belong to a page, or can it appear on five pages? Is the pricing table typed data or a block of rich text? If you're new to the basics, our content modeling 101 guide explains collections, fields and references for a SaaS site. This article is about the migration moment specifically, when you can finally redesign the model instead of patching it.
Why does copying old page templates cause problems?
Copying old page templates causes problems because templates encode past layouts, not what your content is. A field called hero_subtitle_2 exists because a designer once needed a second line; it means nothing to the next editor, and it locks the new site into the old design.
Template-first model | Copy-first model |
|---|---|
Types mirror old page layouts | Types mirror what the content says |
Testimonials pasted into each page | Testimonials stored once and referenced |
Fields named after positions (left column) | Fields named after meaning (customer quote) |
Redesign means remodeling | Redesign means new templates, same content |
Duplicate claims drift out of sync | One claim, updated everywhere |
The copy-first side takes more thinking up front. It pays back the first time you redesign, add a page or change a claim, because the content doesn't have to move again.
What is copy-first content modeling?
Copy-first content modeling is a method that designs the CMS around three layers: the messages your site has to communicate, the proof that backs those messages, and the pages that assemble them. It starts from the words because, at Designify, one team writes, designs and builds, and we've found the content structure is clearest when it follows the copy.
Layer 1: messages
Messages are the claims and explanations your site makes: the value proposition, each feature's benefit, each use case's problem and outcome. Model them as structured fields (headline, supporting line, detail) attached to a feature, use case or product type, not as free text on a page.
Layer 2: reusable proof
Proof is anything that makes a message believable: testimonials, customer logos, case studies, ratings, security badges, integration lists. Each piece of proof is its own entry, tagged by industry, feature or persona, so any page can pull the right proof without copying it.
Layer 3: page assemblies
Pages are thin. A page has a slug, SEO fields and an ordered list of sections, and each section references messages and proof. The page decides order and emphasis; it doesn't own the content.
How do you apply the framework during a migration?
You apply the framework in six steps, starting with an audit and ending with a mapping sheet that tells the import scripts where each old field goes. The order matters, because modeling content you're about to delete is wasted effort.
Audit what you have
Decide what to keep, merge, redirect or delete. Our content audit before migration guide gives a method for each decision.
Extract the messages
Go through the pages you're keeping and list every distinct claim. Group duplicates; you'll often find the same benefit written several different ways.
Inventory the proof
List every testimonial, logo, case study and badge, with where it appears today. Tag each by the message it supports.
Draft the types
Create types for messages, proof and pages. Aim for fewer types than the old site, with names an editor understands.
Build the mapping sheet
For every old field, write the new type and field, or drop it. This becomes the spec for your export and import scripts.
Test with real pages
Rebuild three very different pages from the model on paper. If something won't fit, fix the model now, not after import.
Hypothetical example: remodeling a SaaS site's customer proof
For example, suppose a SaaS site has 40 pages, and testimonials are pasted directly into 18 of them, some edited slightly each time. Logos sit in an image field on the homepage and again on three landing pages.
In the copy-first model, each testimonial becomes one Testimonial entry with the quote, the person's name and role, the company, and tags for industry and feature. Logos become Customer entries. A landing page section now references the testimonials tagged with its industry. When a customer changes their job title, an editor updates it once, and all 18 pages are correct.
How does the new model affect the export and import?
The new model turns the export and import into a transform, not a copy. Instead of moving each old field to a field with the same name, scripts split and merge content: a page's pasted testimonial becomes a reference to a single testimonial entry, and duplicated claims are merged into one message.
That transform is more work than a straight copy, so keep it honest. Pages with heavy rich-text bodies, such as blog posts, often don't need remodeling at all, and can move as structured rich text. Focus the copy-first effort on marketing pages, where messages and proof repeat. For the mechanics of each platform, see our guides to exporting Webflow CMS content, importing content into Framer CMS and the general process of CMS content migration.
How do you know your content model is good?
You know your content model is good when an editor can build a new page without a developer, when a redesign doesn't require moving content, and when every claim and piece of proof exists in exactly one place. If any of those fail, the model still mirrors old templates.
- Names make sense to editors. A new hire can guess what each field is for.
- No position-based fields. Nothing called left, right, second or alt.
- Proof is referenced, never pasted. Search for a testimonial's text; it should exist once.
- SEO fields live on pages. Titles, descriptions and canonical URLs sit where search engines see them, which our on-page SEO audit guide covers in depth.
- The model is smaller than before. Fewer, clearer types usually beat many specific ones.
If you're redesigning at the same time as migrating, the same copy-first thinking applies to the pages themselves; our website content audit template helps you plan both together.
