Hosting Migration Guide 2026: Move Your Site Without Downtime

Good reasons to migrate

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

1. Cost. Old dedicated server at $400 per month when a $20 Cloudflare Pages plan could serve the same traffic faster.
2. Speed. The current host is slow, the TTFB is 800 ms, and no amount of caching fixes it.
3. Reliability. Three outages in the last quarter, no SLA, unresponsive support.
4. 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.

Provider comparison for 2026

The market stabilized. Six categories cover 95% of 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	Great 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, ecosystem
Kinsta	Premium WordPress	$35–$1,500/mo	Google Cloud-based, great 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	Great DX, pay-as-you-go
Render	Node, Python, static	$7/mo+	Herokulike, 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	Infinite flexibility, steep learning curve
Google Cloud	Data-heavy, ML	Usage	Best-in-class BigQuery
Azure	Microsoft shops	Usage	Tight Office/AD integration
DigitalOcean	SMB, devs	$6/mo+	Simplest of the big three IaaS
Hetzner	Budget, EU	€4/mo+	Unbeatable price-performance in Europe

Specialized

• 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 best 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.

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
• Update any hardcoded 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
• Do 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 "migration went wrong" stories.

1. Forgetting email DNS records

You move your A record and also your MX record points 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 86400 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 3600 a week after.

3. Hardcoded 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 real migrations I ran for clients:

• Brochure site on dedicated server → Cloudflare Pages. Cost before: $400/month. Cost after: $0. TTFB improved by 70%. Migration time: 3 hours.
• WooCommerce on shared hosting → WP Engine. Cost before: $30/month + $800 in downtime losses the prior year. Cost after: $100/month, zero downtime in the following year. Migration time: 8 hours.
• Next.js marketing site from Heroku → Vercel. Cost before: $150/month. Cost after: $20/month. Deploy time went from 6 minutes to 90 seconds. Migration time: 2 hours.

The ROI math is usually fast. A $20 Vercel plan that saves one outage per year pays for itself roughly twelve times over.

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 optimization project I migrated from a slow managed host to a tuned cloud setup with zero customer-facing downtime during peak traffic hours. 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). Related reading: SaaS maintenance checklist and website maintenance costs.

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.

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.

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.