What Contentful Developers Actually Build During a Migration
A Contentful build asks contentful developers to design a shared content model before a single component gets written, not after.
Quick answer:A Contentful build hinges on the content model, not the editor UI: content modelling, API-driven front end, redirect mapping and staged migration.
- headless CMS implementation
- CMS migration planning
- multi-channel content architecture
Quick answer
What does a Contentful build and migration involve?
Contentful developers model content for reuse across sites and channels, rebuild the front end against the Contentful API, map redirects, then migrate content in staged batches.
Additional Context
The content model, not the editor interface, decides whether a multi-site migration holds up.
Sources
- Digital Service Standard
Government guidance on building reusable, API-driven digital services rather than single-use page templates.
Contentful Development
What a Contentful Build and Migration Actually Involves
A Contentful engagement rarely starts with swapping one editing screen for another. The real work sits in the content model: the set of types, fields and references that decides whether an article, a park listing or a product offer can be reused across a corporate site, a campaign microsite and a mobile app without being rebuilt for each one.
Contentful developers spend the early weeks of a build mapping how content behaves across every property an organisation runs, not just how the current website happens to be laid out. A typical WordPress site buries layout decisions inside content: a hero field assumes one template, a related-articles block assumes one taxonomy. Migrating that content into Contentful means separating what it means from how it currently displays, then rebuilding the front end so pages render from an API call, with no page template dictating the structure.
National Digital consolidated NRMA Parks and Resorts onto one Contentful headless CMS with a shared Next.js front end, replacing a set of separate WordPress properties with a single content model one editorial team could manage. It's the kind of multi-site consolidation Contentful's model is built for, and the harder half of that work was the WordPress to Contentful migration planning: deciding which fields survived, which got merged, and which got retired.
Where Migrations Go Wrong
Why Contentful Migrations Stall Without a Content Model First
Problem
Many Contentful migrations start by mapping existing web pages into the new CMS one to one. That approach carries forward the layout problems of the old site and produces a content model nobody outside the original build team can safely extend.
Common Pain Points:
- Layout baked into content Old CMS fields assume a specific template, making reuse across channels impossible without rework.
- No single source of truth The same offer or article gets copied and edited separately across each site instance.
- Migration treated as lift-and-shift Moving pages one-to-one into Contentful carries forward the old site's structural problems.
Business Impact:
Time Wasted: Editors keep duplicating content across site instances because no shared structure exists to reuse it.
Cost Implication: Teams re-model content midway through the build, adding another design and migration pass before launch.
Opportunity Cost: New sites or channels need bespoke template work instead of reusing an existing structure, slowing every future launch.
Solution
A model-first approach defines content types for meaning, not layout, before any front-end component is built, so new sites or channels can reuse the same structure.
Our Approach:
- Audit existing content and channels (Early discovery)
Catalogue every site, channel and content type currently in use, including fields that mix layout and meaning.
- Design the content model (Modelling phase)
Define content types and references that work across every channel, independent of any single template.
- Build the front end against the API (Build phase)
Build components that query Contentful's content delivery API, rather than assume a fixed page layout.
- Migrate and verify (Migration phase)
Move content in batches, checking redirects and references at each stage before decommissioning the old system.
Expected Outcome: A content model a non-technical editor can extend to a new site or channel without further development work.
Key Takeaways
What Decides a Contentful Migration's Success
- The content model matters more than the editor interface chosen.Critical
A model built around meaning and reuse survives new sites and channels; one copied from the old site's layout needs rework at every launch.
- Multi-site and multi-channel estates get the most value from Contentful.Important
A single brochure site with one layout rarely needs Contentful's reuse model; the return comes from running several properties off one structure.
- Migration risk hides in redirects and merged fields, not content volume.Critical
Old CMS fields that mix layout and meaning don't map one-to-one into Contentful types, and incomplete redirect maps usually surface only after cutover.
- Contentful developers and a GraphQL-literate front-end team work together.Important
The build pairs a defined content model with a front end that queries Contentful's API directly, with no fixed template engine controlling the page.
Getting a Contentful migration right depends on the content model, not the editor UI, and on planning for reuse across every site and channel before any component gets built.
Modelling and Migration Risk
Content Modelling, Multi-Channel Reuse and Migration Risk
Contentful earns its complexity when a business runs several sites, channels or apps from one shared content model. A single brochure site with one layout rarely needs that model; the return comes from reuse across properties, campaigns and apps that would otherwise each need their own editing workflow.
Teams migrating off a CMS where content and layout are merged typically discover their redirect map is incomplete only after cutover, when search traffic to old URLs reveals pages nobody flagged during planning. Mapping every existing URL, field and taxonomy before migration starts is the step most often underestimated, not the Contentful build itself.
Where a front end needs to combine Contentful's content delivery API with other real-time data sources, the integration patterns look similar to the GraphQL schema integration work used in data-heavy interfaces elsewhere: schema design, query batching and caching strategy matter as much as the content model.
National Digital has supported the NRMA Parks and Resorts platform since January 2023 (case study), continuing to extend the content model as new parks and offers come online.
Contentful Development and Migration: Common Questions
How long does a Contentful migration usually take?
Timeframes vary with the number of site instances and content types involved. A migration starting from a well-defined content model and clean source data moves faster than one starting from inconsistent fields spread across several WordPress installs.
What does designing a Contentful content model actually involve?
It means defining content types, fields and references around what content means, such as an article, an offer or a location, rather than how any one page currently looks. A model that holds up across every site and channel takes longer to design upfront but needs far less rework later.
What should I look for in a team building or migrating a Contentful platform?
Look for a team that can show a finished multi-site build, not just Contentful familiarity. Ask how they've modelled content for reuse across channels, and how they handle migration risks like redirects and merged legacy fields.
Can Contentful replace a WordPress multi-site setup?
Yes, for businesses running several related sites or brands from one content source. Contentful separates content from presentation, so one editorial team can manage entries that render differently across each site's front end.
Do I need custom development for a Contentful build, or can I use a template?
Contentful ships no front end, so every build needs custom development: a Next.js or similar application queries its API and renders the pages. Pre-built themes don't exist for Contentful the way they do for WordPress.
What do contentful developers actually do during a build?
They design the content model, build the front end against Contentful's GraphQL or REST content APIs, set up preview and publishing workflows, and plan the migration of existing content into the new structure.
