Migrating WooCommerce to GlassHosting

Migration mindset

Treat cutover as a rehearsal, not a leap of faith. Clone to staging, prove checkout and mail, lower DNS TTL, then cut over with a rollback plan you can execute without improvising. GlassHosting managed Woo is for SMB stores. Keep the playbook store-shaped: orders, webhooks, SSL, and customer email.

The goal is a boring cutover. Boring means customers keep buying while DNS settles, payment webhooks keep firing, and you can reverse DNS if something is wrong. Schedule the flip for a low-traffic window when you can watch the first orders land.

Prep inventory

List plugins, theme, custom mu-plugins or code snippets, required PHP version, and cron jobs (WordPress cron versus real system cron).
Export or note payment gateway webhook URLs, shipping API keys, and DNS records (A/AAAA/CNAME, plus mail-related records if they live on the same zone).
Take a full backup at the old host (files and database) before anything moves. Store a copy off that host.
Lower TTL on the store hostname 24 to 48 hours ahead when you control DNS. Short TTL makes rollback and cutover faster.
Write down admin users you will need after the move, and disable unused admin accounts before cutover day.
Note any CDN, WAF, or reverse proxy in front of the old site so you do not leave stale cache pointing at the previous origin.
Capture current WooCommerce and WordPress versions, plus any must-use drop-ins (object cache, advanced-cache) so staging matches reality.

Move and stage

Provision your GlassHosting Woo plan (plans) and confirm you can reach staging or the temporary hostname.
Move files and database carefully. Serialized PHP data breaks if you naive-replace domain strings across the whole database.
Fix mixed content, permalinks, and object-cache assumptions on staging. Flush caches after URL corrections.
Run a sandbox or low-risk checkout. Confirm order rows, stock adjustments if you track stock, and customer email delivery.
Re-point payment gateway webhooks and any shipping or tax plugins to the staging or final hostname as appropriate for the provider’s test mode.
Walk the paths that make money: guest checkout, logged-in checkout, coupon, and at least one refund or failed-payment path if you use them.
If you sell subscriptions or memberships, place a renewal or status check in staging before you trust production cutover.

Email and DNS before you flip

Order mail is part of checkout. Before DNS cutover:

Confirm the sending domain’s SPF and DKIM still make sense for how GlassHosting or your ESP sends mail.
Send a test order email to an external inbox (not only the store owner address) and check spam folders.
If you use a third-party transactional ESP, update any domain or webhook settings they require after hostname changes.
Decide whether www and apex both need to land on the store, and whether redirects match what payment providers allow in return URLs.

Cutover and rollback

Point DNS to GlassHosting when staging is green and you have a recent pre-cutover backup.
Confirm SSL, checkout, admin login, and payment webhooks on the live hostname within the first hour.
Monitor orders for 24 to 48 hours. Keep the old host available briefly for emergency rollback (files and DB snapshot intact).
If cutover fails, revert DNS first, then restore from the pre-cutover backup while you ticket with timestamps and what failed.
After a clean soak, decommission or lock down the old host so it cannot accept accidental traffic or webhook posts.

Rollback is a rehearsed DNS change plus a known-good backup, not a improvisation. Write the two or three commands or panel clicks you will use, and keep them next to the change log.

What usually breaks (and how to catch it)

Blind search-replace on serialized data: options and widgets corrupt. Prefer Woo-aware migration tooling.
Webhooks still on the old URL: paid orders look pending. Verify gateway dashboards after DNS.
Hard-coded old URLs in theme or CSS: mixed content or broken assets on checkout.
Cron not running: delayed emails, subscription renewals, or scheduled sales never fire.
Cache layers still serving the old origin: intermittent old-site content after cutover.
PHP version mismatch: a plugin that worked on 8.1 fatals on 8.3 (or the reverse). Match staging to the target runtime before cutover.

Aftercare for the first week

Watch abandoned-cart and failed-order rates if you have those reports. Spot-check a handful of real customer emails. Confirm sitemap and Search Console still resolve to the live host once DNS has settled. If you use a staging clone after cutover, refresh it from production so the next plugin test is not against stale data.

Verify / done

Staging proved cart, checkout, and order email before DNS moved.
Live HTTPS and payment flows work on the real domain.
Webhooks and transactional mail work for a real or carefully labeled test order.
You know the rollback DNS and backup path without improvising late at night.
Old host is no longer the silent backup brain for webhooks you forgot to move.