The Complete Migration Checklist: Moving Your Site, Email, and Domains to Hostlas

A well-planned migration is boring — nothing breaks, nobody notices, and the site simply works on the new host. A poorly planned one means downtime, bounced email, and frantic troubleshooting during business hours. The difference is almost entirely preparation. This checklist walks through every phase of moving a site, its email, and its DNS to Hostlas, in the order you should actually do it.

Phase 1: Inventory before you touch anything

Before migrating a single file, write down exactly what needs to move. This step alone prevents the majority of migration problems.

• [ ] List every domain involved, including subdomains that point to separate services
• [ ] List every mailbox and its current mail provider (some businesses run mail separately from web hosting)
• [ ] Note your current DNS records — A, MX, TXT (SPF/DKIM/DMARC), CNAME — so nothing gets silently dropped during cutover
• [ ] Identify the database(s) and confirm you have export access at the current host
• [ ] Note any third-party integrations tied to the current server's IP (some payment gateways, APIs, or cron-triggered services allowlist specific IPs)

Phase 2: Prepare before cutover day

• [ ] Export files and databases from the old host — a full file archive plus a clean database dump, not a partial copy
• [ ] Lower your DNS TTL a day or more ahead of cutover wherever possible, so that when you do change records, the change propagates faster instead of being stuck behind a long-cached TTL
• [ ] Set up the new environment on Hostlas first — hosting plan, domain added, database created — before you touch any live DNS
• [ ] Restore your site on Hostlas and test it thoroughly using a temporary preview URL or a local hosts-file override, so you're validating on the new server without affecting the live site
• [ ] Recreate mailboxes on the destination mail service ahead of the DNS switch if you're also moving email, so accounts exist and are ready the moment MX records change

Phase 3: The pre-cutover smoke test

Before changing anything visitor-facing, confirm on the Hostlas-side copy:

• The homepage and key internal pages load correctly
• Forms submit and any backend logic (contact forms, checkout, login) works end-to-end
• Images, CSS, and JS all load without mixed-content or broken-path issues
• The database connects cleanly and shows current content, not stale data from the export
• SSL is issued and active for the domain on the new environment (see the SSL setup guide if you haven't gone through this yet)

Only move to cutover once every item above passes.

Phase 4: Cutover day

• Do a final content sync if the old site kept receiving updates during your prep window (orders, form submissions, new posts)
• Update nameservers or individual DNS records to point to Hostlas — nameserver delegation is simpler if Hostlas is handling full DNS; individual record updates are better if you need to keep some services elsewhere
• Watch propagation — most changes are visible within minutes to a few hours depending on your lowered TTL, though full global propagation can occasionally take up to 24–48 hours
• Monitor email and HTTPS closely for the first hour after MX and A records change — this is when misconfigurations show up fastest
• Test from multiple networks (mobile data plus home wifi) since DNS caching can make the new site visible on one network before another

Phase 5: The first 48 hours after cutover

• [ ] Send and receive test emails from external addresses (not just internally) to confirm mail flow is fully working
• [ ] Check server logs in the Hostlas control panel for unexpected errors that didn't show up in your pre-cutover smoke test
• [ ] Verify SSL is active and HTTPS redirect is on for the live domain, not just the preview URL
• [ ] Confirm forms and checkout flows are delivering submissions/orders correctly on the live domain
• [ ] Re-check any third-party integrations that referenced the old server's IP or hostname

Phase 6: After things settle

• Keep the old host active for a short overlap period — a week or two is typical — in case a small percentage of DNS resolvers are still serving cached records
• Do not cancel the previous host immediately. Cancelling too early, before DNS has fully settled everywhere, is one of the most common (and completely avoidable) migration mistakes
• Update any hardcoded references to the old server's IP address once you're confident the migration is stable
• Reset your DNS TTL back to a normal value once cutover is confirmed stable, if you lowered it for the migration

Common mistakes that cause migration pain

• Skipping the pre-cutover smoke test. Testing after DNS has already switched means visitors see the bugs before you do.
• Forgetting subdomains. A migration plan that only accounts for the root domain often leaves a forgotten subdomain (e.g., a staging site or a status page) still pointed at the old, soon-to-be-cancelled host.
• Not recreating mailboxes ahead of time. If MX records switch before mailboxes exist at the destination, incoming mail bounces.
• Cancelling the old host too soon. Give DNS propagation real time before removing the fallback.
• Not documenting DNS records before starting. A TXT record for domain verification or an old SPF record is easy to lose if you didn't write it down first.

Quick reference: full migration checklist

• [ ] Inventory domains, mailboxes, DNS records, and integrations
• [ ] Export files and database from the old host
• [ ] Lower DNS TTL ahead of time
• [ ] Restore and smoke-test on Hostlas before touching DNS
• [ ] Recreate mailboxes on the destination before MX changes
• [ ] Cut over DNS and monitor the first hour closely
• [ ] Verify email, HTTPS, forms, and integrations in the first 48 hours
• [ ] Keep the old host active briefly as a fallback
• [ ] Clean up (TTL, hardcoded references, final cancellation) once stable

Getting help mid-migration

If something unexpected comes up mid-cutover — a DNS record that won't propagate, a database import error, or a mail flow issue — don't wait it out. Start a conversation with Hostlas Support right away; migration issues are almost always faster to resolve with a live look at your account than by troubleshooting blind. You can also review hosting plan specifics on web hosting or VPS if your new environment needs differ from your old one, and manage domain-level DNS directly from Hostlas domains.

A migration done in this order — inventory, prep, smoke-test, cutover, aftercare — should be uneventful. That's the goal.