Table of Contents
TL;DR
- WordPress migrations break in the first 72 hours after cutover. DNS propagates inconsistently across regions. SSL throws errors on subdomains. Stripe webhooks return 404 because the new server’s IP is not registered with the third-party. Cloudways’ March 2026 checklist names twenty-five validation steps the migration tool does not run for you.
- An AI-drafted migration plan feeds an AI chat eight artifacts — current host, destination host, database size, plugin list, media library size, DNS provider, SSL strategy, and custom integrations. The output is a host-pair-specific playbook in five sections covering pre-flight, TTL window, cutover sequence, post-migration validation, and rollback procedure.
- The five-step workflow runs across two sittings. Inventory the source site, pull the destination host’s documented migration support, feed the chat for a host-pair-specific plan, pre-stage and run hosts-file validation against the live URL, then execute cutover with TTL set to 300 seconds 48 hours prior plus 72 hours of monitoring.
- Three traps. Skipping the hosts-file pre-cutover test (Two Row Studio’s breakage list names broken paths, credential mismatches, and redirect loops as failures the migration tool misses). Trusting the AI plan over the destination’s expert support (Kinsta does it free in one business day). Killing the old host within 48 hours of cutover (rollback requires the old IP live for at least 72 hours per Multidots’ January 2026 guide).
- A migration is not a transfer. A migration is a coordinated cutover. The transfer takes minutes — the coordination takes days. Treat the cutover as the start of the validation window, not the end of the project.
The clock reads 11:47 PM on a Tuesday. The DNS A record changed forty minutes ago. The new managed host’s IP responds to ping.
Curl returns the homepage HTML. Everything looks healthy from your laptop.
A user in Berlin opens the site and sees the old version. A user in Tokyo sees a half-styled page where the CDN URLs still point at the old host. The contact form submits but the transactional email never arrives. Stripe webhooks return 404 because the new host’s nginx config has not been told about the webhook URL.
The migration tool reported a clean transfer. The dashboard says the new host is healthy. The first seventy-two hours are when everything you forgot surfaces.
This piece is about how an AI chat drafts a migration plan tuned to your specific host pair, two days before any of that happens.
Why is a WordPress migration so easy to break?
WordPress migrations are easy to break because the failure modes are not in the migration tool’s job description.
Cloudways’ March 2026 migration checklist names twenty-five separate validation steps. Seven pre-cutover, eight during, ten post-cutover. Each step protects against a specific class of failure that automated tools miss because the failures are environmental rather than file-transfer issues.
DNS propagation is the first source. Even with TTL set to 300 seconds 48 hours before cutover, propagation across global resolvers can take 4 to 8 hours. During that window, half your visitors hit the old host and half hit the new one.
Forms submitted on the old server land in databases that no longer accept new writes. Carts created on the new server cannot reconcile with sessions that started on the old one.
SSL is the second. The destination host issues a fresh certificate. The certificate’s chain may not match what your CDN expected. Subdomains that worked yesterday throw mixed-content warnings today.
Custom integrations are the third. Multidots’ January 2026 enterprise migration guide names Stripe webhooks, Salesforce APIs, and HubSpot tracking as the integrations most likely to break silently. The migration tool transfers the plugin code. It does not register the new server’s IP with the third-party service that the plugin talks to.
Plugin behavior is the fourth. A caching plugin tuned for the old host’s filesystem layout fails on the new one. A backup plugin pointing at the old host’s S3 bucket continues to back up nothing. The WordPress backup verification walkthrough catches that silent-backup case before the migration runs, not after.
The 25-step checklist is necessary. The 25-step checklist is also generic. Your migration is the host pair multiplied by your plugin stack multiplied by your integration list. The plan needs to know that combination.
What does an AI-drafted migration plan actually do?
Think of an AI-drafted migration plan as the moving checklist that already knows your furniture. The generic checklist tells you to wrap the dishes. The custom checklist names which dishes you have.
The custom checklist names which boxes those dishes go in. The custom checklist names which truck shelf the boxes ride on so the antique china does not break.
You feed an AI chat eight artifacts about your migration:
- Current host name and tier
- Destination host name and tier
- Database size in megabytes
- Plugin count and list with versions
- Media library size in gigabytes
- DNS provider name
- SSL strategy on the destination
- Custom integrations — Stripe webhooks, Salesforce, HubSpot, transactional email vendor
You ask for one specific output — a host-pair-specific migration plan in five sections:
- Pre-flight checks (PHP and MySQL parity, plugin compatibility, integration registration)
- TTL reduction timing
- Cutover sequence with hosts-file validation
- Post-migration validation steps
- Explicit rollback procedure with timing
The plan reads as a numbered playbook tuned to your pair. The chat names the suspect failure modes for your specific stack. If your plugin list includes a caching plugin known to fight WP Engine’s built-in cache, the plan flags the swap before the cutover, not after.
How do you draft and execute the plan in two sittings?
The work splits into five steps across two sittings. The hosting evaluation matrix walkthrough is the prior read that turned a long list of managed-host candidates into the destination this plan now targets.
Step 1 — inventory the source site. Open a text file. Record:
- Database size from your hosting dashboard or via SHOW TABLE STATUS
- Media library size from the file manager or
du -sh wp-content/uploads - Plugin list with versions from Plugins, Installed Plugins
- DNS provider from your domain registrar
- SSL strategy currently in use
- Custom integrations — list every plugin or service that talks to a third-party API
Step 2 — pull the destination host’s migration support. Kinsta provides free expert migrations completed in one business day per their April 2026 documentation. WP Engine ships a free migration plugin you run yourself. Cloudways offers its own migrator tool. The destination host’s process determines what the chat needs to add on top of vendor support.
Step 3 — feed the chat with one specific prompt. Paste the inventory plus the destination host’s migration approach. Ask for a host-pair-specific plan in five sections covering pre-flight, TTL window, cutover sequence, post-migration validation, and rollback procedure. State the cutover deadline in plain English. The Friday morning email send is a real constraint, not a preference.
Step 4 — pre-stage on destination and run hosts-file validation. The destination host migrates files. You override your laptop’s hosts file to point your domain at the destination IP. You log in, submit forms, process test transactions, verify Stripe webhooks fire, check email delivery, run the WooCommerce checkout if applicable. Hosts-file validation is the only way to test the destination response before flipping DNS for the world.
Step 5 — execute cutover with rollback ready. Reduce TTL to 300 seconds 48 hours before per Multidots’ January 2026 enterprise migration guide. Flip the A record. Monitor for 72 hours.
Keep the old host running and billable until the window closes. The fix-today entry on the post-migration validation list applies first. Everything else gets calendar slots.
What can go wrong with this approach?
Three traps catch operators on a deadline.
Trap 1 — skipping the hosts-file pre-cutover test. The migration tool confirms files transferred and database imported. The hosts-file test confirms that your forms submit, your transactional emails arrive, your Stripe webhooks fire, and your CDN paths resolve.
Two Row Studio’s post-migration breakage list names three failures most likely to surface only after real traffic hits the new host:
- Broken image paths from incorrect file references
- Database credential mismatches
- Redirect loops from .htaccess conflicts
The hosts-file test catches all three before flipping DNS.
Trap 2 — trusting the AI plan over the destination host’s documented support. Kinsta’s free expert migration ships in one business day. That beats a self-execute on most stacks. The plan supplements the destination host’s process, but it does not replace it.
If your destination offers expert-managed migration, the plan focuses on what the destination cannot do:
- Post-migration validation
- Integration re-registration
- Custom DNS records the destination cannot see
Trap 3 — killing the old host within 48 hours of cutover. Rollback requires the old IP live for at least 72 hours. Multidots’ January 2026 enterprise migration guide names that exact window.
If a critical issue emerges and you have already canceled the old hosting plan, the rollback path is gone. Keep the old host running and billable until your monitoring window closes. The old hosting fee for a few extra days is the cheapest insurance in the migration.
How do you split the work across two sittings before cutover?
A defensible migration costs about three hours of planning plus a 4-hour cutover window plus 72 hours of monitoring.
The two sittings split as follows. Two hours one afternoon writes the inventory, pulls the destination host’s process, and runs the chat for a draft plan. The chat returns the playbook in seconds. The next morning runs hosts-file validation on the destination.
The morning session also refines the plan based on what the test surfaces, and books the cutover window with a calendar invite. The cutover itself is the third sitting — by then the playbook does the work.
A migration is not a transfer. A migration is a coordinated cutover. The transfer takes minutes for most sites. The coordination takes days.
The 72 hours after cutover are when the integrations you forgot to test surface. A defensible migration treats the cutover as the start of the validation window, not the end of the project. The plan accelerates the playbook. The 72-hour monitoring is still yours.
Other questions worth answering
Does a flip to a managed host affect search rankings in the first few weeks?
Rankings usually hold when redirects stay clean and the new host responds at parity speed. Cloudways’ March 2026 checklist names reconnecting Search Console and resubmitting the sitemap as required post-cutover steps. Watch crawl errors daily for the first two weeks. A small dip is normal during reindexing.
When should you reconnect Search Console after the new host is live?
Reconnect inside the first 24 hours once DNS shows propagated globally. Resubmit the sitemap on the same day. Per Cloudways’ 2026 checklist, follow-up indexing crawls should be requested several days later. Early reconnection shortens the window where Google sees inconsistent responses from the old and new IPs.
Where should transactional email routing be tested ahead of the A-record flip?
Test on the destination through the hosts-file override on your laptop. Submit a contact form, a password reset, and a checkout receipt. Per Multidots’ January 2026 enterprise guidance, transactional email delivery is part of the validation list. SMTP credentials often need to be re-entered on the new server.
How long should the old hosting subscription stay billable after the A record flips?
Keep the old subscription active for at least 72 hours after the A record flips. Multidots’ January 2026 guidance frames a sub-15-minute rollback as the prepared baseline. Rollback only works if the previous IP still serves traffic. Cancel the old subscription on day four, not day one.
What information does the destination host need from you to start a free expert handoff?
Kinsta’s documentation, last updated April 2026, lists the required handoff — source-host credentials, domain details, a contact for DNS, and any non-standard plugin notes. Gather these into one document beforehand. Submitting a complete packet shortens the one-business-day turnaround. A clean packet saves you a follow-up email cycle.
What goes in the rollback plan?
Three lines:
- The old-host IP address
- The DNS provider where you flip the A record back
- The maximum window after which rollback is no longer safe — typically 72 hours when TTL was set to 300 seconds 48 hours prior
Keep the old host running and billable until that window closes.
The previous post in this series is the hosting evaluation matrix that picked the destination host in the first place. The next post in this series is the backup verification plan that proves your restore actually works. That backup audit runs before the migration, not after.
If you want a calm second opinion on your draft migration plan before you reduce DNS TTL, you can contact me here. I read your inventory, look at your destination host’s process, and tell you which integration to test in hosts-file validation first. There is no pitch, no upsell, and the conversation is free.