What rollback actually means on a course site
For a brochure site, rollback is just pointing DNS back at the old server. For a course or membership site it is harder, because the new site starts collecting data the moment traffic arrives: purchases, enrollments, lesson progress, password changes and new accounts. Switching DNS back hides that data rather than moving it.
Host tools do not solve this for you. Kinsta's push documentation says any changes to the live site's database since the staging site was created will be lost when you push a database, giving comments, content and purchases as examples, and that MyKinsta does not separate new WooCommerce orders from old ones. WP Engine's copy documentation says it does not recommend pushing an entire database to production because the live site can lose data such as orders or users. The same logic applies when you roll back by restoring an old database: anything newer disappears unless you carry it across.
Rollback triggers and who decides
Agree the triggers in writing before the window opens, so nobody is debating at midnight whether a broken checkout counts. Name one person who can call the rollback and one backup. Set a decision deadline: after a fixed number of hours on the new host, fixing forward becomes cheaper than reconciling data back.
| Symptom on the new host | Severity | Default action |
|---|---|---|
| Checkout fails or payments succeed at the processor but no order or enrollment is created | Critical | Roll back unless fixed within 30 minutes |
| Members cannot log in, or logged-in pages error while the cached homepage looks fine | Critical | Roll back unless fixed within 30 minutes |
| Lesson video or downloads fail for all students | High | Fix forward if cause is known; otherwise roll back |
| Transactional email (receipts, resets) not sending | High | Fix forward; switch SMTP settings, no rollback needed |
| Payment webhooks failing | High | Fix the endpoint; processors retry, so rollback is rarely needed |
| Slower pages but working paths | Medium | Fix forward and monitor |
| Cosmetic layout issues | Low | Fix forward |
Keep the old host ready to take traffic back
- Do not cancel, downgrade or let the old plan expire until the new host has been stable for an agreed period.
- Do not change anything on the old site after the final copy; note the exact time of the last database export.
- Lower DNS TTLs a day or more before cutover. Cloudflare, for example, lets unproxied records go as low as 60 seconds on non-Enterprise plans and sets proxied records to a fixed 300 seconds, but it notes that local DNS caches can take longer than 5 minutes to reflect a change.
- Keep the old site's SSL certificate valid so a switch back does not produce browser warnings.
- Leave the old payment webhook endpoint configured until you are sure you will not roll back, or plan to re-point it.
- Record the exact DNS values for both hosts in one place so the switch back is a copy, not a search.
Reconciling orders and enrollments made during the window
Before you switch back, export everything created on the new host after cutover: orders, new users, enrollments, membership status changes and completed lessons if your LMS stores them separately. Use the cutover time you recorded as the boundary.
Your payment processor is the record of truth for money. Stripe documents that in live mode it retries failed webhook deliveries for up to three days with exponential back-off, that a dashboard resend works for up to 15 days after an event and a CLI resend for up to 30 days, and that delivery order is not guaranteed. In practice that means a purchase made during the window can be replayed into the old site by resending its events once DNS and the endpoint point back there, as long as the old site handles duplicates by event ID.
Anything that is not driven by the processor, such as free enrollments, manual grants, profile edits and forum posts, has to be re-entered or accepted as lost. Keep the window short to keep that list short.
| Data created on the new host | How to carry it back | Who checks |
|---|---|---|
| Paid orders and subscriptions | Resend processor events to the old endpoint, or recreate from the processor dashboard | Owner or finance contact |
| New user accounts | Export users created after the cutover time and import, or ask students to re-register | Site admin |
| Free or manual enrollments | Re-grant from an export list | Site admin |
| Password changes | Send affected students a reset link after rollback | Support |
| Lesson progress and quiz attempts | Usually accepted as lost for a short window; tell students | Support |
| Content edits by staff | Freeze editing during the window so there are none | Project lead |
A rollback runbook you can follow at 2 a.m.
- Announce a content and settings freeze to staff for the whole window.
- Put the new site into a limited mode that blocks checkout if you can; Google recommends limiting functionality rather than taking a whole site offline, and if you do disable it briefly, a 503 status with a Retry-After header for one to two days at most.
- Export orders, users and enrollments created on the new host since the cutover time.
- Switch DNS records back to the old host values you recorded.
- Re-point payment webhooks if you changed them, and resend events for orders made during the window.
- Re-create remaining accounts and enrollments from the export.
- Test login, a lesson page and a test purchase on the old host.
- Email affected students using a short, factual message.
- Write down what failed before attempting the next cutover.
When rollback is the wrong choice
Rollback is expensive after the first day because the list of data to reconcile grows. If the new host is working for most students and the failure has a known cause, fixing forward is usually cheaper. Email, webhooks and caching are almost always fixable in place. Reserve rollback for failures that stop students paying or learning and that you cannot diagnose within the time limit you set.
Questions before you decide
How long should I keep the old host after migrating?
Until the new site has run cleanly through the checks you care about, including at least one renewal or payment cycle if you sell memberships. The old host is your rollback path, so do not cancel or change it during that period.
Will a host restore or database push keep orders made after the copy?
No. Kinsta says database changes on live since the staging copy was made are lost on a database push, and WP Engine advises against pushing a whole database to production because orders or users can be lost. Export new data first.
Can Stripe replay payments taken during the window?
Stripe lets you resend an event from the dashboard for up to 15 days and from the CLI for up to 30 days, and retries failed live deliveries for up to three days. Events can arrive out of order, so the receiving site must handle duplicates by event ID.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Kinsta: push environments Accessed 30 Oct 2026
- WP Engine: copy an environment Accessed 30 Oct 2026
- Stripe: receive events in your webhook endpoint Accessed 30 Oct 2026
- Cloudflare DNS: time to live (TTL) Accessed 30 Oct 2026
- Google Search Central: pausing or disabling a website Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.