Staging, Backups and Rollbacks: A Release Process for Small Sites

You need three things, and you can have all of them for under ten dollars a month: a staging copy you can break, an off-server backup you have actually restored once, and a written way to put the old version back inside ten minutes. That is a release process. It is not a pipeline, it does not need a platform team, and it will save you the specific bad afternoon where a plugin update takes your shop offline during a campaign.

The three jobs a release process has to do

Strip away the vocabulary and a release process answers three questions. Can I see this change working somewhere that is not production? If it goes wrong, how do I get the previous version back? And if the server itself is gone, what do I rebuild from? Staging answers the first, rollback answers the second, backups answer the third. They are three different problems and people routinely try to solve all three with one nightly backup.

That conflation is where the pain comes from. A nightly backup is a poor rollback mechanism, because restoring it throws away everything that happened since midnight: orders, form submissions, comments, a page somebody wrote this morning. A staging site is a poor disaster recovery plan, because it usually lives on the same server as the thing it is meant to replace. Keep the three jobs separate in your head and the right tool for each becomes obvious.

Scale this to your actual risk. A brochure site for a consultancy can lose a day of changes and nobody notices. A shop taking fifty orders a day cannot lose an hour. Write down the longest gap you can tolerate between your last good copy and now, and the longest you can be offline while you recover. Those two numbers decide everything else in this article, and they are a business decision rather than a technical one.

Staging is for proving, not for playing

Staging exists to answer one question: does this specific change work against real data? That means a staging site has to be a copy of production, refreshed often enough to be honest, with the same PHP version, the same plugins and the same theme. A staging site running a six-month-old database will cheerfully pass a test that production then fails.

Three rules keep it useful. Make it inaccessible to search engines and to the public, because a staging copy of your shop indexed by Google is its own small disaster. Put payment gateways and transactional email into test mode, or stub them out entirely, so nobody receives a real invoice from your test order. And refresh it from production before each release rather than after, so what you are testing is what you have.

Most managed hosts give you a one-click staging environment, and most shared plans do not. If yours does not, a second cheap virtual server or a subdomain on the same plan will do, as long as you remember that it shares a fate with production. Our guide to web hosting types sets out which tiers include staging and which expect you to build it.

What a real backup looks like

A website backup has three parts and most backups only cover two of them. You need the database, the uploads folder, and the code: themes, plugins and any custom work. Plenty of plugin-based backups quietly skip large upload folders to stay inside a memory limit, which you discover during the restore rather than during the backup.

The convention worth following is three copies, on two kinds of storage, with one of them somewhere your hosting account cannot reach. The last part is the one people skip, and it is the part that matters. A backup stored on the same server is useless against the two most common real disasters: the account being suspended, and an attacker with your credentials deleting everything including the backup directory.

Then there is the test. A backup nobody has restored is a file of unknown value. Pick one quarter a year, restore last night’s backup to staging, and time it end to end. The first time, it takes most teams two hours and uncovers something: a missing database user, a hard-coded domain in a plugin table, an uploads folder that was never in scope. The second time it takes twenty minutes. That difference is the entire value of the exercise.

What backups actually cost

Backup pricing is unglamorous and cheap, which makes the decision easy once you see the figures. These are the published prices for the two patterns small sites actually use: managed backups bundled with hosting, and self-managed snapshots on a virtual server.

Snapshots and backups are not the same product, and the price difference reflects that. A snapshot is a manual point-in-time image you take before a risky change and delete afterwards. Managed backups run on a schedule without anybody remembering. Use both: a snapshot immediately before a release, and a schedule for the rest of life.

The rollback you already have, and the one you think you have

WordPress has more built-in safety than most people realise, and less than they assume. Core auto-updates have attempted a rollback to the last stable release since WordPress 3.7. Version 6.3 added the same protection for manual plugin and theme updates: if the update process itself fails, the previously installed version is restored so the site stays available.

Read that carefully, because the gap matters. Those mechanisms protect you from an update that fails. They do nothing about an update that succeeds and then breaks your site, which is the far more common case: a plugin changes a hook, a theme function disappears, a payment gateway stops talking to its API. For that, your rollback is a snapshot, a copy of the old plugin version, or a database restore. Nothing is automatic about it.

So write the steps down, in a file, with the actual commands and the actual login location. Three lines is enough: how to restore the snapshot, how to reinstall the previous plugin version from your archive, and who to tell. Keep a copy of the old plugin zip before you update, because plugin directories do not always keep older releases available for download, and premium plugins frequently do not.

1. Take a snapshot. Note the time and the ID somewhere you will find it.
2. Keep a copy of the current plugin and theme files, zipped, with the version number in the filename.
3. Apply the update on staging first. Click through the three journeys that earn you money.
4. Apply it to production, then check the same three journeys again, logged out and on a phone.
5. If something is wrong and the fix is not obvious in five minutes, roll back first and diagnose afterwards.

A release you can run on a Tuesday morning

Here is the shape of a release that works for a team of one or two. Pick a morning early in the week, when you have hours of daylight left and your host’s support desk is staffed. Never Friday afternoon, for reasons that need no explanation. Refresh staging from production, apply the updates there, and walk the critical paths: load the home page, complete a contact form, add something to the basket and reach the payment step, and log into the admin.

Then snapshot production, apply the same updates in the same order, and repeat the walk. Check it on a phone as well as a laptop, because a layout break that only shows up at narrow widths is still a break, and more than half your visitors are probably on a handset. Our mobile-first design guide covers why that check belongs in the release rather than in a later review.

Finally, look at speed. Updates change asset loading more often than you would expect, and a new version of a page builder or a slider can add a render-blocking script that costs you half a second. Run one page through a field-data tool after each release and keep the number in a note; our article on why website speed matters explains which of those numbers are worth tracking and which are noise.

The cadence you are trying to keep up with

The reason this needs to be a habit rather than a project is the cadence you are up against. Look at WordPress’s own release archive for the middle of 2026: 7.0 arrived on 20 May, 7.1 on 19 August, and then 7.1.1 on 17 September followed by 7.1.2 on 22 September, five days apart. Security and maintenance releases come in pairs like that fairly often, and the archive notes that only the most recent release in the current branch is actively maintained.

The plugin side moves faster still. Patchstack’s State of WordPress Security in 2026 counted 11,334 new vulnerabilities across the WordPress ecosystem during 2025, a 42% increase on the previous year, with 91% of them in plugins and only six in core. The same research put the weighted median time to mass exploitation for heavily targeted vulnerabilities at five hours, and found 46% of vulnerabilities had no fix available from the developer at the moment of public disclosure.

Those numbers argue for two things at once, and they pull in opposite directions. Update promptly, because a five-hour exploitation window means a monthly patch cycle is a bet. But do not update blindly, because nearly half of disclosures have no patch yet and a rushed update is itself a source of downtime. The resolution is a process fast enough to run weekly and safe enough that you are not frightened of it.

When to break your own rules

Two honest exceptions. A critical security patch for something publicly exploitable goes straight to production after a snapshot, with no staging step, because the risk of waiting beats the risk of breaking. And if your site genuinely has no transactions, no logins and three pages, a weekly backup and a snapshot before updates is a complete process; building a staging environment for it is a hobby rather than a precaution.

The sign you have outgrown this is specific: more than one person changes the site, or a change takes more than a morning to test. At that point you want version control for the theme, a deployment step that is a command rather than a file transfer, and a staging site that refreshes itself. That is a real project, and it is worth doing when the symptoms appear rather than before.

Eudora Technology sets up staging, off-server backups and documented rollbacks remotely for clients across Europe, the Middle East, Asia, Africa and the Americas, and runs the monthly releases for teams who would rather not. Our web development and hosting page describes what that includes, and the handover notes mean you can take it back whenever you want to.

If your last backup is of unknown age and nobody is sure what happens when a plugin update goes wrong, we can set up staging, off-server backups and a written rollback and prove all three work. Get in touch with Eudora Technology to talk about your project.