Moving hosts sounds risky and mostly is not, provided you do things in the right order. Nearly every migration that goes badly does so for the same reason: the DNS was pointed at a server that was not ready yet. This guide gives the sequence that avoids it, explains what DNS and TTL actually do during a move, covers the email question that catches most people, walks through what to test before and after the switch, and lists the mistakes that cause the downtime everyone fears.
Before you touch anything
- Take a full backup of the current site and database, and download a copy somewhere local. Do this even if the host has its own backups.
- Find out where your email actually runs. If it runs on the same hosting, it moves too, and email is the part that hurts most when it breaks. Establish this before anything else.
- Lower your DNS TTL to a short value, ideally a day before the move. TTL controls how long the rest of the internet caches your old server address. Lowering it early means the switch propagates quickly when you make it.
- Note every service using the domain — email, subdomains, any tool that verifies ownership through DNS.
What DNS and TTL actually do during a move
Your domain name is a label. DNS is the directory that turns the label into the address of a server. When you move hosts, the site exists in two places for a while, and DNS decides which one visitors reach. The catch is that the directory is cached all over the internet, by your visitors' internet providers, their phones and their office networks, and each cache keeps the old answer for as long as the record's TTL (time to live) says it may. A TTL of a day means some visitors keep arriving at the old server for up to a day after you change the record. A TTL of five minutes means the same visitors follow within minutes. That is why the TTL is lowered a day in advance: the old long TTL has to expire everywhere before the short one takes effect. Our plain-language DNS guide covers the record types.
Copy everything to the new host first
Set the site up completely on the new server while the old one is still live and serving visitors. Files, database, email accounts, and any scheduled tasks. Nothing about the public site changes during this stage — visitors carry on hitting the old host and never notice.
The migration checklist, step by step
| Step | What to do | When | Downtime risk if skipped |
|---|---|---|---|
| 1. Backup | Full backup of files, database and email, downloaded locally | Day 0 | No way back if the move goes wrong |
| 2. Audit the domain | List email, subdomains, verification records, third-party services | Day 0 | Something nobody remembered stops working |
| 3. Lower the TTL | Set the A and MX record TTLs to five or ten minutes | Day 0, at least 24 hours before switching | Visitors stuck on the old server for hours |
| 4. Copy | Files, database, mailboxes and scheduled tasks to the new host | Day 1 | None, the old site is still live |
| 5. Test | Preview on the new server, check pages, images, forms, login, SSL | Day 1 | A broken site goes live for everyone |
| 6. Content freeze | Stop editing, posting and processing orders on the old site | Just before the switch | Changes made on the old server are lost |
| 7. Final sync | Copy the database again so nothing added since step 4 is missing | Just before the switch | Recent orders or posts vanish |
| 8. Switch DNS | Point the records at the new server | A quiet hour | The step itself; keep it short |
| 9. Verify | Email both ways, forms, SSL, login, checkout | Within an hour of switching | A silent failure nobody notices for days |
| 10. Overlap | Keep the old host running, check it for stray email | One week | Email or visitors lost while caches expire |
| 11. Cancel | Close the old account, raise the TTL again | After the week | Paying for two hosts indefinitely |
Test on the new server before switching
This is the step people skip, and it is the one that makes the whole thing safe. Most hosts give you a way to preview the site on the new server before DNS changes — usually a temporary address, or you can point your own computer at the new server by editing your hosts file. Check the pages load, images appear, forms submit and any login works.
Fix what is broken now, while the live site is still happily running elsewhere. The things that most often differ between hosts are the PHP version, the path to uploaded files, the database connection settings, and the mail settings that forms depend on. A test run finds all four in an hour.
The email question, in detail
Email is where migrations go wrong, because it lives in three possible places and each one needs a different plan:
| Where email runs | How to tell | What moves | What to do |
|---|---|---|---|
| On the same hosting as the site | Mailboxes are created in cPanel; MX records point at the hosting server | Everything: mailboxes, stored messages, forwarders, autoresponders | Recreate every mailbox on the new host, copy stored mail, switch MX with the A record, check the old server for stragglers all week |
| With a separate email provider | MX records point at the provider, such as a business email service | Nothing | Leave the MX records exactly as they are when you switch the A record; do not let a host "helpfully" reset them |
| Forwarded to personal addresses | Addresses on the domain forward to free mailboxes | The forwarders | Recreate each forwarder on the new host before switching |
Also check the mail authentication records, SPF and DKIM. If they name the old server, messages sent from the new one may land in spam until they are updated. Our guide to business email on your own domain explains the records.
Then switch the DNS
Update the DNS records to point at the new server. With a low TTL set the day before, most visitors follow within minutes rather than hours. Some will still reach the old server briefly while caches expire, which is precisely why the next step matters.
If the domain's nameservers are also changing, rather than just the records, expect a longer tail: nameserver changes are cached at the registry level and can take a day or two to settle everywhere. Where possible, change the records at the existing DNS provider first and move the nameservers later, once everything is stable.
Keep the old hosting running for a week
Do not cancel immediately. For a short period some traffic still lands on the old server, and if email was involved a few messages may arrive there too. A week of overlap costs one month's hosting at most and removes nearly all the risk from the move. Cancel once you have confirmed nothing is still arriving at the old host.
Watch these three things afterwards
- Email. Send and receive a real message in both directions. This is the most common casualty of a migration.
- Forms. Submit a test enquiry. Forms depend on mail settings that often differ between hosts.
- SSL. Confirm the padlock is present and there is no browser warning on the new server.
For a store, add a fourth: place a real test order, including payment, and confirm the order appears in the admin and the confirmation email arrives.
Moving the domain at the same time
Moving the hosting and transferring the domain to a new registrar are two separate jobs, and doing them on the same day multiplies the risk. A domain transfer can take several days, and some registrars reset DNS records during it. The safer order is: move the hosting first, confirm everything works for a week, then transfer the domain once the site is stable. If the domain is close to expiry, renew it before starting either job; a domain that lapses mid-move takes the site, the email and your ability to fix anything offline at once. Our guide to transferring a domain covers the registrar side.
What actually causes downtime
Switching DNS before the new server is ready is the usual cause. The others are letting the domain expire in the middle of a move, cancelling the old host too early, and forgetting that email moved with the website. None of these are technically difficult problems — they are sequencing problems.
Common mistakes
- Switching DNS first and copying afterwards. The single biggest cause of a dead site.
- Leaving the TTL at a day. Visitors are split between two servers for hours.
- Skipping the final database sync. Orders and posts added during the copy are lost.
- Forgetting email runs on the hosting. Mail stops the moment the A record moves, with no mailboxes on the new side.
- Resetting MX records for email hosted elsewhere. Working email breaks for no reason.
- Cancelling the old host the same day. Stray visitors and messages have nowhere to go.
- Moving hosting and domain on the same day. Two sets of propagation and two things to debug at once.
- Migrating in a busy week. Pick a quiet period and a quiet hour.
- Not testing forms. Enquiries silently fail for weeks because the mail settings changed.
Where Gotka Technologies fits
You do not have to do any of this yourself. Migration to Gotka cloud hosting is free and handled by our team, including the testing step before anything is switched. Hosting starts at RM17.80/month on LiteSpeed servers with cPanel, free SSL, daily backups and a 99.9% uptime guarantee, and a 30-day money-back guarantee applies to a customer's first order of a new plan, which is long enough to migrate, test and decide.
If you are also moving the domain, transfers in are free and it is registered in your name. Gotka Technologies has operated in Malaysia since 2004.
Key terms used in this guide
- DNS: the directory that turns a domain name into the address of a server.
- A record: the DNS record that says which server hosts the website.
- MX record: the DNS record that says which server receives the domain's email.
- TTL (time to live): how long a DNS answer may be cached before it is looked up again.
- Propagation: the period during which caches around the internet pick up a changed DNS record.
- Nameservers: the servers that publish a domain's DNS records; changing them moves the whole DNS zone.
- Hosts file: a file on your own computer that can force a domain to a chosen server, used to preview a site before DNS changes.
- Content freeze: a short period before the switch when nothing is edited or ordered on the old site, so the final copy is complete.
- SPF and DKIM: DNS records that tell receiving mail servers which servers may send email for your domain.
Will my website go down when I change hosting?
It should not, if you copy the site to the new host and test it there before changing any DNS records. Downtime almost always comes from switching DNS to a server that is not ready yet. Lower your DNS TTL a day beforehand, verify the site works on the new server, then switch — and keep the old hosting running for about a week.
What is DNS TTL and why does it matter for a migration?
TTL is how long other systems on the internet cache your domain's server address before checking again. If it is set to a long period, some visitors keep reaching your old server for hours after you switch. Lowering it a day before the move means the change propagates within minutes instead, which shortens the window where visitors could see anything inconsistent.
How long does it take for DNS changes to take effect?
With a low TTL set in advance, usually minutes to about an hour for most visitors. Without that preparation it can take considerably longer, because caches elsewhere hold the old address until they expire. This is why lowering the TTL the day before is worth doing even though it feels like an unnecessary extra step.
What happens to my email when I move hosting?
If your email runs on the same hosting as your website, it moves with it, and this is the part most likely to cause real disruption. Establish where email is handled before you start, make sure mailboxes are recreated on the new server, and test sending and receiving in both directions immediately after the switch.
Should I cancel my old hosting straight away?
No. Keep it running for about a week after the switch. Some visitors and occasionally some email will still reach the old server while caches expire, and having it available means nothing is lost during that window. One extra month of hosting is cheap compared with recovering from an early cancellation.
Should I move my domain and hosting at the same time?
Better not. Move the hosting first, confirm the site and email work for a week, then transfer the domain once everything is stable. A domain transfer can take days and some registrars reset DNS records during it, so doing both at once doubles what can go wrong. Renew the domain before starting if it is anywhere near expiry.
Can someone else handle the migration for me?
Yes, and for most businesses that is the sensible option. Migration to Gotka is free and handled by our team, including copying the site, recreating email accounts and testing on the new server before any DNS is changed. You confirm the site looks right, and the switch happens once it does.
What to Check on Your Hosting Account in the First Week After You Sign Up
A first-week checklist for a new hosting account: confirm free SSL, set up email, find your daily backups, learn cPanel and know where to raise a ticket.
HostingShared Hosting vs VPS: When a Growing Business Should Move Up
Most business sites never outgrow shared hosting. The signals that say you have, what a VPS actually gives you, and why upgrading rarely fixes a slow website.
HostingBusiness Email on Your Own Domain: Why hello@yourcompany Beats a Gmail Address
Why hello@yourcompany beats a free Gmail address, why it's already included with Gotka hosting, and why SPF, DKIM and DMARC now decide if it reaches the inbox.