This is an illustrative composite scenario. It does not describe any single real organization; it generalizes patterns we see repeatedly across WordPress rebuild projects. Figures are typical ranges, not one company’s exact numbers.
Context
Picture an established business on WordPress that had accumulated a decade of decisions: a heavy page-builder theme, forty-plus plugins, a couple of acquired microsites bolted on, and a sitemap nobody fully trusted. Nothing was “wrong” with WordPress — the goal was a ground-up rebuild on the block editor with a modern theme, a single consolidated install, and a faster host. Same CMS, new everything.
That “same CMS” framing is exactly what makes WordPress-to-WordPress replatforms go sideways. Teams skip the migration discipline they would apply to a cross-platform move, assuming content just carries over. It does not, because the thing being replaced — the theme, the builder, the URL structure, the plugin stack — is where the content actually lived.
What broke
Page-builder lock-in
The old site’s pages were built in a proprietary page builder that stored layouts as its own shortcodes and markup. On the new block theme, that markup rendered as raw shortcode text or empty boxes. There is no clean automatic conversion from one builder’s format to native blocks — the richest, most-visited pages had to be rebuilt, and that re-authoring was the biggest single task in the project.
URL changes on the restructure
Consolidating the microsites and cleaning up the information architecture changed permalinks across the site. WordPress does not redirect old URLs for you when structure changes, so without a complete 301 map the rebuild would have dropped rankings on content that was otherwise untouched — the most avoidable kind of traffic loss.
Plugin consolidation drops features
Cutting the plugin count from forty to a dozen was a goal, not an accident — but each removed plugin took its shortcodes and features with it. Pages that relied on a retired plugin’s shortcode broke silently. Every plugin being dropped needed a plan for the content that depended on it.
Media, domains, and SEO metadata
Moving hosts and consolidating installs changed media URLs and, in places, the domain. In-body image links and hardcoded absolute URLs broke where they were not rewritten. And the SEO plugin’s per-page titles and meta descriptions had to be carried across deliberately, or years of tuning would have reset to defaults.
What worked
The rebuild went well where the team treated it like a real migration. They ran a full content audit first and retired a surprising amount of thin and duplicate content instead of paying to rebuild it. They converted high-value pages to blocks by hand and accepted that as core work rather than hoping for a plugin to do it. They built the redirect map from a crawl of the live site before cutover, and they validated everything on a staging install that mirrored the new host before flipping DNS.
Lessons
- “Same CMS” is not “same content.” A theme, builder, and host change is a real replatform — apply migration discipline.
- Builder content does not convert cleanly. Budget to rebuild page-builder pages as blocks; there is no lossless shortcut.
- Any structure change needs redirects. Crawl the current URLs and map 301s before you restructure or consolidate.
- Dropping a plugin drops its content. For every retired plugin, plan for the shortcodes and features pages relied on.
- Carry SEO metadata across. Migrate titles and descriptions explicitly; do not let them reset to theme defaults.
Before you make this move
- Audit all content and retire the thin, stale, and duplicate before rebuilding anything.
- Inventory every page-builder layout and plan the block rebuild for the high-value ones.
- Crawl current URLs and build the 301 map for any permalink or domain change.
- List every plugin, mark which are being dropped, and plan for the content each supported.
- Export SEO titles and descriptions and migrate them; validate on a staging install that mirrors the new host.
A pre-migration scan turns this into a concrete backlog rather than a series of launch-day surprises. Replatform Radar inventories your pages, redirects, plugins, and SEO signals so a WordPress rebuild ships without quietly losing what already worked.