How to Roll Back a Migration if Something Goes Wrong

One of the quiet strengths of the iWebVault migration approach is that it’s reversible. Because you keep your old account running until you’re confident, rolling back is fast and low-stress — usually just repointing DNS. This guide lays out the rollback procedure and when to reach for it.

Why rollback is easy here

The migration never deletes your old account — it only reads from it. So during the days after cutover, you have two working copies of your site: the new one on iWebVault and the original on your old host. If the new one has a problem you can’t immediately fix, you point DNS back to the old host and you’re instantly on the known-good copy.

The rollback procedure

1. Confirm the issue is real and not just DNS propagation settling
2. At your registrar or DNS provider, repoint your domain back to the old host (old nameservers or old IP)
3. Wait for propagation — visitors return to the old, working site
4. Tell us what went wrong so we can fix the iWebVault copy
5. Once fixed and verified, cut over to iWebVault again

When to roll back vs fix forward

Not every hiccup needs a rollback. A missing cache purge, a mixed-content warning, or AutoSSL not having issued yet are quick fixes you can make on iWebVault without reverting. Reserve rollback for a genuine, blocking problem you can’t resolve quickly — and remember that because the old site is live, you have the luxury of choosing calmly.

The window for rollback

Rollback is available as long as you keep the old account running — which is exactly why the guidance is always to keep it live for several days after cutover and not cancel immediately. Once you’ve confirmed iWebVault is serving cleanly for a few days, the old account has done its job as a safety net and can be retired.

After a successful period

Once your site has run cleanly on iWebVault for a few days and you’ve verified site, email, and any integrations, you can cancel the old account with confidence. At that point the migration is fully complete and rollback is no longer needed.

Reversibility is built into the approach

The reason rollback is simple is structural: the migration only ever reads from your old account, never deletes it, and you keep it running until you’re confident. So for the days after cutover you possess two working copies of your site — the new one on iWebVault and the untouched original. Rollback is just choosing which one your domain points at.

The procedure in full

1. Confirm the problem is genuine, not just DNS still propagating
2. At your registrar or DNS provider, repoint the domain to the old host
3. Wait for propagation — visitors return to the original working site
4. Report what went wrong so we can fix the iWebVault copy
5. Once fixed and verified, cut over to iWebVault again

Rollback versus fixing forward

Many post-cutover hiccups don’t warrant a rollback at all. A forgotten cache purge, a mixed-content warning, or AutoSSL not yet having issued are quick fixes you make on iWebVault while staying live. Reserve rollback for a genuinely blocking issue you can’t resolve quickly. And because the old site is available, you get to make that judgement calmly rather than under pressure.

Keep the window open

Rollback is possible only while the old account is alive — which is exactly why the standing advice is to keep it running for several days after cutover and never cancel immediately. The modest cost of a few extra days of the old account is your insurance for the whole migration.

Closing out

After your site has run cleanly on iWebVault for a few days — site, email, and integrations all verified — rollback is no longer needed and you can retire the old account with confidence. At that point the migration is genuinely complete, and the safety net has served its purpose.

What’s next

• Verifying a Migration Was Fully Successful
• How to Migrate With Zero Downtime
• DNS Propagation — What to Expect

Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.

Key takeaways

Rollback is simple because the migration never deletes your old account and you keep it live — so you have two working copies and can repoint DNS back to the old host instantly if needed. The lowered TTL makes rollback fast too. Reserve it for genuinely blocking issues; minor fixes are made on iWebVault while staying live. Keep the old account for several days as the safety net.

How long can I roll back?

For as long as you keep the old account running — which is why the advice is always to keep it live for several days after cutover. Once your site has run cleanly on iWebVault for a few days and you’ve verified everything, rollback is no longer needed and you can retire the old account.

Common mistakes to avoid

• Cancelling the old account immediately after cutover appears successful
• Rolling back for a minor issue better fixed forward on iWebVault
• Mistaking normal DNS propagation for a problem and reverting too soon
• Not lowering TTL beforehand, making any rollback slow

Rollback is the safety net that makes migrating low-stress: because the old account stays live, you can always step back to a known-good site. Keep that net in place for several days, reserve actual rollbacks for genuinely blocking issues, and you can approach every cutover knowing nothing is irreversible until you choose to retire the old account.