We Migrated 200 Sites Last Year. Here is What Actually Broke.

Migration articles usually read like a checklist: back up, change DNS, update nameservers, done. In practice, migrations fail in ways checklists don't predict. We've moved hundreds of sites off GoDaddy, Wix, Squarespace, HostGator, and a dozen smaller hosts over the past few years. Below is what we actually see — the things that consistently go sideways, and what we do about them.

No client names appear below. The details are composites drawn from real engagements. Where I describe a specific failure mode, it's happened more than once.

The numbers, first

Across roughly the last 200 site migrations we've handled, here is the rough distribution of what we found on the other side:

• About 60% were straightforward: clean cPanel or managed-host backups, valid DNS, no surprises. Migrations completed in under four hours.
• About 25% had at least one issue that extended the migration by a day or more: oversized databases, custom cron jobs, broken SSL chains, third-party integrations that depended on the old server's IP address.
• About 12% had a serious problem that risked data loss or extended downtime: missing backups, mismatched database versions, hacked sites with backdoors we had to clean before the move.
• About 3% failed outright the first time and required a second migration. Every one of these was a small-business site that turned out to be running on infrastructure the owner didn't fully understand — a reseller account, a friend's server, or a hosting plan that had been quietly downgraded.

The headline: if you're paying for hosting, there's roughly a 1-in-8 chance your site has a real problem hiding in it that you don't know about until someone tries to move it.

The five things that actually break

1. WordPress sites over 5GB

The most common surprise on WordPress migrations is size. The site you're moving looks normal — 20 pages, a contact form, a blog — but the uploads directory is 4GB of high-resolution images that someone uploaded at original camera resolution. The database is 200MB because of accumulated post revisions, transients, and a WooCommerce install that was abandoned but never cleaned up.

The migration itself isn't the problem. The problem is the new host's plan you picked. A site that needs 8GB doesn't fit on the $4/month plan with 5GB of storage. We end up either recommending a plan upgrade, or doing the work to compress and clean before the move. Either way, it's a conversation the buyer wasn't expecting.

What this looks like in practice: we tell the customer mid-migration that they need to either upgrade their plan with us or spend two hours cleaning up their media library. They almost always pick the upgrade. The migration takes a day instead of an hour.

2. Email continuity

This is the issue that causes the most panic. A business has been running on info@theircompany.com through their old host for years. They switch web hosting but forget that their email is tied to the same DNS. As soon as DNS changes, their email stops arriving in some clients' inboxes for 24–48 hours while the change propagates. By the time they realize it, they've already missed a few customer emails.

We always ask, before a migration, whether the customer wants us to move their email too or just the website. About half the time, the answer is "I didn't realize those were separate things." For those customers, we lower the DNS TTL a few days before the migration so propagation is fast, and we keep the old email service running for a transition period even if the website is fully migrated.

The bigger version of this problem: a customer migrates their website to a new host but their email stays at the old host, and the old host suspends the account for non-payment six months later. Email goes dark. The customer had no idea the two were tied together. We've added "check that you actually own your email hosting" to our pre-migration checklist as a result.

3. SSL certificate re-issuance

Let's Encrypt certificates are free and automatic on most modern hosts. But they're issued against specific server environments. When you move a site, the SSL certificate that's currently working on the old server doesn't carry over. The new host needs to issue a new one.

If the new host does this automatically — which we do — the visitor sees no interruption. If the new host doesn't, or if the customer's old host used a paid certificate that was tied to a specific account, the visitor sees a security warning for up to 24 hours while DNS catches up and a new cert is issued.

The nasty version: a customer migrates their site but their old host had issued a multi-year paid SSL certificate through a third party. That certificate is now invalid on the new server. They need to either re-purchase or set up Let's Encrypt on the new host. Either way, it's an unexpected cost in the first week.

4. Cron jobs and scheduled tasks

This is the issue that breaks WordPress sites silently. WordPress itself uses a fake cron system that runs whenever a visitor hits the site. Plugins often schedule their own cron jobs — backup plugins, social media schedulers, email auto-responders, anything that needs to happen at a specific time. These jobs are stored in the WordPress database.

When we migrate the database, the cron jobs come along with it. They should keep working. But if the new server's PHP version is different from the old one — and it almost always is, because old servers tend to be running older PHP — some scheduled tasks fail silently. The customer doesn't notice for two weeks until an automated report stops arriving.

We've added "verify scheduled tasks are firing after migration" to our standard process. Most migrations don't have this problem. The ones that do are the ones where the customer is using a plugin that hasn't been updated in two years.

5. The hacked site

This is the worst one. About 4% of the sites we migrate show signs of compromise before we even start — usually a backdoor uploaded through an outdated plugin, sometimes malware injected into the theme files. The customer has no idea. The site looks fine.

If we migrate the hacked site as-is, we move the backdoor to the new host. Now the customer is paying us to host a site that's actively being used for spam, phishing, or cryptomining. Worse, the old host might not have noticed either, which is why the customer didn't get a warning.

Our policy: we scan every site before migration. If we find something, we tell the customer before the move and clean it as part of the migration. The cleanup adds two to six hours and sometimes requires a theme or plugin rebuild. We've never had a customer refuse the cleanup once they understand what's happening.

What surprises customers most

The pattern across these migrations is that the customer almost always underestimates the time it takes to do the things they don't know about. They budget for "switch hosts" and don't budget for "fix the WordPress plugin that hasn't been updated in three years" or "figure out where the cron job went."

A clean migration on a simple site takes us under two hours. The same customer asking "can you also move my email" can turn it into a six-hour job. A customer who built their site on Squarespace five years ago and never touched the code can turn it into a two-day migration because there's no clean export path.

The honest advice: budget more time than you think, and budget for at least one thing you didn't know about. If the migration goes smoothly, you've saved yourself stress. If it doesn't, you've planned for it.

What we do differently

We could write a whole separate post on our specific migration process, but the short version is:

• Pre-migration scan for malware, oversized databases, and broken backups
• Pre-migration conversation about email, subdomains, and any third-party integrations
• DNS TTL lowered 48 hours before the move so propagation is fast
• Migration happens during the customer's low-traffic window, usually overnight
• Old site stays live for 7–14 days after the move as a fallback
• Post-migration verification: SSL, email, scheduled tasks, contact forms, analytics

Most of the time, this all happens invisibly. The customer notices that their site is now hosted by us and the bill is different. That's the goal.

When a migration isn't worth it

There are sites we recommend customers don't migrate. If you're on a deeply discounted legacy plan that you've been grandfathered into for years, and the renewal price would actually be higher if you left, the math may not work. We've had customers save money by staying put.

If your current host is fine, your site works, and the only reason you're thinking about migrating is because of a recent billing change — that's a good reason to ask questions first, not to switch.

But if your host is unreliable, your support is bad, or you're paying significantly more than the going rate — yes, migrate. Just don't expect it to be a 15-minute task.

If you're thinking about migrating and want to know what your migration would actually look like, look at our plans or call us at (330) 587-9583. We'll walk through your current setup and tell you honestly whether the move makes sense.