Website Naye Host Par Bina Downtime Migrate Kaise Karein

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 (/blog/a-step-by-step-guide-to-moving-your-pakistani-business-to-managed-wordpress). For hands-on execution, use (/hosting-migration) or the Task Desk brief at /desk/migrate-to-cloud-without-downtime.

---

Key Takeaways

• Never cut DNS first — build and test on the new host while the old site stays live
• Lower DNS TTL 24–48 hours before cutover for faster propagation
• Use hosts file or staging URL to QA before the world sees the new stack
• Final delta sync catches orders, comments, and form submissions during migration window
• Email (MX) and web (A/AAAA) are independent — plan both explicitly

---

Migration Phases Overview

| 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 |

---

Phase 1: Pre-Migration Audit

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.

---

Phase 2: Build on the Destination Host

Provision the target plan ((/shared-hosting), (/managed-wordpress-hosting), 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:

• WordPress: migration plugins (Duplicator, All-in-One WP Migration) or manual tarball + mysqldump
• Static / HTML: rsync or SFTP mirror of public_html
• Custom apps: git deploy + env file + database restore

Point a temporary URL or /etc/hosts entry to the new server IP so QA happens without public DNS changes.

---

Phase 3: Staging QA Checklist

Test as if you were a customer:

• Homepage, key landing pages, and mobile layout
• Login, checkout, or form submissions (use test mode for payments)
• wp-cron or application schedulers firing
• Email send from contact forms (SMTP credentials updated?)
• SSL certificate valid on new host name (no mixed-content warnings)
• 301 redirects and .htaccess rules preserved

Fix issues on the new host while the old site continues serving production traffic.

---

Phase 4: DNS TTL and Cutover Strategy

| 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, SSL, and CDN During Cutover

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-Specific Notes (Brief)

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 (/blog/a-step-by-step-guide-to-moving-your-pakistani-business-to-managed-wordpress) — this playbook stays CMS-agnostic by design.

---

Rollback Plan

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.

---

Which Option Should You Choose?

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 (/blog/shared-hosting-vs-vps-hosting) or start a brief at /desk/migrate-to-cloud-without-downtime.

---

Frequently Asked Questions

Can I migrate without any downtime at all?

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.

How long before cutover should I lower DNS TTL?

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.

Should I migrate files or DNS first?

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.

What about email during migration?

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.

Does Pakish offer migration help?

Yes. Use the hosting migration service for assisted moves, or open a Task Desk ticket for complex multi-site or custom stack migrations.

---

Related Guides

• (/blog/a-step-by-step-guide-to-moving-your-pakistani-business-to-managed-wordpress)
• (/blog/shared-hosting-vs-vps-hosting)
• (/blog/wordpress-hosting-vs-shared-hosting)
• (/blog/manage-dns-records-cpanel-zone-editor)

---

Sources

• (https://www.icann.org/resources/pages/dns-2012-02-25-en)
• Let's Encrypt documentation
• (https://developer.wordpress.org/advanced-administration/server/wordpress-on-web-server/)