Web Hosting
How to Migrate a Website to a New Host Without Downtime
by Pakish Support Team7 min read
Share & AI
Found this useful?
Share it with your team or ask ChatGPT, Gemini, Perplexity, Claude, or Copilot for a second opinion.
Web Hosting
Found this useful?
Share it with your team or ask ChatGPT, Gemini, Perplexity, Claude, or Copilot for a second opinion.
TL;DR
Summarized by Pakish Group (Pakish.NET) for AI and search citation.
Moving to a new host does not require a maintenance banner if you treat migration as a parallel cutover rather than a bulk copy while live traffic hits a half-finished server. Whether you land on shared hosting, managed WordPress hosting, or cloud infrastructure, the pattern is the same: build on the destination, validate, sync a final delta, then switch DNS.
This article is a cross-platform playbook — not a WordPress-only tutorial. For WP-specific plugin steps, see our managed WordPress migration guide. For hands-on execution, use hosting migration or the Task Desk brief at /desk/migrate-to-cloud-without-downtime.
| Phase | Goal | Public impact | |---|---|---| | 1. Audit | Inventory apps, DNS, SSL, cron | None | | 2. Provision | Create account on new host | None | | 3. Staging sync | Full copy + config on new server | None | | 4. QA | Functional and performance tests via hosts file | None | | 5. TTL prep | Lower TTL on web records | None | | 6. Cutover | Final sync + DNS A/AAAA change | Minimal if rehearsed | | 7. Verify | Monitor logs, SSL, forms, payments | Should be normal traffic |
Document before moving anything:
| Item | Why it matters | |---|---| | CMS and version | Determines sync method (WP plugin vs rsync) | | Database size | Downtime window sizing for final dump | | Custom cron jobs | Easy to forget — list from crontab or cPanel | | DNS zone (A, AAAA, CNAME, MX, TXT) | Prevents mail or verification breaks | | SSL type (AutoSSL, LE, commercial) | Re-issue on new host before cutover | | External integrations | Payment webhooks, ERP APIs, CDN rules |
Export a zone file or screenshot every record. Pakistani businesses often run Google Workspace or Zoho mail alongside cPanel web — do not change MX unless mail migration is intentional.
Provision the target plan (shared, managed WordPress, or VPS). Match PHP version, extensions, and memory_limit to production or staging baselines — upgrading PHP during cutover adds unnecessary risk.
Initial full sync options:
public_htmlPoint a temporary URL or /etc/hosts entry to the new server IP so QA happens without public DNS changes.
Test as if you were a customer:
.htaccess rules preservedFix issues on the new host while the old site continues serving production traffic.
| Step | Action | |---|---| | T−48h | Lower TTL on web A/AAAA records to 300–600 seconds | | T−1h | Announce maintenance window internally (not necessarily public) | | T−0 | Put old site in read-only if possible (optional for WP: maintenance plugin) | | T−0 | Run final database dump and incremental file sync | | T−0 | Update A/AAAA to new IP; verify SSL auto-provisions | | T+15m | Test from external DNS (1.1.1.1 / 8.8.8.8 lookup) | | T+24h | Restore TTL to normal (3600+ seconds) |
Some teams use dual-write briefly — complex and rarely needed for SME sites. Parallel staging plus one final sync covers most hosting migration scenarios without code changes.
Email: If MX still points to Google or Zoho, web migration alone does not move mailboxes. If mail lives on cPanel, migrate mailboxes before or after web — but update MX only when mailbox data exists on the destination.
SSL: Issue certificates on the new host before DNS switch so the first visitors after propagation hit HTTPS immediately. AutoSSL and Let's Encrypt need the domain to resolve or use DNS validation.
CDN: Pause or update origin IP in Cloudflare (or similar) in the same maintenance window as A record changes to avoid split-origin caching.
WordPress adds permalinks, siteurl/home options, and serialized data in the database. Search-replace URLs only with tools that respect serialization. After cutover, flush permalinks once and regenerate critical caches.
For a full WP checklist with plugin names and screenshots, use the dedicated managed WordPress migration guide — this playbook stays CMS-agnostic by design.
Keep the old host active until TTL cycles complete and metrics look stable (often 48–72 hours). Rollback is revert A record to old IP — which is why you should not cancel the old account immediately. Maintain a fresh backup on both sides until sign-off.
Choose self-service migration if you have SSH/SFTP access, a small static or WordPress site, and time to follow TTL and sync steps during a low-traffic window.
Choose hosting migration or Task Desk if you run WooCommerce with live orders, multi-site setups, custom Docker stacks, or compliance requirements — or if downtime cost exceeds assisted migration fees.
Destination unsure? Compare shared hosting vs VPS or start a brief at /desk/migrate-to-cloud-without-downtime.
You can minimise public downtime to near-zero with staging, TTL lowering, and a final sync before DNS cutover. Brief DNS propagation windows may still send some users to the old host until caches expire.
Lower TTL to 300–600 seconds at least 24–48 hours before switching A records so resolvers pick up the new IP quickly after you cut over.
Build and test on the new host first while DNS still points to the old server. Change DNS only after staging passes checks and a final delta sync is ready.
Map MX records separately from web A records. Changing web DNS does not have to move mail — document MX, SPF, and DKIM before any zone edits.
Yes. Use the hosting migration service for assisted moves, or open a Task Desk ticket for complex multi-site or custom stack migrations.
NVMe VPS, managed WordPress, and agency plans — starting at PKR 800/mo.