This is the last part of the series. You have taken an inventory, set the scope, protected the addresses, reviewed on staging, rolled out template by template, tidied the legacy content and watched the fortnight after launch. One thing remains: deploying in a state you can reverse.
A rollback plan is not a sign of low confidence — quite the opposite. When you can go back, you can ship boldly. When you cannot, deployment becomes frightening, and frightened teams end up pushing one large under-verified lump all at once.
A rollback has two tracks
A WordPress deployment changes code (theme, plugins, configuration) and the database (content, options, meta). The two are reversed differently, and reversing them costs differently.
The second layer is the crux. Restoring the database as it was at deployment also removes every enquiry, order and post created since. Database rollback is therefore always the last resort, and before doing it you back up the current state first so the interim data can be recovered later.
What to prepare before deploying
Rollback preparation is part of the deployment plan, not five minutes before it. Five things.
That last line matters most. Deploy without a threshold and the decision gets made on feelings. Write it down instead: “if the conversion form does not deliver, revert immediately”; “if 404s keep climbing on one template, revert that template only”; “ranking movement gets two weeks of observation”. Those sentences remove the argument on launch night.
The order to reverse in
A rollback is the deployment run backwards. Get the order wrong and you either revert and see no change, or leave new code reading old data, which is stranger still.
① Back up the current state first. Keeping today’s database and uploads is what lets you recover the enquiries that arrived in the meantime.
② Restore the previous code. Most problems end here, because layout, screens and assets all live on the code side.
③ Purge every cache — the server page cache, the object cache, and any CDN in front. Skip this and visitors keep seeing the new design after you reverted, which is regularly misdiagnosed as “the rollback did not work”.
④ Verify the addresses still resolve. If URLs moved, the redirect rules have to move back too — and if the new addresses were shared in the meantime, you need the reverse rules for a while.
Only restore the database when those four steps do not resolve it — typically when content structure or options changed such that the old code cannot read the new data. Even then, it is the backup from step one that lets you recover what arrived in between.
Choosing not to revert everything
A gradual rollout gives you one more option: revert only the template that misbehaved. The others are running fine, so there is no reason to take them with it, and the cause is inside that one template anyway. This is where rolling out template by template earns its keep.
Sometimes fixing forward is better. When the cause is clear and the fix is short, reverting costs more than it saves. The deciding question is simply whether you are confident about how long the fix will take — if you are not, revert and fix it on staging.
Closing the series
Redesigning a live site is harder than building a new one, because there is something to protect. That is a good problem to have: a site with no traffic and no conversions has nothing to lose whatever you change.
Eight parts come down to one idea. Make a list, change one thing at a time, and keep a way back. WordPress supports that working style unusually well — content is kept separate from the theme, addresses are yours to control, and code and data can be backed up independently.
Work that pairs naturally with a redesign — upgrades, performance, a security review — can be handled as one job through our optimization program, and the order we work in, with the evidence we keep, is published on the process page. If a redesign is on your roadmap, get in touch and we will start by assessing where the site stands today.