Move to Contentful without losing a single thing.
Specialist migrations from Drupal, WordPress, Sitecore, AEM, and bespoke systems into Contentful. Scripted, version-controlled, rehearsable — with zero content loss and zero downtime as the only acceptable outcome.
We've migrated content from every system you'd recognise.
Drupal 7 / 9 / 10→
Our home turf. Field-level mapping, paragraphs, taxonomy, media, multilingual.
WordPress→
ACF fields, custom post types, Gutenberg blocks, WPML translations, media library.
Sitecore→
Templates, datasources, multi-site, presentation details unwound and remodelled.
Adobe Experience Manager→
Components, content fragments, DAM, multilingual structure mapped to Contentful.
Umbraco / Kentico→
Document types and structured properties translated to Contentful content types.
Bespoke databases→
Custom CMS, MySQL, MongoDB, structured CSV — anything with a queryable schema.
A migration is a software project,
not a copy-paste job.
Every migration we run is scripted, rehearsable, and reviewable. We never click around in the UI. The same scripts run against staging on Tuesday and production on Saturday — that's how we get to zero downtime.
Source Audit
We inventory everything: content types, custom fields, taxonomies, media, redirects, URL patterns, user permissions, integrations, and the bits of business logic hiding in template files.
A written audit document with content inventory, complexity scoring, and migration risk register.
Target Modelling
We design the destination Contentful model. This is the moment to fix structural problems — not to recreate them. Old "kitchen sink" page types become reusable, composable content types.
Content architecture document and Contentful CLI migration scripts, version-controlled in Git.
Mapping & Transformation
For every source field, a target field. For every Rich Text body, a parser. For every reference, a lookup. Mapping is documented, reviewed, and code-reviewed before a single entry is written.
Field-by-field mapping spreadsheet plus transformation scripts (typically Node.js with the Contentful Management SDK).
Dry Run on Staging
Full migration runs against a staging Contentful environment — repeatedly. Each iteration finds new edge cases. We don't move forward until we have a clean, automated, repeatable run.
Reproducible staging environment that matches what production will look like, with diff reports against source.
Validation & QA
Automated checks (counts, references, media presence) plus editorial sign-off on a representative sample. Redirect mapping built and tested. Editors trained on the new model in a sandbox.
Validation report, redirect map, and editor sign-off checklist signed by content owners.
Cutover & Aftercare
Production migration on a planned cutover window with a rehearsed rollback plan. Frontend deploys, DNS switches, redirects go live. We stay on for 30 days of warranty support afterwards.
Live Contentful platform, warranty period, and full handover documentation. Optional: ongoing support retainer.
What a typical mid-size migration looks like.
Below is a representative project plan for a mid-size migration (around 5,000 entries, 6 content types, single locale, with a Next.js frontend rebuild). Larger or multi-locale projects scale proportionally.
Every migration is reproducible code.
We don't run migrations through the Contentful UI, and we don't trust anything we can't replay. Every transformation lives in version-controlled JavaScript using the Contentful Management SDK.
That means:
- →The same migration runs on staging on Tuesday and production on Saturday — identically
- →Every change is reviewed via pull request before it touches content
- →Rollback is just running the inverse migration script
- →If you add a new content type six months later, the patterns are already in place
- →Your team owns the scripts after handover — no agency lock-in
// Migrate Drupal articles → Contentful import { createClient } from 'contentful-management'; import { fetchDrupal } from './source'; import { toRichText } from './transforms'; const migrate = async () => { const client = createClient({ accessToken: process.env.CTF_TOKEN }); const env = await client .getSpace(SPACE_ID) .getEnvironment('staging'); const articles = await fetchDrupal('/articles'); for (const a of articles) { await env.createEntryWithId( 'article', a.uuid, { fields: { title: { 'en-GB': a.title }, slug: { 'en-GB': a.slug }, body: { 'en-GB': toRichText(a.body) }, hero: { 'en-GB': linkAsset(a.image) }, } } ); } }; migrate().catch(console.error);
Why most agency migrations over-run, over-spend, or quietly lose content.
Migration projects are where consultancies get rich and clients get burned. Here's what actually goes wrong, and how we avoid it.
"We'll fix it in production"
Manual UI edits to fix migration issues after go-live. Now there's no source of truth and staging has drifted irrecoverably from production.
Rich Text becomes plain text
The body field was HTML. Contentful Rich Text isn't HTML. Without a proper transformer, half your content formatting silently vanishes.
Broken reference links
Every internal link in your old CMS pointed to a node ID. Without redirect mapping, your SEO traffic falls off a cliff at cutover.
Media assets left behind
Images, PDFs, and embedded video referenced from old paths. Without an asset migration plan, your editors discover broken links for months.
"It worked on staging"
One-off staging migration, then a different sequence on production. We run the same scripts on both, repeatedly, until they're boring.
Recreating bad architecture
"Just port everything as-is" is the most expensive sentence in any migration. We use the move as a chance to fix structural problems, not preserve them.
"They migrated 14,000 articles, 23,000 media assets, and four years of structured editorial data from Drupal 7 to Contentful with one weekend of cutover and zero content-loss incidents. We had a full rollback ready and never needed to use it."
Three ways to migrate.
Every migration is unique, but most fit one of three shapes. All quotes are fixed-fee against an agreed scope, with transparent change control if scope shifts.
Migration Audit
- Source CMS audit & inventory
- Complexity & risk register
- Target Contentful model proposal
- Effort estimate for full migration
- Migration risk & mitigation plan
- Credited against full migration if engaged
Standard Migration
- Up to 5,000 entries, single locale
- Up to 8 source content types
- Full scripted migration in Node.js
- Staging dry runs & QA
- Cutover & redirect management
- 30-day warranty period
- Editor training included
Enterprise Migration
- Multi-locale & multi-space
- Complex source data (AEM, Sitecore)
- Frontend rebuild (Next.js / Astro)
- Integration migration (search, commerce)
- Full project management & PMO
- Dedicated engineering pod
- Optional: 12-month support retainer
Common questions.
Yes. The default approach is a parallel build: we run dry-run migrations into a staging Contentful space repeatedly while your live site stays untouched. Cutover happens on a planned window — typically a weekend — with a rehearsed rollback plan if anything goes wrong.
Critical, and built into every migration. We map every old URL to its new destination, generate the redirect rules, and test them as part of the staging dry run. We also preserve canonical tags, structured data, and Open Graph metadata where they exist on the source.
If you want — most enterprise migrations are paired with a Next.js or Astro frontend rebuild. We can also work alongside an existing frontend team and just deliver the migrated Contentful space.
The Migration Audit phase is where this gets caught — that's its job. If new content surfaces during the build phase, we have transparent change control: a written change request, an estimate, and your sign-off before any extra work happens. No surprise invoices.
Yes, with a freeze plan. Typically there's a content freeze for 24–72 hours around cutover, but the rest of the project runs against a snapshot of source data with delta migrations near the end to catch new content.
Honest answer: it does happen. The Migration Audit is partly designed to catch this — sometimes the right answer is Strapi, Sanity, or staying with Drupal. We support all of them, and we'd rather tell you that upfront than mid-project.
Start with an audit, not a leap of faith.
The Migration Audit is the cheapest insurance policy you can buy. Two weeks, fixed fee, fully credited if you engage us for the full migration. You'll know the scope, the risks, and the costs before you commit.