Once your migration is complete and verified, the last step is telling the internet to send visitors to iWebVault instead of your old host. You do this by updating your domain’s DNS — and only now, after everything checks out.
Option A — Change nameservers (simplest)
At your domain registrar, set your nameservers to iWebVault’s. This hands DNS control to iWebVault, which already has your migrated zone records ready.
ns1.iwebvault.com ns2.iwebvault.com
This is the cleanest method because your migrated DNS records (A, MX, TXT, etc.) come into effect automatically.
Option B — Update the A record only
If you keep DNS elsewhere (for example at Cloudflare), don’t change nameservers — instead update your domain’s A record to point at your new iWebVault server IP, found in your welcome email or service details.
Timing the switch
Lower your DNS TTL a day before if you can, so the change propagates quickly. After switching, propagation usually completes within a few hours, though it can take up to 24–48 hours globally.
After the switch
- AutoSSL issues a fresh certificate once your domain resolves here
- Keep your old account running for a few days as a safety net
- Clear any caching plugin and CDN cache
Nameservers vs records — which to change
There are two ways to direct your domain to iWebVault, and which you use depends on where your DNS is managed. If you let iWebVault manage your DNS, you change your nameservers and everything else follows automatically. If you keep DNS at a third party such as Cloudflare, you leave nameservers alone and instead update the individual records that point at your server’s IP.
The nameserver method, step by step
- Log into your domain registrar (where you bought or manage the domain)
- Find the nameserver settings for your domain
- Replace the existing nameservers with iWebVault’s two nameservers
- Save, and wait for propagation
Because your migrated DNS zone already lives on iWebVault, switching nameservers brings all your records — web, mail, verification — into effect at once. This is the simplest path for most customers.
The records-only method
If you manage DNS externally, don’t touch nameservers. Instead, update your A record (and any subdomain A records) to your new iWebVault server IP, found in your welcome email. If you run mail on iWebVault, update MX records too. The advantage is you keep your existing DNS provider; the responsibility is remembering to update every relevant record, not just the root.
www or other subdomains, leaving part of your site pointing at the old server. List your records and update each one that referenced the old IP.Confirming the cutover worked
After propagation, a DNS lookup of your domain should return iWebVault’s nameservers (or your new IP). Visiting your site should serve it from iWebVault — you can confirm by checking it loads correctly and, shortly after, that the HTTPS padlock appears once AutoSSL issues your certificate.
Keeping a safety net
Leave your old hosting account active for several days after cutover. If anything looks wrong, you can repoint DNS back to the old host instantly while we investigate — a free, instant rollback that costs nothing but a few days of the old account’s life.
Choosing your method with confidence
The choice between changing nameservers and updating records comes down to one question: do you want iWebVault to manage your DNS, or keep it where it is? If you’re happy for iWebVault to handle DNS, the nameserver method is simplest — your migrated zone takes over automatically. If you rely on a third-party DNS provider (commonly for advanced features or a CDN), keep your nameservers and update individual records to the new IP instead.
Walking the nameserver path
Log into your registrar, find the nameserver settings for your domain, replace the existing entries with iWebVault’s two nameservers, and save. Because your migrated DNS zone already lives on iWebVault, this single change brings all your records — web, mail, and verification — into effect together. It’s the least error-prone path for most customers because there’s nothing to update record by record.
Walking the records-only path
If you keep DNS externally, leave nameservers untouched and update the A record for your root domain to your new iWebVault IP, along with the A records for any subdomains like www. If you host mail on iWebVault, update MX records too. The strength of this method is keeping your existing DNS features; the responsibility is updating every relevant record so no part of your site is left pointing at the old server.
Verifying and rolling back
After the change propagates, a DNS lookup should return iWebVault’s nameservers or your new IP, and your site should serve from iWebVault. Keep your old account live for several days afterward — if anything looks wrong, repointing DNS back to the old host is an instant, free rollback while we investigate. That safety net is the reason you don’t cancel the old account immediately.
Timing the change
Lower your record TTLs to 300 seconds the day before so the switch propagates fast, and make the change during a low-traffic window. Make it once and let it settle — repeatedly changing DNS only restarts caching timers and prolongs the transition. One clean change, then patience, is the fastest route to a completed cutover.
What’s next
Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.
Was this helpful?
Thanks for your feedback!
