Website Migration Checklist for Singapore SMEs: Switch Hosts With Minimal Downtime

Moving a website to a new host is rarely hard in itself. The risk sits in the details around it: DNS records, email, forms and a cutover made at the wrong moment. This checklist is for Singapore founders, marketing leads and IT owners who are switching hosts and want the live site to keep working while they do it.

Executive summary

What a hosting migration includes, and what it does not

Before touching anything, write down what is moving. A typical SME site has five parts: website files, a database, email, DNS records and an SSL certificate. A sixth item, the domain registration, often gets mixed up with them.

On Z.com, domain registration transfer is not part of the website transition process. You can move the hosting while the domain stays where it is, and transfer the domain separately at any time. If you plan to do both, the domain transfer page explains that process.

Z.com's Website Transfer page, which presents free migration, sets out self-service steps: you back up, upload and test the site yourself. It does not describe a staff-led migration. If the site is business-critical, line up a developer or agency to be available on cutover day.

One week before: preparation checklist

• Lower your DNS TTL. TTL is the time a DNS record may be cached before the source is consulted again, as defined in RFC 1035. Google's guidance for hosting moves is to lower it to a conservative value, for example a few hours, at least a week ahead so changes spread faster.
• Export every DNS record. Copy the full list of A, CNAME, MX and TXT records from your current DNS provider into a document. Give extra attention to the MX, SPF, DKIM and DMARC records, because email fails if they go missing.
• Back up everything. That means website files, the database exported as a .sql file, and email. Backups can hold personal data, so store them securely and delete spare copies afterwards.
• List your integrations. Note payment gateways, contact forms, CRM or newsletter connections, analytics tags, and any service that only accepts your old server's IP address.
• Check plan fit. Z.com's staging subdomain method is available on the Personal and Business plans, not on Starter or free hosting. At the time of writing the hosting comparison page lists them at S$6.38 and S$12.98 a month, and does not say whether GST is included, so confirm that before you order.
• Choose a quiet window. A weeknight usually works. Avoid campaign launches, sale periods and invoicing runs.
• Keep Search Console verification working. If you verify with an HTML file or meta tag, make sure it is also present on the new copy of the site.

Build and test a staging copy first

Adding your domain to a Z.com account does not affect your live site. It keeps running at the current host until you change DNS. That gives you time to build and test the new copy properly.

The usual order is to upload the website files by FTP, import the database, then update the site's configuration file. For WordPress, if the database name, user or password differ on the new host, update wp-config.php to match, and check your permalinks after go-live, as the WordPress migration guide advises.

To view the copy before DNS changes, Z.com's method creates a test subdomain. At your old DNS provider, add an A record for the subdomain that points to the Z.com server IP, which you can find under Server Statistics in cPanel, and allow 1 to 24 hours for it to propagate. Then create the same subdomain in Z.com cPanel and upload the files and database there. A hosts file entry on your own computer is another way to preview the site under its real domain. Remove it after testing.

If the test copy is publicly reachable, Google advises using a temporary hostname with a noindex tag, and checking that no firewall blocks Googlebot. Remove any noindex tag or robots.txt block before launch.

Test these before you go live:

• The home page and your highest-traffic landing pages, including images and media.
• Every form, with a real submission that reaches the right inbox.
• Admin and customer logins.
• Checkout and payment flows, in test mode where your gateway offers it.
• HTTPS, with no mixed-content warnings. Z.com's plans list a free SSL certificate. If you need organisation-level validation, compare the GlobalSign SSL options.
• Redirects and error pages, so old links still land somewhere useful.

To go from staging to production, place the site files in the production domain's document root, not the test subdomain's folder. For WordPress, set the home and siteurl values to the production hostname and replace test-URL references in content and settings. Once DNS points to the new server, confirm HTTPS on the production hostname.

Choose your DNS cutover method

The cutover is the moment visitors start reaching the new server. Z.com's transfer page describes two ways to do it.

Z.com notes that A record changes may show in about an hour, but full propagation can take up to 48 hours, and Z.com cannot speed that up. Lowering the TTL beforehand is the one lever you control.

Cutover day

1. Stop writes and orders on the old site. Pause content edits and put the old site in maintenance mode. For an online shop, stop accepting orders there, and do not take orders on both old and new servers during the move.
2. Take a final backup. Once writes have stopped, back up the files and export the database again.
3. Load and verify the new site. Apply the latest database and changed files to the new server, then test logins, forms and checkout before touching DNS.
4. Change DNS. Use the nameserver or A record method you chose.
5. Remove test blocks. Take off any staging noindex tag or robots.txt block.
6. Reopen orders on the new site. Resume order intake only on the verified new environment, and keep the old one closed to orders.
7. Check from different networks. Try your office connection, mobile data and a public DNS lookup tool, because visitors may reach either server for a while.
8. Watch both servers. Google recommends monitoring server logs on the old and new hosts and tracking indexing in Search Console.

Some visitors will still reach the old host during propagation, so leave it running with content frozen and orders closed.

This checklist assumes your domain and URLs stay the same. If the URLs change too, follow Google's guidance on site moves with URL changes. WordPress also warns that a plain find-and-replace on the database can break serialised data, so use a tool such as WP-CLI search-replace instead.

After the move: when to close the old host

Google says its crawl rate may dip after launch and then recover.

Keep the old account until traffic to it reaches zero, which is Google's own test for shutting down old infrastructure. Before cancelling the old contract, also confirm that no email or authoritative DNS still depends on it. In the meantime:

• Confirm email still sends and receives. Our guide to business email on your own domain covers cutover mistakes, and the SPF, DKIM and DMARC setup guide explains the records to recheck.
• Run the small business website security checklist against the new host.
• Take a first backup of the new site and test that you can restore it.
• Check that no MX record, mailbox or nameserver still points to the old host.
• Return your DNS TTL to its normal value.

Common mistakes to avoid

Frequently asked questions