Part-2
Phase 07
SEO Preservation
SEO is where poorly executed migrations cause the most lasting damage. Ranking losses from a migration can take six to eighteen months to recover — and some never fully recover. This phase deserves as much rigor as the technical migration itself.
URL Structure
Ideally, preserve your URL structure exactly. Every URL change creates a redirect requirement, and redirects — even proper 301s — carry a small PageRank penalty. If URL changes are unavoidable, map every changed URL to its new destination before a single redirect is written.
| Scenario | SEO Risk | Mitigation | Action Required |
|---|---|---|---|
| URLs unchanged | Low | Verify canonical tags correct | Audit canonicals |
| Pagination structure changes | Medium | 301 redirects + update sitemap | Map all archive URLs |
| Category/taxonomy URL changes | Medium | Full redirect map required | Build URL mapping sheet |
| Domain change | High | Change of Address in GSC + 301 all | File GSC notice immediately |
| HTTP to HTTPS | Medium | Sitewide 301 + update GSC property | Update all internal links |
| Content consolidation / deleted pages | High | Redirect to nearest relevant page | No 404s on indexed URLs |
Migrating without a redirect map is like moving offices without telling your clients the new address. Google will figure it out eventually — but eventually costs you rankings.
Technical SEO Checklist
- Full redirect map built and validated before cutover
- XML sitemap regenerated and submitted to GSC post-launch
- Robots.txt verified (staging must block crawlers; production must allow)
- Canonical tags correct on all key pages
- Structured data (Schema.org) intact and error-free
- Google Search Console Change of Address filed (if domain changed)
- Core Web Vitals benchmarked on staging pre-launch
Phase 08
QA & Pre-Launch Testing
Testing a large WordPress migration requires a systematic approach — checking every integration, every content type, and every user flow. The staging environment at this point should be functionally identical to what will go live.
Content Integrity
Spot-check a representative sample of posts, pages, and custom post types. Verify that all ACF fields, metadata, and featured images transferred correctly. Check pagination on archive pages. Verify that internal links resolve correctly.
Struggling With WordPress Performance At Scale?
Functionality Testing
Test every form submission end-to-end including confirmation emails. Test e-commerce flows if applicable: product pages, cart, checkout, and order confirmation. Verify search functionality. Test any member-gated content.
Performance Benchmarking
Run Lighthouse audits on a representative sample of page types. Compare load times against the baseline from the old environment. Confirm caching is operational — a cache-miss response time above 800ms on a server-rendered page warrants investigation.
Redirect Validation
Validate your redirect map programmatically. A spreadsheet of 2,000 redirect rules that has never been tested is not a redirect map — it’s a wishlist. Use Screaming Frog’s redirect chains report against the staging domain to validate every rule before cutover.
Phase 09
Cutover & Launch
Cutover is the most time-sensitive phase of the migration. The goal is to minimize the window during which the old and new environments can diverge, and to make the DNS propagation window as brief as possible.
The Cutover Sequence
- 1.Lower DNS TTL 48 hours before
Drop TTL to 300 seconds (5 minutes). This ensures DNS changes propagate fast when you flip. - 2.Put old site in maintenance mode
Enables a final database export without new content being written during the migration window. - 3.Final database sync
Export production DB, import to new environment, run search-replace again to catch any last changes. - 4.Final media rsync
Delta sync to capture any media uploaded since staging was last synced. - 5.Update DNS records
Point A/AAAA records to new server IP. With 300s TTL, propagation is rapid. - 6.Validate live environment
Run immediate smoke tests: homepage loads, admin accessible, key integrations firing, no PHP errors in logs. - 7.Monitor for 48 hours
Watch error logs, uptime monitoring, and search console for anomalies. Keep old server live for at least 72 hours as a rollback option.
Schedule cutover for low-traffic windows. For most enterprise sites that means Tuesday–Thursday between 2–4am local time. Never migrate on a Monday morning or ahead of a planned campaign launch.
Post-Launch Monitoring
The 48 hours following cutover are not the time to stand down. Monitor server error logs in real time, watch your uptime tool, and have a team member checking Google Search Console for any sudden crawl errors or index drops.
Within the first week post-launch, run a full crawl of the live site and compare it against your migration manifest. Any 404s that weren’t in your planned redirect map need to be investigated and resolved immediately. In the first month, track organic search traffic weekly against your pre-migration baseline. A drop of more than 15% warrants a full technical SEO audit before the rankings loss compounds.
The migrations that fail publicly almost always had a successful staging run. The difference is always in the cutover execution — specifically, what changed between staging and go-live.
Key Numbers
| Metric | Value |
|---|---|
| Ideal DNS TTL pre-launch | 300 seconds |
| Old server retention post-launch | 72 hours minimum |
| Organic traffic drop threshold for audit | −15% |
| Recommended cutover window | 2–4am local |
| Max acceptable cache-miss response time | < 800ms |
Essential Tools
- WP-CLI — Command-line WordPress management. Essential for search-replace, cache flushing, and database operations at scale.
- Screaming Frog — Site crawling and redirect validation. The industry standard for pre and post-migration audits
- rsync — File synchronization over SSH. The right tool for large media library transfers.
- Google Search Console — Post-migration health monitoring and Change of Address filing.
- WP Migrate — Database and media migration plugin with search-replace built in, good for mid-size migrations.
WordPress Engineering Desk · Enterprise Platform Series · March 2026