Managed WordPress Migration: A Cutover Runbook for a Pakistani Shop

A managed WordPress migration is a cutover of a shop that is still taking orders. The first copy is a snapshot. Later orders, stock edits, and new customers stay on the source until a second copy. Inventory plugins, mail, DNS, and payment dependencies. Copy to staging. Verify paths and scheduled tasks. Agree a write freeze or a final-sync plan. Test checkout in the payment provider sandbox. Then switch traffic, monitor, and retain rollback. A DNS edit alone leaves every post-snapshot order on the old database.

What the cutover has to decide

The destination is managed WordPress hosting, the platform that will run PHP, the database, certificates, and the scheduler. Six facts must be written before traffic moves: a finished inventory, a staging click-through, scheduled tasks a person has seen, a sandbox payment, a named rollback owner, and a freeze window with a start and an end. Record them on the task desk. A plugin count with no webhook notes is not an inventory, and "the host" is not a rollback owner. The sequence is a written plan. It is not, by itself, permission to move a live store.

Inventory plugins, mail, DNS, and payment dependencies

Plugins and outside services

List plugins that touch checkout, shipping, tax, SMS, couriers, cache, login locks, or extra fields. Note tables, outside calls, and any saved site URL or secret. A badge moves with the files. A courier plugin that books a pickup on processing will use the URL and key active after the switch, so mark sandbox versus live and who rotates the key. Keep deactivated plugins on the list. They still store old URLs.

Mail and website DNS

Order mail may leave through the host, SMTP, or a transactional provider. MX records receive replies and are not the website. Write the sending hostname, the MX hosts, and which records stay when the site name moves. Replacing the whole zone can drop mail as the shop moves. Lower the TTL on the website A, AAAA, or CNAME records before cutover day, or resolvers keep the old answer.

Notify URLs and cash on delivery

Card, wallet, and bank plugins store a merchant id and a notify URL. Copy that URL and any refund URL. The browser return is a separate request, so a thank-you page can show while the paid status still posts to the old host. Cash on delivery writes an order, a stock change, and often an SMS, with no webhook. Those rows belong in the final sync. Card and wallet methods need the provider sandbox. Cash on delivery needs a staging test order that never captures live funds.

Copy to staging and verify paths

The first copy lands on staging while production keeps the domain. Open home, a category, a product, the cart, the account, the thank-you page, login, and one order. Permalinks can 404 when the layout or a security plugin differs. Replace media URLs that name the old host, then open a few images. If staff cannot open an order, the copy is not ready for a freeze. A new slug without a redirect is a broken path. WordPress describes heavy plugins and uncached pages in its optimization guidance. Mark plugins that run on every request. If salts differ from production, sessions end, so copy them on purpose or tell staff to sign in again.

Scheduled tasks have to be seen

Queued work covers mail retries, webhooks, stock notes, and cache cleaning. Some hosts run it only on a visit. Others use system cron. Either can vanish while the shop looks open. On staging, list hooks beside production with the next run and the clock zone. A UTC host and Pakistan Standard Time in the shop can make a task look late. Proof is one staging task that completes. Card and courier jobs stay on sandbox credentials, or stay paused, until the freeze. WordPress states what a backup is for in its backup guidance. A morning dump is already behind the next order, so the freeze has to sit next to the switch.

Why a managed WordPress migration needs a final sync

DNS does not carry rows

DNS tells resolvers which address should answer for the domain. It does not copy tables or merge databases. During the first copy, payments, shipped marks, coupons, and stock changes land on the source. The target keeps the earlier read. Switching the domain serves that older snapshot, so later orders exist only on the old host.

A changing order database needs a final sync, not merely a DNS edit, because writes continue after the first read. That second copy starts only after writes stop, or after the last allowed writes are included and checkout then closes. Either close checkout for a named window and sync inside it, or keep selling on the source and then freeze briefly for the last sync. Syncing if time allows is a DNS-only cut. Coupons, refunds, notes, stock, and new customers missed by the first snapshot belong in that second pass.

Order tables, without a storage-mode change

Name the order tables in the inventory, and sync that same list. WooCommerce documents High-Performance Order Storage, where order storage may be dedicated tables rather than the posts table alone. Compatibility must be checked before any storage-mode change. This runbook does not call for a production toggle of storage mode during cutover. If dedicated order tables are already in use, the final sync includes them. Skipping them leaves the latest orders behind.

Sandbox checkout before traffic moves

Staging uses sandbox keys. A tester pays, and the order status must match the webhook, not only the browser return. Record the sandbox transaction id beside the staging order id. Live keys stay off staging. If the webhook fails, correct the notify URL and repeat. Change production notify URLs only inside the freeze, after that pass. Place one cash-on-delivery test order as well. That method has no card transaction id. The row and its status are the proof.

Switch traffic, monitor, and keep rollback

When every go row is true and the freeze holds, point website DNS or the proxy at the target and leave MX on the mail plan. Watch errors, checkouts, order mail, the scheduler, and the old site. A stray order there means a leaked freeze or a cached old address. The rule says whether the owner copies it or staff handle it on the old admin. Rollback needs the previous DNS values, the freeze-point backup, and a person allowed to use them. Orders taken on the target after the switch need a short copy back or manual entry. Name a deputy and a watch clock. If mail fails or the scheduler stalls, roll back instead of debugging live checkout.

An illustrative dry-fruit shop in Peshawar

This shop is illustrative, not a measured business, and it states no revenue. A dry-fruit seller in Peshawar keeps taking almond orders, including cash on delivery, during the first copy. Twenty minutes in, a buyer orders almonds for that evening. The insert lands after the orders table was read. Staging lacks the row and still shows the almonds in stock.

A DNS-only cut points the domain at that snapshot. The new order list skips the buyer, the target can sell the same goods again, and a wallet notice may still hit the old URL. Cash on delivery leaves no provider message to find later. Reloading the new domain cannot rebuild a missing row.

The illustration then freezes after packing, in Pakistan time, with the host clock zone written down. Checkout shows a holding notice and staff stop status edits. The final sync copies the inventoried order tables, dedicated tables if those are already in use, stock, and new customers. The almond order arrives on the target. Sandbox and cash tests already passed. Live notify URLs change in the freeze, and website DNS moves only after that. The rollback owner holds the old DNS values and the freeze-point backup through the watch. Without the freeze, the order stays on the source.

Criteria that allow the switch

Move traffic only when every row is true. One open row holds the cut.

Criterion	Go only when
Inventory complete	Plugins, mail path, DNS records that stay, and payment webhooks are written down with owners.
Staging click-through	Home, category, product, cart, account, and thank-you paths answer, and staff can open an order.
Scheduled tasks seen	Hooks were listed beside production, with next run and timezone, and one staging task completed.
Sandbox payment	A sandbox transaction id matches a staging order, and a cash-on-delivery test order is visible.
Rollback owner	A named person and deputy may restore prior DNS and the freeze-point backup.
Freeze window	Start, end, clock zone, and whether checkout is closed are written before the final sync.

Source and target ownership

Write who holds each dependency so mail, payments, and rollback do not fall between accounts.

Dependency	Source side	Target side
Files	Current host account, plus a freeze-point copy kept for rollback.	Platform account after staging paths are accepted.
Database	Live orders until the freeze, then the snapshot the final sync reads.	Must receive every order table, stock change, and new customer.
Mail DNS	MX and the sending host stay unless a separate mail plan moves them.	Website records may change without copying MX lines.
Payment webhooks	Notify URL keeps the old host until the sandbox pass is recorded.	Notify URL changes only inside the freeze, after sandbox proof.
Cron	Visitor cron or system cron, listed before cutover.	Platform scheduler, accepted only after a task is seen to finish.
SSL	Certificate buyers use on the current host.	Certificate issued for the shop domain before traffic moves.
Who may roll back	Named owner and deputy, with prior DNS values written down.	Same owner applies the rule for orders taken after the switch.

Editorial review date: 10 October 2026. The original publication date is unchanged.

Before any production copy

Write the freeze window and the rollback owner before copying production. The window states when checkout closes and when the final sync may start, in the clock zone staff will read. The owner may restore the prior DNS and the freeze-point backup if checkouts fail or orders exist on only one side. Those two lines give the inventory, the path checks, the task sighting, and the sandbox payment a clock and a name.