> blog
Migrating from another WordPress host: what actually breaks
WordPress migrations have a reputation for being painful.
The five things that break (in order of frequency)
1. Email
If your old host bundled email with hosting, the email accounts go away when you switch hosts. Most migrations we do start with: “we need to set up email separately first.” Our email hosting handles this, but you can use Google Workspace, Microsoft 365, or any other dedicated email provider.
How we manage it: set up the new email accounts BEFORE the migration. Test mail flow on the new system. Then update DNS for both web (A record) and email (MX records) at the same time. Zero email downtime.
2. SSL certificate
Your old host might have a custom-installed SSL certificate that doesn’t come with you. New host generates a fresh one. There’s a brief window where the cert is being issued where your site might show security warnings.
How we manage it: stage the site on a temporary URL first (e.g. new.yoursite.com). SSL works there immediately. When DNS cuts over to the new server, the new SSL is already in place via Cloudflare or Let’s Encrypt, usually issued in seconds.
3. Custom server configurations
If your previous developer added custom .htaccess rules, custom PHP settings, or server-level cron jobs, these don’t come with the WordPress files. They’re server-specific.
How we manage it: document everything pre-migration. Audit the .htaccess, the PHP settings (memory limit, max upload, etc.), the cron jobs. Replicate on the new host before cutover. Test.
4. Plugin license keys
Premium plugins often have site-locked licenses. Move the site, the license stops working until reactivated.
How we manage it: document active plugins and their license vendors. Ensure you have admin access to each license. Reactivate within hours of cutover.
5. Caching that’s broken
Old host might use Varnish, NGINX cache, or proprietary caching. New host uses different layers. Cache invalidation can produce stale content briefly.
How we manage it: flush all cache layers immediately post-cutover. Test cache rules on the new host before going live.
What rarely breaks but always scares people
Database integrity. Modern WordPress migrations use proper database export/import (mysqldump, not phpMyAdmin’s “export” button). Tables transfer cleanly.
File permissions. Linux file permissions can drift. We rebuild them on the new host using a known-good script. Usually a non-issue.
WordPress core files. They’re identical across hosts. Just files. No magic.
Theme/plugin code. Same. Files transfer, work the same way on the new host.
The migration process we use
Day 0: kickoff call. Document everything: domain, DNS, current host, theme, plugins, custom code, email, SSL setup.
Days 1-2: stage on temporary URL. Files transferred, database imported, SSL active on temp URL. Site fully functional at e.g. new.yoursite.com.
Day 3: testing. Click through every key page. Submit forms. Test checkout if ecommerce. Check Search Console for errors. Verify plugins activated and licensed.
Day 4: DNS cutover at low-traffic time (midnight Sunday is our default). DNS propagates over 1-4 hours. Cache layers flushed. Email reconfigured to new host.
Day 5+: monitoring. Check uptime, check email delivery, check rankings in Search Console. Fix anything we missed.
Most migrations are 4-5 days end-to-end. Larger ecommerce sites take a week. Total downtime if done properly: zero to a few minutes during the actual cutover.
Migration costs
Standard WP site migration: $500-$1,500 depending on size and complexity. Includes backup, transfer, testing, DNS cutover, post-migration monitoring.
WooCommerce store migration: $1,500-$3,500. More moving parts: Stripe webhooks, shipping zones, tax tables, customer accounts.
Multi-site network migration: $3,000+. Each subsite is a small migration in itself.
Free with new hosting tier signup: for sites moving onto our managed WP hosting at $100/mo+, we usually waive migration fees for sites under 5GB. Talk to us about your specific situation.
Red flags in your current host
You can’t access cPanel / SSH / FTP. Some hosts (Squarespace, Wix, Webflow) don’t let you. Migration is more complex but still possible.
Your developer is gone. No login credentials, no documentation. We can usually recover access, but it takes time.
Your site has been compromised. Migration becomes a clean-up exercise too. We restore from a clean backup or rebuild affected components rather than migrating malware to the new host.
You’re behind a CDN or reverse proxy you don’t control. Cloudflare, KeyCDN, etc. We’ll need to work with the proxy provider during cutover.
When NOT to migrate
Your current site is on its way out anyway. If you’re going to rebuild within 6 months, don’t migrate twice: do the rebuild, host on the new platform from the start.
Your current host is decent and the only complaint is price. $20-30/mo savings doesn’t justify the migration risk. Stay where you are.
You’re mid-launch of a new product. Don’t migrate during high-stakes traffic moments. Wait two weeks until things stabilise.