Teams reach this decision for three recurring reasons: the WordPress editor feels slow even on decent hosting, the admin is buried under plugins nobody remembers installing, and Core Web Vitals refuse to improve no matter how many themes are tried. Moving to a headless architecture is not a silver bullet, but it returns control over performance, security, and the editorial flow. What follows is the recipe we apply when a client asks us to leave WordPress without losing search rankings or months of editorial work.
-
Audit. Before touching anything, we inventory everything: content types (posts, pages, custom post types), custom fields (ACF, Meta Box), taxonomies, plugin-generated shortcodes, total post count, and the split per author. If there are 12,000 posts and half use a shortcode from a discontinued plugin, that shapes the plan. We document each item in a sheet with its count and its destination in the new system.
-
Pick the stack. For sites with frequent publishing and several authors we recommend Next.js with a headless CMS such as Sanity or Contentful. For technical blogs with one or two editors, static Markdown plus Decap CMS is cheaper, faster, and versioned in Git. The rule of thumb: if editors are non-technical and publish daily, pay for the CMS; if they are developers or publish weekly, plain MD is enough.
-
Export. We use the WP REST API to pull clean JSON, or WXR when metadata must be preserved. The usual pain points are three: attachment IDs embedded in content, oEmbed shortcodes that only WordPress resolves, and Gutenberg block JSON mixed with raw HTML. We write a transformer that normalises everything to Markdown or to the target CMS schema.
-
URL map. We list every public URL of the current site, decide which one is canonical in the new site, and prepare the 301 plan. Skipping this step means losing organic traffic for months. The map lives in a CSV with three columns: source, destination, expected status code.
-
Media. Images can stay in wp-content/uploads behind a redirect, or move to S3 or Cloudflare R2 with rewritten srcsets. If the site exceeds a few hundred megabytes, moving to a CDN is the right call: the LCP improvement is usually immediate.
-
Parallel period. We bring the new site up at staging.domain.com with robots.txt set to noindex, give editors access, and let them test for two or three weeks. This is the time to hunt bugs without pressure.
-
Cutover. We flip DNS during a low-traffic window, validate the new sitemap in Search Console, and request reindexing. For the first 48 hours we watch crawl stats and 404 errors closely.
-
Editor training. We run a recorded session with the new CMS, document the flow in a README inside the repo or in Notion, and leave clear contacts for support.
What we do not migrate: comment threads from ten years ago, empty category pages, and broken affiliate links. A migration is the best opportunity to throw out what no longer earns its place.