A migration is invisible when the new site is fully built and tested before anything is pointed at it, when DNS time to live is lowered in advance, and when email is planned separately from the website. The two failures that account for most migration problems are mail that stops arriving and a switch made before the destination was verified, and both are avoidable with sequencing rather than skill.
Why migrations go wrong
Almost never because copying files is difficult. They go wrong because a migration touches several independent systems at once, and the person doing it treats it as one job.
The website, the database, the email, the DNS records, the certificate, and anything scheduled to run on the server are separate concerns with separate failure modes. Move them together in a single evening without sequencing and at least one will misbehave, usually the one nobody was watching.
What to establish before starting
Who controls the domain
Not who built the site, but who holds the registrar account and can change the records. If that is not you, resolve it first. It is the most common reason migrations stall midway, and it is far easier to sort out before a move than during one.
Where email currently lives
The single most important question and the one most often skipped. Mail may run on the same server as the site, on a separate provider, or through a relay. Moving the site without knowing this is how businesses lose a day of mail with no copy of it anywhere.
A complete inventory of DNS records
Not just the main record. Mail records, verification records for various services, subdomains for anything separate, and text records supporting mail authentication. Export the whole zone and keep it, because these are what get quietly dropped.
What runs on a schedule
Scheduled tasks, form handlers, anything integrating with another system. These do not announce themselves in a file copy and they fail silently after a move.
The sequence
- Build and test at the destination first. The site should be complete and working on the new server, reachable privately, before anything public changes. Nothing should be pointed at a destination that has not been verified.
- Lower the DNS time to live in advance. Records carry a value telling networks how long to cache them. Reducing it a day or two ahead means the eventual switch propagates in minutes rather than hours. Skipping this is why some migrations have a long, messy tail where some visitors see the old site and some see the new one.
- Test properly at the destination. Every page, every form with a real submission confirmed as received, the certificate, redirects, and the site on a phone as well as a desktop.
- Take a final copy of the source. Files and database, immediately before the switch, so anything changed during the build is captured.
- Handle mail deliberately. Either keep it where it is and leave those records untouched, or move it as a planned step with mailboxes copied and verified. Never as an afterthought inside a website move.
- Switch, then watch. Change the records and monitor: pages loading, forms delivering, certificate valid, mail flowing, and error logs at the new server.
- Leave the old account running. For at least a fortnight. Cancelling immediately removes your fallback at exactly the point you are most likely to discover something missing.
The two things that break most often
Email. Mail records were changed along with the website records because they were all in the same place. Mail now routes to a server with no mailboxes on it, and messages sent during that window are gone rather than delayed. There is no way to retrieve them and the sender is not told.
Form delivery. The site moves, the form still submits, the confirmation still appears, and nothing arrives. The new server's mail configuration differs, or the sending address is not authorised there. Because it fails silently, businesses can go weeks before noticing, which is why a real submission test belongs in the checklist rather than a visual check that the form loads.
What about search rankings
A move to a different server at the same domain has minimal effect when it is done cleanly. The address does not change, the content does not change, and there is nothing to reindex.
Where rankings do suffer, the cause is usually something introduced during the move rather than the move itself: a stray file blocking crawlers that was fine on a staging server, a certificate not configured on the new host, missing redirects, or a site that is now materially slower. Those are checkable, and checking them the day after a switch takes a few minutes.
A move that also changes addresses is a different exercise, and the redirect mapping matters far more than the hosting. That case is covered in redesigns that hurt SEO.
When to do it
Early in the week and early in the day, so that if something needs attention there is a working day in which to attend to it. Friday evening migrations are traditional and the tradition is a bad one, since a problem discovered at 6pm on a Friday sits unresolved through the weekend.
Avoid your busy season entirely. The right window is a quiet stretch when a small disruption costs little, which for most seasonal businesses is a specific and fairly obvious part of the year.
Frequently asked questions
How long does a website migration take?
The technical work is often a few hours for a straightforward site. The full process including lowering DNS values in advance, testing, switching, and monitoring usually spans a few days, most of which is waiting and verification rather than work.
Will my site go down during a migration?
It should not. Building and testing fully at the destination before changing anything, and lowering DNS time to live in advance, means visitors move from a working site to a working site.
What is TTL and why does it matter for migration?
Time to live tells networks how long to cache a DNS record. Lowering it a day or two before a move means the change propagates in minutes rather than hours, which removes the long tail where some visitors still reach the old server.
Does changing hosts affect SEO?
Not materially when done cleanly at the same domain. Problems that do appear usually come from something introduced during the move, such as a file blocking crawlers, a certificate misconfiguration, missing redirects, or a slower server.
What happens to my email during a migration?
It depends entirely on where mail currently runs, which is why that is the first thing to establish. Changing mail records alongside website records without moving mailboxes first is how businesses lose messages permanently.
Should I cancel my old hosting right away?
No. Keep it running for at least two weeks. It is your fallback, and the first fortnight after a move is when you are most likely to discover something that was not carried across.
West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.
Thinking about moving hosts?
We migrate sites onto our own servers as a managed process, test every form before the switch, and keep the old account running until you are certain.
Start a Conversation