A hosting migration looks like a copy operation. Take the files, take the database, point the domain, done.
The problem is that a copy is faithful. If something has been quietly broken for a year, the migration carries it across and hides it under a fresh invoice, and now it is broken on a host that has never been blamed for anything.
We learned this preparing a move for two small business sites. The audit found problems that had nothing to do with hosting, and the job stopped being a move and became a rebuild on clean foundations. That was the right outcome, but it should have been found earlier.
Here is what we check now, before quoting a migration.
1. Does outbound mail actually arrive
Not whether the site can send. Whether the message lands in a normal inbox and not in spam.
Send a real order confirmation to an address on a mainstream provider and look at the headers. Broken outbound mail is the single most common fault we find, and it is invisible from inside the site: the admin panel shows the order, so everything looks fine, while the customer received nothing and assumes the business ignored them.
2. Where the mailboxes actually live
Small businesses accumulate email across products and contracts over years. One mailbox came with the domain, another came with a hosting upgrade, a third was bought separately and forgotten.
Write down every address, which product serves it, which contract pays for it, and when that contract renews. This list is often where the largest saving is, and it is almost never in the original scope.
3. What the current setup actually costs
Add up the invoices, including the ones on separate contracts and separate renewal dates. Compare the total against usage, not against the plan name.
The number that matters at renewal is the renewal price, not the introductory price. Comparing an introductory price on the new host against a renewal price on the old one makes any move look good.
4. Whether the orders were fulfilled
On a store, reconcile orders against fulfilment before you touch anything. If confirmations were not being delivered, there may be paid orders nobody acted on. That is a customer service problem with a deadline, and it outranks the migration.
5. Who owns the accounts
Find out whose name is on the domain, the hosting, and the mailboxes, and whose payment method is on file. If the answer is a previous developer, resolve it before the move rather than during it.
New accounts should be created in the client’s legal name and business details, with the client’s own payment method. Access can be delegated. Ownership should not be ambiguous, and a handover pack at go live should mean they could hire somebody else tomorrow without asking permission from anyone.
The rule underneath
An audit that changes the scope is not a failed audit. It is the audit doing its job. The version of this project where nobody looked first is the version where two sites move successfully, mail is still broken, and the invoice says everything went well.