A WordPress migration rollback plan documents how to restore production to the pre-migration state if cutover fails — before you switch DNS, not after visitors report broken checkout. Every migration project needs one. Most DIY failures become disasters because rollback was an afterthought and the old host was cancelled day one.
Write this document during Phase 2 of the WordPress migration checklist. Test that your backups actually restore. A rollback plan referencing corrupt backups is fiction.
Rollback triggers: when to abort cutover
Do not switch DNS (or revert immediately if already switched) if any of these fail on the destination during pre-cutover testing:
| Trigger | Severity |
|---|---|
| Admin login impossible | Critical — abort |
| Homepage 500/502/503 error | Critical — abort |
| WooCommerce checkout cannot complete test order | Critical — abort |
| Contact form does not deliver email | High — abort unless forms are non-critical |
| More than 5% of tested URLs return 404 | High — abort |
| Mixed content breaking checkout or login | High — abort |
| Redirect loop on live domain test (hosts file) | Critical — abort |
| Database serialization corruption (widgets/settings blank) | Critical — abort |
| SSL certificate invalid or expired | Critical — abort |
| Payment gateway test transaction fails | Critical — abort |
Go/no-go meeting: Assign one person authority to call abort. Stakeholder pressure to "just launch" is how broken migrations go live.
Rollback plan template
Copy and fill in before migration day:
“`
ROLLBACK PLAN — [Site Name]
Migration date: ___________
Cutover window: ___________
Go/no-go authority: ___________
SOURCE (CURRENT LIVE)
- Host: ___________
- IP: ___________
- SFTP/SSH: ___________
- Database: ___________
- Backup location: ___________
- Backup verified (date): ___________
DESTINATION (NEW)
- Host: ___________
- IP: ___________
- Test URL / hosts file method: ___________
DNS
- Provider: ___________
- Current A record: ___________
- Pre-lowering TTL (date/time): ___________
- TTL value before/after: ___________
ROLLBACK STEPS
- ___________
- ___________
- ___________
COMMUNICATION
- Internal notify: ___________
- Status page / social: ___________
OLD HOST RETENTION
- Keep active until: ___________
- Cancel date (NOT before): ___________
“`
Component 1: Verified backups
Rollback starts with restorable backups taken before migration work began — not after partial changes.
File backup
- Location: ___________ (off-server — S3, local drive, backup plugin remote storage)
- Size: ___________
- Verified: extracted and contains wp-content, wp-config, .htaccess
Database backup
- Location: ___________
- Size: ___________
- Verified: opens in text editor or imports successfully to test database
Backup restore test (mandatory)
Before cutover, restore backup to a sandbox and confirm:
- [ ] Site loads on sandbox URL
- [ ] Admin login works
- [ ] At least one form or checkout path works
If restore test fails, fix backup process before proceeding. Database details: WordPress database migration guide.
Component 2: Keep old host alive
Rule: Do not cancel old hosting until 48–72 hours minimum after successful cutover. Prefer 30 days for high-value sites.
During rollback window, old host should:
- Remain powered on with files and database intact
- Not receive intentional content updates (or document any that occur during parallel-run window)
- Be accessible via direct IP or original DNS if rollback needed
Canceling old host on migration day eliminates your fastest rollback path.
Component 3: DNS rollback procedure
Standard A record migration
Forward (cutover):
- Change A record from OLD_IP to NEW_IP at DNS provider.
Rollback:
- Change A record from NEW_IP back to OLD_IP.
- Wait for TTL propagation (300 seconds if TTL was lowered).
- Purge CDN cache if Cloudflare or similar fronts the domain.
- Verify old host serves traffic: `curl -I https://yourdomain.com` shows OLD_IP response headers or check access logs on old host.
Rollback time: 5 minutes to 2 hours depending on TTL and CDN.
Cloudflare origin switch
Forward: Change origin server IP in Cloudflare DNS or Load Balancing.
Rollback: Revert origin IP to old host. Near-instant for proxied records.
Guide: migrate WordPress without downtime.
Domain change rollback (harder)
If cutover included domain change (`old.com` → `new.com`):
- Rollback means pointing `new.com` traffic away and ensuring `old.com` still serves the original site with 200 responses.
- Keep old domain DNS and hosting active.
- If old domain now 301s to new, rollback requires removing those redirects first.
Domain changes need longer old-domain retention (12+ months for SEO anyway). See change WordPress domain.
Component 4: Database rollback
If DNS was switched but destination database is corrupt:
- Revert DNS to old host (immediate traffic fix).
- Old host database is unchanged if no write sync occurred — site resumes immediately.
- If orders/content were created on new host during partial cutover: manual reconciliation required — export new orders, import to old host, or accept data loss on new host entries.
Prevention: Do not enable bidirectional sync unless you have explicit merge tooling. Most migrations are one-way.
If old host database was modified during migration attempt:
- Restore old host database from pre-migration backup via phpMyAdmin or WP-CLI `wp db import`.
- Restore files if modified.
Component 5: Staging deploy rollback
For staging to production pushes:
Before push: Production backup (files + database).
Rollback:
- Restore production database from pre-push backup.
- Restore production files from pre-push backup (or Git revert for code-only deploys).
- Purge cache.
- Verify production orders/users intact.
File-only deploy rollback: Git revert or restore theme folder from backup — no database restore needed.
Rollback decision timeline
| Time after cutover | Rollback approach |
|---|---|
| 0–30 minutes | DNS revert immediately if critical failure |
| 30 minutes – 4 hours | DNS revert + investigate destination offline |
| 4–48 hours | Fix-forward if issue is isolated (one plugin, one redirect). Revert if core broken |
| 48+ hours | Fix-forward preferred — DNS already propagated globally; rollback causes second disruption |
After 48 hours, fix-forward with targeted patches unless destination is completely non-functional.
Communication plan
Draft before cutover:
Internal (team/ client):
> Migration cutover scheduled [date/time]. If critical issues occur within [window], we revert DNS to previous host. Expected propagation: [X minutes]. Contact: [name].
External (if maintenance mode used):
> Brief maintenance complete. If you experience issues, contact [email].
Do not announce "migration complete" until post-cutover checklist passes.
Post-rollback recovery
After successful rollback:
- Document what failed on destination — error logs, screenshots, test results.
- Keep destination environment for debugging (do not delete).
- Fix issues on destination offline.
- Re-run full pre-cutover checklist.
- Schedule second cutover attempt — do not rush same day unless failure was trivial (typo in DNS).
Common fixes before retry: fix WordPress migration errors.
Rollback vs fix-forward
| Situation | Recommendation |
|---|---|
| Site completely down | Rollback |
| Checkout broken | Rollback |
| One page 404 | Fix-forward |
| Slow performance | Fix-forward (unless unusable) |
| Minor styling issue | Fix-forward |
| Widgets missing (serialization) | Rollback + fix replace method |
| Email not sending | Fix-forward if site otherwise functional |
Professional migration rollback guarantee
Scoped WordPress migration services include rollback plan documentation and execution within the agreed cutover window. Fixed-fee scope should clarify:
- How many cutover attempts included
- Rollback execution responsibility
- Old host retention requirement (client must keep account active)
Typical estimate: $250–$2,500 depending on migration type. WordPress migration cost.
FAQs
How long should I keep backups after successful migration?
Minimum 90 days. Many teams keep pre-migration backup indefinitely archived. Storage is cheap; re-migration from scratch is not.
Can I rollback after canceling old hosting?
Only if you have off-server backups and time to reprovision the old host. Recovery takes hours to days vs minutes with live old host.
Does rollback hurt SEO?
DNS revert on same domain: minimal SEO impact if revert happens within hours. Prolonged flip-flopping (multiple DNS changes in one week) confuses crawlers — avoid repeated attempts without fixing root cause.
Should I practice rollback before cutover?
Yes. Rehearse DNS revert in documentation walkthrough. Optionally test hosts file pointing back to old IP while team confirms procedure.
What if new host works but is slower?
Fix-forward with performance optimization — not rollback unless speed is business-critical and old host is definitively faster. Compare field data, not single Lighthouse runs.
—
Rollback planning is insurance you write before you need it. WordPress migration services include go/no-go criteria, backup verification, and rollback execution.
Book a free 15-minute migration consult.
September 12, 2026
WordPress Migration Cost: What to Budget in 2026
September 12, 2026
