What goes wrong
Redirects & URL mapping
The most common and most damaging migration failure. Redirect rules built up over years — pointing old URLs to new ones, managing legacy platform structures, preserving link equity — disappear when the server moves. On Apache servers this means the .htaccess file. On NGINX, server-level configuration. Neither migrates automatically. Neither gets checked unless someone specifically looks for it.
- Old platform URL structures left pointing nowhere
- WWW to non-WWW canonical redirect lost — duplicate content signals sent to Google
- Pagination redirects, feed redirects and legacy redirect chains broken
- Thousands of internal links pointing to URLs that no longer exist
SEO & plugin configuration
Every plugin that affects how your site behaves stores settings in the database. If those settings don't carry across — or if a plugin is deactivated during migration — you're back to defaults. The pages still load. The titles are just wrong.
- SEO plugin titles and meta data wiped — 530 pages in one case
- Noindex configuration reset — wrong pages appear in Google, right pages disappear
- Sitemap broken — permalink flush skipped, sitemap 404ing for weeks
- Caching plugin removed or misconfigured — performance degrades silently
- Security plugin settings reset — hardening rules lost
Images & media
If I had a pound for every migration where images didn't make it across, I'd have retired somewhere warm. Media cleanup tools that don't account for page builder references. CDN configurations that don't survive a server move. Upload folders that weren't included in the file transfer.
Media cleanup tools must be Pro versions on page builder sites — free versions don't scan ACF, Divi or Elementor fields correctly and will delete images that are in active use. The images won't be in the trash. They'll require a server restore.
Why crawl comparison is non-negotiable
The only way to know what a migration has damaged is to compare a full crawl before against a full crawl after. Not a spot check. A complete crawl: status codes, title tags, canonical tags, indexability, image responses — compared column by column using our crawler.
Without that comparison, you're working from memory and assumption. Neither surfaces 530 changed page titles or 398 missing images.
What the work involves
Pre-migration audit
The baseline that makes the post-migration audit meaningful. Run before anyone touches anything.
- Full site crawl using our crawler — status codes, titles, meta, canonicals, indexability, image responses
- Redirect rule export and full documentation
- URL mapping — old URLs to new destinations, legacy platform structures
- Page mapping — content, categories, taxonomies, structural changes planned
- SEO plugin settings export (Rank Math / Yoast)
- Plugin configuration documentation — caching, security, redirects, forms
- Current sitemap verification and GSC baseline
- Image and media library audit — folder structure, CDN configuration
- Database export confirmation — not just files
Post-migration audit
Delivered within 48 hours of the migration completing, before the damage compounds.
- Full crawl against the pre-migration baseline using our crawler
- Status code comparison — new 404s, redirect chains, server errors
- Title tag comparison — any reversion to WordPress defaults
- Indexability comparison — noindex changes in both directions
- Redirect verification — all documented rules tested end-to-end
- Image response audit across key page types
- Sitemap verification and GSC resubmission
- Plugin configuration check — SEO, caching, security, redirects
- Prioritised remediation list with clear ownership
Migration recovery
For sites where the migration has already happened and the damage is already done. Audit, prioritise, fix.
- Full technical audit of the current state against available baseline data
- Identification and documentation of all losses
- Redirect rebuild — .htaccess or NGINX configuration as appropriate
- SEO configuration review and repair
- Sitemap restoration and GSC resubmission
- Image audit and restoration brief for hosting provider
- Crawl monitoring setup
Plugins — what needs documenting before you move
SEO
- Rank MathExport settings before migration. Stores title, meta and schema data in wp_postmeta — database must migrate correctly or all custom title data is lost.
- Yoast SEOSame principle. Settings export available under Tools → Import/Export. Verify after migration.
Redirects
- RedirectionExport all redirect rules before migration. On NGINX servers this is your primary redirect management tool — the server-level configuration handles the persistent layer.
- .htaccess / NGINX configNot a plugin — but the most important file on an Apache server. Back it up. Check it's intact after migration. On NGINX, confirm with your host how server-level redirects are managed.
Caching
- FlyingPressConfiguration lost on server migration if not manually exported. Full rebuild required after any server move.
- WP RocketExport settings file before migration. Check CDN configuration survives the move.
- LiteSpeed CacheServer-dependent — some settings tied to server configuration rather than WordPress.
Security
- Really Simple SecurityCheck noindex and .htaccess rules after migration — settings can reset to defaults.
- WordfenceFirewall rules and IP blocks are database-stored but verify after migration.
Backup
- UpdraftPlusRun a full backup immediately before migration. Confirm both database and files are included. Store offsite — not on the server being migrated.
- All-in-One WP MigrationUseful for smaller sites. Verify file size limits at destination before migrating.
Media
- Media Cleaner ProIf running a media cleanup around migration time, use the Pro version — the free version does not scan page builder fields and will delete images in active use.
Get it in writing
A written contract specifying what the migration covers, what is excluded, and who is liable if something goes wrong. Verbal agreements are not agreements. If it is not in writing it does not exist.
Keep your own access
Full admin access to the website, database, Google Analytics, Search Console and any other tools should remain with you throughout and after the migration. You should never be in a position where access to your own site depends on a third party relationship remaining intact.
Know what server you're moving to
Apache or NGINX. This affects how redirects are managed, how caching is configured, and what your SEO consultant or developer needs to know before touching anything. Ask before the migration happens, not after.
Platforms
WordPress / WooCommerce
Migration & recovery
Shopify
Migration & recovery
Visualsoft
Platform exit
Magento
Migration
Server migration
Any platform
CMS migration
Any platform
E-commerce retailer — two-stage migration failure
Two years. Two agencies. Two sets of damage.
The first agency was brought in to migrate the site from Visualsoft to WooCommerce. What they actually did was rebuild the site from scratch and leave the content behind. The majority of redirects were put in place but not all of them — and nothing else came across. No title tags. No meta descriptions. No historical content. A new site that looked like a migration but wasn't.
Twelve months of remediation work followed. Custom title tags written across hundreds of pages. Rank Math configured correctly. FlyingPress set up to handle Core Web Vitals. The redirect gaps identified and closed. The noindex settings set properly across taxonomy pages. Slow work but it was getting somewhere.
Then the second agency moved the site to a new server.
Post-migration audit identified 530 pages with wiped SEO titles — every custom title replaced with WordPress defaults. 398 images deleted across 15 monthly upload folders. FlyingPress gone. Rank Math configuration reset to defaults including noindex back on across taxonomy pages. The entire .htaccess redirect block dropped. A broken sitemap undetected since the migration date.
Everything built in the twelve months of recovery work. Gone in an afternoon.
The .htaccess was rebuilt from scratch, verified against a pre-migration crawl and a detailed remediation brief sent to the hosting provider covering the specific database tables and upload directories requiring restoration. Total remediation time from audit to implementation: one working day. Total time to get back to where we were before the second agency touched it: considerably longer.
Dealing with migration damage?
Bring what you know about the current situation and we'll go from there. A post-migration audit takes a day. Undoing the damage from not doing one can take considerably longer.