A website update breaks checkout at 4:47 p.m. The developer says the fix should take 20 minutes. Forty minutes later, customers still can’t pay, the owner is refreshing the page, and nobody can answer the only question that matters: can we put the last working version back?
That question should be answered before a release, not during a failure.
A rollback plan is a short, tested procedure for restoring the last known-good version of your website. It covers more than code. A modern site may include a database, uploaded files, DNS records, payment settings, analytics tags, form integrations, and third-party services. Reversing one layer while ignoring the others can turn a small outage into a larger mess.
This playbook gives a small business a usable rollback process without building an enterprise incident department.
What a rollback actually means
A rollback returns a system to a known working state. It isn’t the same as fixing forward.
With a rollback, you restore the previous release and investigate after service is stable. With a fix forward, you keep the new release live and deploy another change to repair it. Both approaches have a place. The mistake is improvising the choice while leads or sales are being lost.
Hosting platforms often make code rollback easy. For example, Netlify supports restoring a previous production deploy, while Cloudflare Pages documents rollbacks to an earlier deployment. That button does not necessarily reverse a database migration, restore deleted media, undo a DNS edit, or recover orders sent to another system.
Your plan must define exactly what each rollback method restores.
Decide when to roll back before you launch
Write down objective triggers. Otherwise, a team can spend an hour debating whether a broken release is broken enough.
Roll back immediately when any of these conditions occurs:
- Customers can’t complete the primary conversion, such as buying, booking, requesting a quote, or calling from a mobile device.
- The release exposes private data, creates an authentication problem, or weakens security.
- Important pages return errors, redirect incorrectly, disappear from navigation, or become unavailable to search engines.
- Analytics, advertising, or form routing sends sensitive data to the wrong destination.
- The team can’t identify and safely test a fix within the agreed time limit.
Set that time limit in advance. For a brochure site, 30 minutes may be reasonable. For an ecommerce checkout during a promotion, five minutes may be too long. The right threshold depends on revenue risk, not developer optimism.
Minor spacing issues, a typo, or a noncritical browser quirk can usually be fixed forward. A broken payment path should not stay live while someone experiments in production.
Build a complete recovery inventory
Start by listing the parts that can change. Small business sites are often treated as one thing, but recovery usually spans several systems.
Code and configuration
Keep website code in version control and label production releases. Git’s documentation explains tags as references commonly used to mark release points. A release identifier lets your developer answer “what was live before this?” without guessing from file dates.
Document environment variables and hosting configuration separately. API keys and credentials should stay out of the repository. Record who controls them, where they are managed, and how to restore prior values.
Database
Content management systems, ecommerce stores, membership sites, and booking systems store live information in databases. Confirm how often backups run, how long they’re retained, and whether a restore replaces the full database or selected tables.
Database rollback needs extra care. Restoring a backup from noon at 3 p.m. could erase three hours of orders, form entries, account changes, or inventory updates. The safest response may be to roll back code while leaving the database intact. Any database migration should therefore have a documented reverse procedure or a compatibility period in which the old code can still use the new database structure. Build those backup checks into a recurring small business website maintenance checklist so recovery readiness does not depend on someone remembering it before a launch.
Uploaded files and generated assets
Customer uploads, product images, PDFs, and CMS media may live outside the code repository. Verify that the backup system covers them. WordPress documentation notes that a complete backup requires both the database and website files.
DNS, domains, and email
A normal hosting rollback won’t undo DNS edits. Before changing DNS, export or screenshot every record and lower the TTL early enough for the change to take effect. Cloudflare’s DNS guidance explains that TTL controls how long records are cached.
Pay special attention to MX, SPF, DKIM, and DMARC records. A rushed website migration can accidentally interrupt email even when the site itself works.
External services
List payment gateways, CRM connections, scheduling tools, email platforms, webhooks, analytics, consent tools, and advertising pixels. Record an owner and a basic test for each. A green homepage does not prove that a quote request reached the sales inbox.
Create a release checkpoint
Every production change should have a small packet of information. This can be a ticket, shared document, or deployment note. It needs:
- Release name, time, owner, and business reason.
- Link to the previous known-good release.
- Database or content changes included in the release.
- Backup completion time and restore instructions.
- Five to ten tests that prove the business still works.
- Rollback decision-maker and time limit.
- Communication contacts if customers are affected.
Keep the test list short enough that people will run it. For a service company, test the homepage, one service page, primary form, thank-you page, call button, email delivery, analytics event, and mobile navigation. For a store, add product search, cart, checkout, payment confirmation, tax, shipping, inventory, and order notification. Include measurable speed limits from a website performance budget when a release changes images, scripts, fonts, or third-party tools.
Google recommends testing site moves carefully, changing one major thing at a time where practical, and monitoring after launch in its site move documentation. The same discipline helps with ordinary releases. When a redesign, domain change, CMS migration, and copy rewrite happen together, diagnosing a failure becomes much harder. A website redesign measurement plan gives the team baseline metrics and launch guardrails to spot regressions quickly.
Use this rollback procedure during an incident
When a serious problem appears, stop making unrelated changes. Assign one person to coordinate and one to perform the technical work. Then follow this sequence.
1. Confirm and record the failure
Reproduce the problem on the affected device or workflow. Save the exact URL, time, screenshot, error message, browser, and steps. Check whether the issue affects everyone or a limited group.
2. Protect incoming business data
Before restoring a database, export new orders, leads, bookings, accounts, or inventory changes created since the backup. If data can’t be preserved safely, pause the affected transaction path and show customers a clear message with another contact method.
3. Call the rollback decision
Compare the incident with your written triggers and time limit. The designated decision-maker makes the call. Avoid a committee vote while the site is losing transactions.
4. Restore the last known-good release
Use the hosting platform’s restore function or deploy the tagged prior version. Reverse configuration changes that belonged only to the failed release. Restore the database or files only when the incident requires it and current business data has been protected.
5. Clear and verify caches
A successful restore can still look broken when a browser, CDN, application cache, or service worker serves old files. Purge only the relevant caches where possible, then test in a fresh session and on a mobile connection.
6. Run business-path checks
Do not stop at “the homepage loads.” Submit a real test lead, complete a low-value test transaction if appropriate, verify notification delivery, and confirm the analytics event. Check logs for continuing errors.
7. Communicate and preserve evidence
Tell internal staff what failed, what was restored, and whether any customer data or transactions need manual follow-up. Keep logs, screenshots, release identifiers, and timestamps for the review.
Test the plan before you need it
An untested backup is a hope, not a recovery method. Schedule a restore drill at least twice a year and before a risky migration. Restore the site into a private staging environment, time the process, and run the business-path checks.
The drill should answer four questions: Can you find the backup? Can the right person access it? Does it restore successfully? Does the restored site actually accept and route a lead or order?
Also test when the usual developer is unavailable. Store instructions in a business-controlled account, not only in an agency’s private system. Use individual logins with appropriate permissions and keep emergency access protected with multifactor authentication.
Review the failure without blaming people
After service is stable, write a short incident review. Record the customer impact, timeline, cause, detection method, rollback duration, and actions that will prevent a repeat.
Useful actions are specific. “Be more careful” changes nothing. “Add an automated checkout test before production deploys” changes the system. So does “require a database snapshot before running migrations” or “send form failures to an alerting channel.”
Update the rollback playbook while the details are fresh. If the restore took 52 minutes because nobody could access the hosting account, access ownership is part of the failure.
A one-page rollback plan is enough to start
You don’t need a thick disaster-recovery binder. You need a current list of systems, a known-good release, tested backups, clear rollback triggers, and one person authorized to act.
Start with the page that makes money. Define how to prove it works, how long you will tolerate failure, and how to restore its supporting systems. Then run the drill.
If your website has no documented recovery path, talk with YourWebTeam about building and maintaining one. A rollback plan costs far less than discovering during an outage that your backup never covered the database.
Frequently asked questions
How often should a small business back up its website?
Match backup frequency to how much data you can afford to lose. A mostly static site may need daily backups and a backup before each release. A busy store or booking site may need much more frequent database protection. Retention matters too, because a problem may go unnoticed for days.
Is a hosting backup the same as a rollback?
No. A hosting backup may restore files and a database, while a deployment rollback may restore code only. Ask your provider exactly what is captured, where backups are stored, how long they’re retained, and whether you can restore them without support.
Should we roll back every failed update?
No. Fix forward when the issue is minor, isolated, and safely repairable within your agreed window. Roll back when a core business path, security, privacy, or data integrity is at risk.
Who should be allowed to order a rollback?
Name one primary decision-maker and one backup. They should understand the business impact and have a direct line to the person performing the restore. The technical operator should not have to chase three executives for approval while checkout is down.
