Worked example: an online shop moves its WooCommerce site between cPanel hosts without downtime
A fictional online shop follows our cPanel hosting migration playbook: inventory, a full backup, an account-level transfer, hosts file testing, a short order freeze, a final sync and a DNS switch while the old host keeps running. The shop is invented to show how the steps fit together.
Who they are and what they faced
Illustrative example. The organisation is fictional; the steps follow our How to move a website between cPanel hosts without downtime.
Organisation
A small online shop selling homewares through WooCommerce, run by the owner and a part-time administrator (fictional)
Moving from → to
A shared cPanel account at the old host holding the WordPress and WooCommerce site, its database, a staging subdomain, an addon domain for a second brand and the shop's mailboxes → A cPanel account on a VPS at a new host, where the shop's IT contractor has root access in WHM
Constraints
- The shop must stay online throughout; customers should never see an error page
- Orders arrive at all hours, so the order freeze has to be short and announced on the site
- Only a cPanel login, with SSH access to the account, is available on the old host, not root
- Mail for orders, supplier invoices and customer service runs on the same cPanel account
Assess
The contractor worked through the inventory step of the playbook in the old cPanel. They listed the main domain, the addon domain, the staging subdomain and their document roots; every DNS record with its TTL, including SPF, DKIM, DMARC and the payment and search verification TXT records; the database and its user, found from DB_NAME and DB_USER in wp-config.php; every mailbox, forwarder and autoresponder; and every cron job, noting which paths contained the old username.
They recorded the PHP version and custom INI values from MultiPHP Manager and MultiPHP INI Editor, and which domains had a certificate in SSL/TLS Status. nslookup -type=ns showed the domains used the registrar's DNS service, not the old host's nameservers.
Decisions
- Use Transfer or Restore a cPanel Account in WHM on the new server The playbook recommends this account-level method when you have root on the new server but only a cPanel login on the old account. The Transfer Tool needs root or sudo on the source.
- Change only A records at the DNS provider on cutover day Because DNS was not at the old host, the playbook's simplest route applied: no nameserver change, and cancelling the old host later would not remove the zone.
- Keep mail on cPanel at the new host The shop did not want to change mail platform during the move, so mail travelled with the account and the mail host record moved with the A records.
Plan
The owner chose a quiet evening for the cutover and agreed a short order freeze with a notice on the site. The plan put TTL lowering at least one full old-TTL period ahead, a full backup as the rollback copy, the first transfer, hosts file testing, then the freeze, final sync and DNS switch, with the old account kept active and unsuspended afterwards.
The risk register used the playbook's rollback triggers: database connection errors after the switch, mail failing on the new host, checkout or payment failing, certificate warnings lasting longer than agreed, and missing data that could not be re-synced in time.
Decisions
- Stop taking orders instead of switching the whole site to maintenance mode The playbook allows either for a shop. Stopping orders kept the catalogue visible, which met the no-downtime goal while still freezing the data that matters.
- Keep the old account until mail and DNS settle The playbook says to keep the old account active for at least the old TTL plus a margin, then collect late mail.
Design
The Network and DNS worksheet listed each record to change on cutover day (A for the domain, www and the mail host, and AAAA because the new server had no IPv6) with current and target values, and SPF updated to include the new server because it would send order mail. The Application inventory and dependency map listed what talks to the site: the payment gateway, the shipping plugin's callbacks, the accounting integration and the scheduled jobs.
The new plan was sized with at least twice the account's disk usage free, as the playbook advises, after old backups, logs and mailbox Trash folders were cleared.
Decisions
- Keep the same cPanel username on the new host The playbook says database names and paths change when the username changes, which would mean editing
wp-config.phpand every cron path. - Export the current certificate and key from the old host The playbook advises installing them on the new host so HTTPS works from the first request, with AutoSSL as the follow-up once DNS points at the new server.
Execute
The contractor generated a full account backup from Files > Backup on the old host and downloaded it as the rollback copy. In WHM on the new server they used Transfers > Transfer or Restore a cPanel Account with the old cPanel login to pull the account, then compared the domain list with the inventory and added the addon domain back with Create A New Domain, because the playbook warns Restricted Restore skips parked and addon domains. They set the recorded PHP version and INI values.
Testing used the hosts file on the contractor's PC pointed at the new server's IP address: home page, product pages, the cart and checkout in the payment gateway's test mode, the contact form, the admin login, and an outbound email from new host webmail. Every problem went into the runsheet, was fixed and re-tested, and the hosts file lines were removed afterwards. Cron jobs were added on the new host but commented out until cutover.
Decisions
- Test checkout in test mode before anyone sees the new host Checkout failure is one of the playbook's rollback triggers, so it was proven before DNS changed.
- Hold cron jobs back on the new host The playbook says each job should run once, on one host only, so jobs were enabled on the new host and disabled on the old one at cutover.
Cutover
At the agreed time the owner stopped taking orders and showed the store notice, and editors stopped publishing. The contractor exported and imported the database again, following export and import a MySQL database, and re-ran the rsync command for uploads. The exported certificate and key were installed on the new host before the switch.
The A records for the domain, www and the mail host were changed at the DNS provider to the new server's IP address, the AAAA records were removed and SPF was updated. The contractor checked answers from several public resolvers with nslookup, enabled the cron jobs on the new host, ran AutoSSL for domains without an exported certificate, and disabled the same cron jobs on the old host. The owner placed a real low-value order, then reopened the store.
Decisions
- Change DNS by hand at the DNS provider The playbook's zero-downtime pattern is to test, freeze, copy the changes and then change DNS yourself, rather than letting the Transfer Tool's Live Transfer option change records on the source.
- Reopen orders only after a real order completed on the new host A test order is part of the playbook's validation that site functions work for real visitors.
Close
Over the following days the contractor watched propagation, then checked each old mailbox for messages received after the cutover time and moved them to the new mailboxes. Once no new mail or orders had reached the old host for a full day, TTLs were raised again.
Validation followed the playbook: every domain present with the same document root, the newest order from before the freeze on the new host, DNS answering with the new server everywhere, valid certificates with no AutoSSL problems, mail flowing both ways, cron running once on the new host. A final full backup of the old account was stored off both servers before the account was cancelled and the date recorded in the Decommission checklist.
Decisions
- Treat cancelling the old account as final The playbook says once the host removes the account its files, databases and mailboxes are gone, so the final backup came first.
The cutover timeline
- Two days beforeLower the TTL on the A, AAAA, www and mail host records to a few minutes at the DNS provider.
- Day beforeFinal hosts file test of checkout, forms and admin login on the new host. Store notice about the short order pause published.
- Cutover evening 20:00Stop taking orders and freeze content edits. Record the time in the runsheet.
- 20:05Export the database from the old host and import it on the new host. Re-run rsync for uploads.
- 20:25Spot check: the newest order from before the freeze is visible in the new host's admin area.
- 20:30Install the exported certificate and key on the new host if not already done.
- 20:35Change A records for the domain, www and the mail host to the new IP address. Remove AAAA records. Update SPF.
- 20:45Check answers from several public resolvers. Enable cron on the new host, run AutoSSL where needed and disable cron on the old host.
- 21:00Place a real order, check order mail arrives, then reopen the store.
- Following daysWatch propagation, collect late mail from the old mailboxes, raise TTLs, then take a final backup and cancel the old account.
What surprised them and what they did
The addon domain was missing after the restoreRestricted Restore skips parked and addon domains. The contractor added it back with its original document root, as the playbook describes.
A database connection error appeared in hosts file testingThe new database name did not match wp-config.php. It was fixed before cutover, which is why the playbook tests with the hosts file first.
Late mail kept arriving at the old host for a whileSome senders cached old DNS. Keeping the old account active meant nothing was lost, and the mail was moved across once DNS settled.
A scheduled job used a path with the old usernameThe cron inventory had flagged it. The path was corrected on the new host before cron was enabled.
The staging subdomain had no certificate on the new hostIt had not been exported. AutoSSL issued one once DNS pointed at the new server.
Templates they used
Questions
Is this a real shop?
No. The shop is fictional. It shows how the steps in our cPanel hosting migration playbook fit together for a small online store.
Was there really no downtime?
The site stayed online throughout. Orders were paused for a short freeze so the final database copy was complete, which the playbook recommends for shops.
Why not use the WHM Transfer Tool?
It needs root or a sudo user on the source server. The shop only had a cPanel login on the old shared host, so the playbook points to Transfer or Restore a cPanel Account.
How could they roll back?
While the old account was active and unsuspended, by pointing DNS back at the old IP address and copying back any orders taken on the new host.
When was it safe to cancel the old host?
After DNS had settled, late mail was collected, no new mail or orders reached the old host for a full day and a final backup was stored off both servers.