What actually breaks during a hosting migration

Parity, not poetry

We have checked a site on a replacement host and found configuration and content-parity gaps that had to be worked through before anyone was allowed to call the move done. We have prepared a newly provisioned server that was missing required components and had a separate content-publishing problem. In both cases the honest sentence was “the server is not ready,” not “we migrated.”

If a note does not confirm the public cutover, we do not claim the public cutover. That sounds pedantic until you have watched a client announce a move while DNS still pointed at the old box.

Mail is the silent failure

Forms and order notifications keep using the old SMTP user, or SPF still authorizes a host you just vacated. The homepage looks fine. The next lead never arrives. That is why a destination form send is on the pre-flight, not on the “week two” list.

Certificate and DNS problems show up at the flip: the panel is green, the browser is not. Install HTTPS on the destination and walk it as a visitor before you lower anyone’s TTL story into a Friday afternoon.

The new PHP version

Plugins that ran on the old runtime fatal on the new one. This is the same class of failure as an emergency after a host upgrade, except you chose the moment. Review compatibility on staging. Do not discover it after the nameservers move.

Who owns each record

Migrations fail in the paperwork as often as they fail in rsync. Someone has to hold the registrar. Someone has to hold the mailbox that receives form mail. Someone has to hold both hosts. If any of those people are on holiday, you do not have a cutover date — you have a hope. We will say that in the scope rather than discover it at 21:00.

Scheduled jobs deserve their own line. Cron that still hits the old hostname, a wp-cron that only ran because a visitor loaded the old site, a Magento indexer that nobody started on the destination, a Windows scheduled task that lived only on the old box — these do not copy themselves. Inventory them. Test them. Then cut over.

Stores are a different animal

A brochure site can survive a messy afternoon. A store cannot. Orders placed during a flip, inventory sync, payment callbacks, and tax calculations all assume a single origin. If you take money, freeze or queue orders, keep the source read-only for a short overlap, and prove a test purchase on the destination before you announce anything. Location-dependent tax is a real test, not a single happy-path postal code. We have configured that class of checkout work; we still prove it with more than one address.

If the destination PHP version is newer, treat every paid extension as guilty until staging says otherwise. A storefront that “only moved hosts” is still a runtime change.

Pre-flight

Inventory the source: PHP version, database size, cron, media offload, object cache, and every DNS record that is not obvious. Confirm you hold credentials for the CMS, both hosts, the registrar, and the mailbox that receives form mail. Build the destination first. Copy to staging. Check parity. Send mail. Install the cert. Review plugins. Lower TTLs the day before. After the flip, do not delete the source until forms, checkout, admin, SSL, and Search Console pass.

The printable list is on the migration page: hosting migration pre-flight. Related reading when DNS is the only change you think you made: check your email anyway.

A walk-through we will not dress up

Picture a Sitefinity or WordPress site moving to a server that was ordered last week. The panel says the account is ready. The first login shows a missing library the CMS assumes is there. A publishing job fails because the destination user cannot write to a folder the vendor installer created as root. Content copied overnight is short a batch of media and one language version. Mail still leaves through the old SMTP user. None of this is exotic. All of it is why “the server is ready” is a claim you verify.

The notes we keep from that class of work are deliberately dull: required components, a publishing problem, a later confirmation that the application can run. If the public cutover is not in the notes, it is not in the story we tell on this site. That is the standard we apply to anonymized examples on the migration service page as well.

Do the same when you are the one writing the internal ticket. “Copied files” is not a status. “Parity checked on ten URLs, form sent, cert valid, cron listed” is a status.

Search Console is part of the cutover

A move that ignores Search Console is a move you will redo. Verify the destination, keep the URL structure unless you have a written redirect map, and fetch a sample of important URLs after DNS settles. If you changed hosts and also changed permalinks, you did two projects. Say that out loud before the flip.

Sitemaps that still list the old host, canonical tags that still print the old hostname, and hardcoded links in post content are ordinary leftovers. They are also how “we migrated” becomes a six-week ranking dip you did not budget. We check a sample. We do not claim we crawled every URL unless that crawl is in the scope.

If the site is a store, the same pass includes payment callbacks and the origin the gateway already knows. Changing hosts without telling the gateway is a silent checkout failure. Changing hosts without telling the mailbox that receives order mail is the other silent failure. Both belong on the same checklist as the A record.

When you are ready to have someone else own that list, send the source host, the destination, traffic level, and whether you take payments. We will say whether the honest first step is a staging copy or an emergency repair of a move that already happened. Related: the Wix to WordPress checklist if the source is not already WordPress.

How Metro Vancouver IT runs a move

We migrate onto hosts we operate and onto hosts we do not sell. The checklist does not change. Staging first. Form send first. Certificate on the destination first. A written cutover window. Canadian billing. Remote delivery from Burnaby, with the same on-site limits we publish on every city hub.

If you arrived here because a cheap host is pushing a PHP version your plugins cannot follow, read the emergency article on why sites go down and decide whether you are buying a repair, a move, or both. Trying to do both on the same evening is how you get neither.

For a scoped move, start on WordPress migration services or the contact form with the source host, the destination, and whether you take payments. If you take payments, say so in the first sentence.