Hosting Migration Guide 2026: Zero-Downtime Moves

TL;DR

A solid hosting migration guide for 2026 starts with one rule: most migrations fail not because the new host is wrong, but because DNS, email, and SSL are not planned as one change.
Lower TTL a week before the move. Build and verify on the new host before flipping DNS. Keep the old host running for 7 days.
Pick on fit: Vercel/Netlify for Next.js, WP Engine/Kinsta for serious WordPress, Hostinger/SiteGround for cost, Cloudflare Pages for static.

Hosting migrations have a bad reputation. Most of that reputation is earned, because the people running them under-plan and then have a very bad Saturday.

This guide walks through how I do it without drama: why you would move in the first place, which providers make sense in 2026, the exact DNS cutover sequence, and the five mistakes that cause most of the "my site went down for 6 hours" stories.

Good reasons to migrate

I have moved sites for clients for four reasons, in roughly this order of frequency:

Cost. Old dedicated server at $400 per month when a $20 Cloudflare Pages plan could serve the same traffic faster.
Speed. The current host is slow, the TTFB is 800 ms, and no amount of caching fixes it.
Reliability. Three outages in the last quarter, no SLA, unresponsive support.
Developer workflow. Current host does not support staging, git deploys, or automated rollbacks. Your team deserves better.

Bad reasons to migrate:

"This new host is trendy on Twitter."
"A salesperson emailed me."
"Some random speed-test tool ranked Provider X highest."

Migration takes 4–20 hours of real engineering time. Make sure the delta is worth it before you book a Saturday for it.

Provider comparison for 2026

The market stabilised. Six categories cover most use cases.

Static and JAMstack sites

Provider	Best for	Pricing	Notable
Vercel	Next.js, React, PPR	$0 hobby, $20/user Pro, $750+ Team	First-class Next.js support, Vercel Functions
Netlify	Jamstack, Eleventy, Astro	$0 Starter, $19/user Pro	Strong build pipeline, atomic deploys
Cloudflare Pages	Static + Workers	$0 free, $5/mo Workers Bundled	Unmatched free tier, tight Workers integration
GitHub Pages	Docs, open source	Free	Simple, limited

Traditional shared hosting

Provider	Best for	Pricing	Notable
Hostinger	Small business, WordPress	$3–$15/mo	Cheapest credible option, cPanel
SiteGround	WordPress, WooCommerce	$4–$40/mo	Strong support, built-in caching
Bluehost	Entry WordPress	$3–$15/mo	Owned by Newfold, decent but not great
A2 Hosting	Performance shared	$3–$30/mo	Turbo plans genuinely fast

Managed WordPress

Provider	Best for	Pricing	Notable
WP Engine	Serious WordPress	$30–$300+/mo	Reliable, fast, large add-on catalogue
Kinsta	Premium WordPress	$35–$1,500/mo	Google Cloud-based, good dashboards
Flywheel	Design agencies	$15–$290/mo	WP Engine-owned, good for freelancers
Pressable	Mid-market WP	$25–$400/mo	Automattic-owned

Application hosting

Provider	Best for	Pricing	Notable
Railway	Rails, Django, Laravel	$5/mo starter + usage	Strong DX, pay-as-you-go
Render	Node, Python, static	$7/mo+	Heroku-like, better pricing
Fly.io	Global edge apps	Usage-based	True global deploy
Heroku	Nostalgia	$7/mo+ (eco)	Still works, pricier than alternatives

Cloud IaaS

Provider	Best for	Pricing	Notable
AWS	Enterprise, scale	Usage	Wide service catalogue, steep learning curve
Google Cloud	Data-heavy, ML	Usage	Strong BigQuery story
Azure	Microsoft shops	Usage	Tight Office/AD integration
DigitalOcean	SMB, devs	$6/mo+	Simplest of the big three IaaS
Hetzner	Budget, EU	€4/mo+	Strong price-to-performance in Europe

Specialised

Shopify for ecommerce where you want zero hosting management
Supabase / Neon / PlanetScale for the database layer if you decouple
Cloudflare R2 / AWS S3 for object storage separate from the app host

Which provider wins, by scenario

Short decision tree:

Next.js app, any size → Vercel. Others work; Vercel is the lowest-friction default.
Astro or static site → Cloudflare Pages if you want the best free tier, Netlify if you want the smoothest DX.
WordPress, business-critical → WP Engine or Kinsta. The $30/month savings versus Hostinger is not worth the reliability gap at this tier.
WordPress, small budget → Hostinger at $5/month with Cloudflare in front for caching and security.
Laravel or Django app → Railway for speed of setup, Fly.io for global edge, Hetzner for cost.
Enterprise compliance (HIPAA, FedRAMP) → AWS or Azure with dedicated solutions. Not a migration to do casually. Read the FedRAMP marketplace before scoping.

For the fuller view of what you pay to keep a site running after launch, see the website maintenance costs guide.

The zero-downtime migration sequence

This is the order I run every migration. Skip no step.

Week -1: Prep

Inventory current host: DNS records, email, SSL, cron jobs, env variables
Lower DNS TTL to 300 seconds (5 minutes). Do this a week ahead so the lower TTL has time to propagate.
Document every integration that points at the current domain or IP (webhooks, API keys, email services)
Take a full backup: files, database, any attached storage
Set up a staging subdomain on the new host (e.g., new.example.com)

Day -2: Build and verify

Deploy the full site to the new host at the staging subdomain
Verify SSL is live on the staging subdomain
Test everything:
- All pages load
- Forms submit and email arrives
- Database queries work
- Background jobs or crons run
- Third-party webhooks authenticate correctly
- Login and checkout flows work end-to-end
Run a performance comparison: TTFB, LCP, CLS on new vs old (the web.dev Core Web Vitals reference is the cleanest source for the thresholds).
Update any hard-coded URLs from old host to domain-agnostic

Day -1: Final sync

Take a fresh database dump from the old host
Import into the new host
If there is customer-generated content (orders, comments, uploads) on the live site, plan for a final delta sync at cutover time

Day 0: Cutover

Optional: put the old site into read-only or maintenance mode if you cannot risk new writes during the sync window
Run the final data delta sync
Update DNS A or CNAME record to the new host
Verify propagation with dig from a few resolvers
Watch uptime and error dashboards for 4 hours
Keep old host running, fully operational, for 7 days

Day +1 through +7: Monitor

Compare error rates and performance new vs old baseline
Check Google Search Console for crawl errors
Verify transactional emails still deliver (SPF, DKIM, DMARC updated)
Watch customer support tickets for anything stack-related

Day +7: Decommission

Only after a full week of green new host, cancel the old one
Export final backups from the old host before termination

The five mistakes that break migrations

These cause most of the "migration went wrong" stories I get sent.

1. Forgetting email DNS records

You move your A record and your MX record happens to point to the old host for email. Suddenly your email stops. Or you miss SPF, DKIM, DMARC entries and email starts bouncing.

Fix: list every DNS record on the old host and confirm each one is migrated intentionally. Email often lives on a different provider than web (Google Workspace, Microsoft 365) and should stay there.

2. Not lowering TTL in advance

You flip the DNS on migration day but the TTL is 86,400 seconds (24 hours). Half your users hit the new host, half keep hitting the old one. If the two are in different states, you corrupt data.

Fix: lower TTL to 300 seconds a full week before migration. Raise it back to 3,600 a week after.

3. Hard-coded domain references in the database

Common in WordPress. Posts have images stored as https://oldhost.com/uploads/.... You move, the images load from the old host, everything works — until you turn off the old host and every image breaks.

Fix: run a search-replace on the database before cutover. WP-CLI: wp search-replace 'oldhost.com' 'newhost.com' --dry-run first.

4. SSL mismatch at the CDN layer

Cloudflare is set to "Full (strict)" but the new origin has only a Let's Encrypt staging cert, or no cert at all. Users see SSL errors.

Fix: SSL on the new origin live and valid before the DNS flip. See my SSL setup guide for the common cases.

5. Webhooks and callbacks pointing at the old host

Stripe webhooks, GitHub webhooks, Zapier triggers, Slack callbacks, OAuth redirect URIs. Each of these has a URL configured in a dashboard somewhere. If it points at the old host, it keeps working until the old host goes dark, then silently fails.

Fix: list every webhook and every callback URL. Update them the morning of the migration. Test one of each after cutover.

WordPress-specific migration

WordPress is the most common migration I do. The extra steps:

Use a plugin like All-in-One WP Migration, Duplicator, or WP Migrate DB Pro. Not manual zip-and-upload.
Confirm the new host matches or exceeds PHP, MySQL, and WordPress versions of the source.
Rebuild caches after migration (WP Rocket, W3 Total Cache).
Run wp search-replace for domain changes (or enable it in the migration plugin).
Regenerate image sizes if moving themes or image plugins.
Disable plugins during initial load, re-enable one at a time to catch plugin conflicts.

If you maintain WordPress sites at any scale, my WordPress maintenance cost guide covers what to expect from each host tier.

Cost savings examples

Three patterns I see again and again on client migrations (numbers are typical of the projects I have run, not promises):

Brochure site on dedicated server → Cloudflare Pages. Cost before: roughly $400/month. Cost after: $0. TTFB improvements of 60–70% are common when traffic is global. Migration time: a few hours.
WooCommerce on shared hosting → WP Engine. Cost before: $30/month plus a year of avoidable downtime losses. Cost after: $100/month, far fewer incidents the following year. Migration time: under a day.
Next.js marketing site from Heroku → Vercel. Cost before: ~$150/month. Cost after: ~$20/month. Deploy time drops from minutes to under two minutes. Migration time: a couple of hours.

The ROI math is usually quick. A $20 Vercel plan that prevents one outage per year pays for itself many times over.

[INSERT REAL ANECDOTE: a specific client migration where you can share host names, before/after numbers, and the date]

When to call a professional

You can run a simple brochure-site migration yourself. Cases where I would not:

You take payments and downtime costs more than $500 per hour
Your email runs on the same server as your website
You have heavy third-party integrations (HubSpot, Salesforce, ERPs)
The old host is going dark in fewer than 7 days
You have never done DNS work before

For these, an engineer doing this weekly for years can save you a very painful Saturday. I have handled migrations as part of custom web application engagements and one-off fractional CTO calls.

The approach scales. On the Cuez API optimisation project I migrated from a slow managed host to a tuned cloud setup with zero customer-facing downtime during peak traffic hours, and the API went from 3 seconds to 300ms. For more on how infrastructure affects speed, see the Imohub real estate portal case study (120k+ properties, sub-0.5s query response, 70% infrastructure cost reduction). The same care applied at a different scale on bolttech, the $1B+ unicorn where I led the payment service across 40+ providers with 99.9% uptime and zero post-launch critical bugs. Related reading: SaaS maintenance checklist and website maintenance costs.

Reflecting on what matters in a migration

After 16 years and 250+ projects, the migrations I am proudest of are the ones nobody noticed. No ticket spike, no Slack screaming, no apology email. The customers kept buying, the team kept shipping, and the bill went down.

The instinct most teams have is to focus on the new host. Pick the perfect provider, tune the perfect config, write the perfect Dockerfile. That is fine, but it is the smaller half of the work. The bigger half is the order of operations: TTL first, build second, DNS third, decommission last. Get that order wrong and even the perfect host produces a bad weekend.

If your team is migrating, write the order down. Read it out loud. Then run it slowly.

FAQ

How long does a typical migration take?

Simple static site: 2–4 hours. WordPress small business: 4–8 hours. Ecommerce or SaaS: 1–3 days with planning.

Will SEO suffer from a hosting migration?

If the URLs stay identical and you keep old host live during propagation, impact is usually nil. Google crawls, sees the same content, updates its IP cache. Submit a fresh sitemap after cutover. Google's own site moves guidance is worth a read if URLs are changing.

Do I need to keep the old host running?

Yes, for at least 7 days. DNS propagation is uneven, and some users' resolvers cache TTLs aggressively. Keep the old host operational during that window.

Can I migrate an active ecommerce site without downtime?

With planning, yes. The trick is a final short delta-sync window, often 5–15 minutes, where the store is in read-only or maintenance mode while final orders copy over. Most teams accept this.

What about email during migration?

Move email before, during, or after the website, but never at the same time. Confirm MX records point where you want them before the DNS flip.

How do I roll back if the new host misbehaves?

Because TTL is low and the old host is still running, a rollback is just changing the DNS record back. Practise this once on a staging domain so the muscle memory is there before launch day.

Closing

A hosting migration done well is a non-event. Customers never notice. Your team gets back faster deploys, better performance, or a lower bill. The difference between that and a disaster is planning and order of operations.

If you want a second pair of eyes on a migration plan or someone to run the cutover with you, get a quote in 60s. Most client migrations are done in a single evening once the prep is right.