A Low-Risk Website Migration Checklist for Small Teams

Before moving a website, back up its files and database, test the destination and plan how to handle writes during cutover. Keep the old environment available until the new one has been verified.

Why small-team migrations go wrong#

Most migration failures trace back to a handful of familiar causes. DNS changes propagate slowly because resolvers cache old records, so visitors keep arriving at the old server long after you flipped the switch. Databases arrive with mismatched collations or absolute URLs that still point at the old environment, which breaks links, uploads, and login redirects. File permissions are lost or changed in transit, leaving pages that render incompletely. And content gets edited on the old server during the cutover window, so those changes vanish when the old host is switched off. Every step below exists to head off one of those four outcomes.

Two days before: lower your DNS TTL#

Every DNS record carries a time to live value that tells resolvers how long they may cache it. If your records currently carry a long TTL, resolvers around the internet will keep serving the old address for hours after you change it, which is precisely what you do not want during a cutover. Lower the TTL on the records you plan to change, to something in the region of 300 seconds, roughly 24 to 48 hours before the move.

That window matters because you need the old, longer TTL to expire from caches first. The caching behaviour is defined in the DNS specifications themselves, notably RFC 1035, which is why this step is standard practice rather than superstition.

Take complete, consistent backups#

Before anything moves, take a full snapshot of two things: the filesystem and the database. The filesystem holds your code, themes, uploaded media, and configuration. The database holds your content, user accounts, and settings. Both need to be captured close together so they describe the same moment in time. A site restored from a filesystem snapshot taken hours after its database snapshot will have files that reference records which no longer exist.

Store these backups somewhere other than the server being migrated. If you run a content management system, follow its own migration documentation; WordPress, for instance, publishes detailed guidance on moving a site, because these systems have well-documented quirks around URLs and serialized data.

Stage and verify at the destination#

Deploy your files and database to the new host before you change anything public. Once staged, work through a verification pass: confirm the application can reach the database with its new credentials, that rewrite rules behave the same way, and that the PHP or runtime version on the new server matches what your code expects.

Then load the site at its new location without touching DNS. The two common approaches are a temporary staging subdomain or a local hosts file override, which lets your own computer resolve the domain to the new server while everyone else still sees the old one. Test forms, search, image uploads, and login flows specifically, because these depend on server configuration rather than simple file copying.

Freeze content and cut over#

When you are satisfied the new environment works, pick a quiet window and freeze the old one. Put interactive features such as forms, checkout, and comment posting into maintenance mode, so no new content is created on a server you are about to abandon. Take a final incremental database snapshot if anything has changed since your last backup.

Then update the public DNS records, whether A and AAAA records pointing at an address or a CNAME pointing at a hostname. Provision and validate the SSL certificate on the new server before changing public DNS. A certificate error or HTTPS interruption during cutover is not harmless, so treat it as a reason to pause or roll back.

After the switch#

Keep the old host intact for a while rather than cancelling immediately. Watch for lingering traffic on the old server, which tells you whether caches have caught up, and test the site from different networks and devices. Once you are confident, raise the TTL back to a longer value so resolvers are not querying your nameservers every few minutes indefinitely. Export a fresh backup from the new environment before you decommission the old one.

The short version#

• Lower the DNS TTL 24 to 48 hours ahead.
• Back up files and database together, and store them off the old server.
• Stage at the destination and test via a subdomain or a hosts file override.
• Freeze writes, take a final snapshot, validate SSL on the new server, then update DNS.
• Verify, watch propagation, raise the TTL, and keep the old host until you are sure.