We have shipped sixty-plus CMS migrations since 2017. WordPress to Shopify, Magento to Shopify Plus, Drupal to WordPress, Joomla to WordPress, custom-everything to Strapi, Squarespace to Webflow, ThemeForest WordPress to clean WordPress. Different sources, different destinations, different scales. The failure modes are the same five every time.
Here are the five places every CMS migration actually breaks, and the plays we run on each one. If you are about to commission a migration project, this is the punch list to walk through with your agency before the contract is signed.
1. Redirects
The first and most common breakage. The new site launches on a different URL structure than the old site. Every URL that the old site had — and that Google has indexed — needs to redirect to its destination on the new site. Otherwise organic traffic collapses on day one and the merchant calls in a panic at 11pm on the launch day.
The breakage happens in three flavors:
- The redirect map was generated but never tested. Old URLs are sent to 404s on the new domain.
- The redirect map covered the obvious URL patterns but missed the long tail — paginated archives, attachment pages, comment-thread URLs, author archives, query-string variants Google had indexed.
- The redirect map was set up on the wrong layer — at the application level instead of the CDN level — and the redirects never reach Google’s crawler at full speed.
The play: every migration we ship has a redirect map deliverable that covers three sources — the old database export, Google Search Console’s 12-month coverage report, and a fresh Screaming Frog crawl of the old site. Each URL is mapped to a destination and verified with an HTTP status check against the staging new site. The verification is part of the launch checklist, not an optional step. The redirect playbook is the same on every migration.
2. Content that does not survive the transfer
Content rarely moves cleanly between CMSes. The reasons are technical but the impact is editorial:
- Embedded shortcodes from the old CMS turn into raw HTML or plaintext in the new CMS. A page builder shortcode like [vc_row][vc_column] becomes visible text on the new site.
- Custom fields stored in postmeta tables migrate as long as the destination platform supports the same field types. Repeater fields, flexible content fields, and complex nested arrays often do not round-trip cleanly.
- Inline images keep their URLs pointing at the old domain’s media library. After the cutover, those URLs 404.
- Internal links keep pointing at the old URL structure even after the post moved.
- Embedded videos, embedded social posts, and oEmbed content render differently or not at all on the new platform.
The play: every migration has a content audit phase before the cutover. We run a small script that scans the migrated content for old-domain URLs, broken shortcode artifacts, and missing media references. The list goes to the editorial team for review. The cleanup is part of the project budget, not a surprise expense post-launch.
3. SEO meta drift
The new CMS has a different SEO plugin or a different way of storing meta titles, meta descriptions, canonical tags, and structured data. The migration script writes the values into the new fields but something in the wiring is off.
The most common drifts:
- Meta titles and descriptions migrate to the wrong field — sometimes into post content, sometimes into a different SEO plugin’s field, sometimes into a custom field that the new theme does not render.
- Canonical tags drop entirely. The new pages render without a rel=canonical, and Google indexes both old and new URLs.
- Open Graph tags lose the image references because the image URLs changed.
- Schema markup — Product schema, Article schema, BreadcrumbList — is platform-specific and rarely migrates without custom mapping.
The play: a meta-fidelity check on a sample of 50 to 200 high-traffic pages before launch, comparing the rendered HTML on the staging new site against the rendered HTML on the old site. Anything that drifts gets fixed before launch.
4. Integrations and tracking
The site is connected to other systems. Analytics. Marketing automation. CRM. ERP. Email service provider. Each connection needs a verified working state on the new platform.
The breakages:
- Google Analytics tracking ID was hardcoded in the old theme and not migrated to the new one. Traffic stops being tracked on launch day.
- HubSpot or Marketo form embeds were on the old pages and need to be re-added to the new pages.
- The CRM connection was a custom API call from the old theme that the new theme does not make.
- The ERP integration was pointed at the old database. It needs to be re-pointed and re-mapped.
- UTM tracking on landing pages drops because the new page structure broke the redirect chains.
The play: a complete integration inventory at the start of the project, with one verification step per integration on staging before launch. The inventory typically catches integrations the merchant has forgotten about — a five-year-old marketing automation pixel, an analytics tag from a previous agency, a CRM connection that has not been used in three years.
5. Editor training and workflow disruption
The site is technically migrated. The redirects work. The content is intact. The SEO holds. And then the editorial team cannot publish because the new CMS is different from the old one.
This is the failure mode that does not show up in the post-launch traffic dashboards but is the most common reason migrations get called ‘failures’ by the people who actually run the site.
The breakages:
- The editorial team was not trained before launch. They open the new admin on day one and do not know how to publish a draft.
- The new CMS has a different content model. Old workflows (custom post types, taxonomy structures, multi-author handoffs) do not exist or work differently.
- The publishing tools (scheduled publishing, content preview, multi-language toggles) that the team relied on are missing or different.
- The plugin or app the team used for a specific function — internal linking suggestions, content scoring, image optimization — is not on the new platform.
The play: editor training as a deliverable on every migration. Typically two to four sessions, each 60 to 90 minutes, with a written runbook for the specific workflows the team will use. The training happens in the two weeks before launch, on the staging environment, with the actual content. We bake training into every migration scope because we have seen it skipped enough times to know what it costs the project when it does not happen.
The hidden sixth: post-launch monitoring
Technically a sixth thing, but it is not a ‘place where the migration breaks’ so much as the way to catch the first five quickly when they do break.
Every migration we ship has a post-launch monitoring window — typically 30 to 60 days — where someone watches the analytics, Search Console coverage, redirect logs, error logs, and customer service tickets for signs of migration-related issues. The monitoring catches the things the launch checklist missed, before they become serious enough to show up in traffic numbers.
The point
None of these five failure modes are exotic. None of them require special tooling. They are predictable, repeatable, and avoidable. The reason migrations break in these places anyway is that most migration projects budget for the technical migration and forget that the migration is also a content project, a SEO project, an integration project, and an editorial project.
If your migration proposal does not have line items for all five, push back. The work is going to happen regardless. The only question is whether it shows up in the original scope or as a surprise on the invoice.