Migration plan, written down
Source content inventory, target schema design, redirect map, cutover plan with a rollback path. We don't start migration until the plan is signed.
// headless cms migration
Migrate to a headless CMS without losing rankings.
We move sites off WordPress, legacy Contentful, Drupal, or hand-rolled CMSes onto Sanity, Storyblok, or Contentful — with the redirect map, structured-content schema, and editor training that make the move stick. Scoped per project.
// why teams replatform
The CMS you have is the bottleneck on everything you ship next.
- Editors copy HTML between fields because the schema doesn't fit how content actually works.
- Every layout change is a developer ticket — content team blocked on engineering capacity.
- Plugin sprawl: 40+ WordPress plugins, each one a security and upgrade risk.
- Preview is a guess. Publish is a hope. Reverting a bad change takes a database restore.
- Performance budget shot — Core Web Vitals failing because the CMS ships every render server-side with cruft.
- You can't reuse the same content across web, mobile, and email — each surface re-implements the same data.
// what's included
What ships at handoff.
Structured-content schema
Documents, objects, and references modeled around what content IS — not where it currently appears. Reusable across web, app, email, in-store displays. Sanity, Storyblok, or Contentful, depending on team fit.
Custom CMS authoring experience
Studio configuration tuned to your editors' actual workflow. Custom inputs, structure builder, document actions, real-time preview against staging.
Content migration script
Idempotent, re-runnable script that pulls every post, page, term, taxonomy, image, and reference from the old CMS and writes the new model. Includes a content-parity report.
SEO continuity package
URL redirect map (one-to-one for every indexed URL), updated sitemap.xml, schema.org carry-over, lastmod tracking, GSC monitoring through cutover.
Editor training + runbook
Recorded walkthroughs for content team, written runbook for ops, decision log for the architecture choices we made and why.
// how we work
Three phases. Built to last.
01 · Calibrate
Content audit on the old CMS. Schema design for the target. Redirect strategy. Cutover plan with a rollback. Written scope before any migration runs.
02 · Build & migrate
New CMS configured in parallel with the migration script. Weekly demo on staging with real migrated content. Content team trains on the new Studio while we build.
03 · Cutover & support
Production migration in a maintenance window. Redirects live. SEO monitoring through the post-launch period. Post-launch support window starts at cutover.
// common questions
What teams ask before committing to a CMS migration.
Yes — when it's planned that way. We build a one-to-one redirect map for every indexed URL, carry over schema.org JSON-LD, preserve canonicals and hreflang, and monitor Google Search Console through cutover. We've moved sites with six-figure monthly organic traffic without losing rankings. The risk profile is high if you skip the redirect plan; near-zero if you don't.
Sanity for editorial-driven teams that want a custom Studio and structured Portable Text. Storyblok for marketing teams that want a visual editor and component-based authoring. Contentful for larger orgs that need formal review workflows, role-based access, and audit logs. We pick based on team size, editor profile, and content reuse needs — not based on which one we like best.
Scoped per project. Factors that shape the timeline: number of content types, custom field complexity in the source CMS, reference depth, image volume, and how much content cleanup is needed (most legacy CMSes carry orphan posts, broken images, and unused taxonomies that surface during the audit).
We replace the functionality, not the plugins. Forms move to a typed API endpoint or service like Web3Forms. SEO plugins become structured metadata in the new schema. Image optimization moves to Next.js or a dedicated CDN. Caching is handled at the edge. The end result is fewer moving parts, not a rewrite of every plugin.
Yes. The migration script is idempotent — re-runnable until cutover. Editors keep publishing on the old CMS; we re-pull right before the maintenance window. Content is frozen on the old CMS for the cutover window only, not for the duration of the project.
We can do a phased migration — move content types in priority order, with the old and new CMS both serving routes via a proxy. Adds scope but reduces cutover risk. Common pattern for sites with high-traffic blog content that needs continuous publication.
Usually yes — we build the headless storefront or marketing site in Next.js as part of the engagement. If you have an existing Next.js, Nuxt, or SvelteKit frontend, we integrate the new CMS into it. We don't migrate to a headless CMS without a plan for the frontend that consumes it.
Sanity and Contentful both have built-in document history. We configure the retention window and document-action shortcuts to your team's workflow. The migration script keeps the old CMS as a read-only backup post-cutover.
Murcia, Spain. Remote across Spain, the EU, the UK, and North America. On-site visits when the project warrants it. Delivered in English or Castilian Spanish.