# Rollback Explained: Can You Undo a Bad AI Release? > Can you undo a bad release of AI-built software? A plain guide to rollback: what it can reverse, where data changes make it hard, and what to ask first. Canonical: https://bridge-terminal.com/atlas/blog/rollback-undo-bad-ai-release-plain-guide/ Last updated: 2026-11-14 Published 14 November 2026 · Plain English · Explainer · 6 min read ## The short version - A rollback puts the previous version of the software back, and it is usually quick when the release only changed the program. - Rollback gets hard when a release also changed the database, because the old program may not understand data the new one wrote. - When you cannot go back safely, teams fix forward: they ship a prepared, corrected release instead of reversing the change. - Before any release, ask: what is the way back, is there a backup that has been proven by restoring it, and who decides to use it. - Undoing an AI agent's file edits while it works is a different thing from undoing a release to real users. If an AI-built release goes wrong, can you undo it? Often yes, but only if someone prepared the way back before the release went out. A rollback puts the previous version of the software back in place. It works well for changes to the program and works badly for changes to the data. This guide explains what a rollback is, why it is not a magic undo button, and what a non-technical owner should ask before approving a release. ## What is a rollback? A rollback means going back to the last version that worked. Think of a shop that rearranges its shelves overnight. If customers cannot find anything the next morning, staff move the shelves back to how they were. Nothing is lost, because the shelves hold the same goods either way. Software releases have the same idea. The team keeps the previous version, and if the new one misbehaves, they switch back. Martin Fowler describes one version of this on his page about [blue-green deployment](https://martinfowler.com/bliki/BlueGreenDeployment.html). You run two production environments (two copies of the live setup) that are kept as identical as possible. One serves users and the other sits idle. You release to the idle one, and if the new release fails, you point users back at the previous one. That is a fast, low-drama way back. It is the best case. ## Why rollback is harder than it sounds The shop analogy breaks down when a release changes the database. The database is where your software keeps its records: customers, orders, invoices, messages. Imagine the new release stores each customer's phone number in a new format, and it converts the old records as it goes. Now you roll back to the old program. The old program does not understand the new format. It may show blank fields, crash, or quietly save wrong data. Putting the old program back did not put the old data back. An engineering write-up on [safe rollbacks and forward fixes](https://oneuptime.com/blog/post/2026-08-06-database-compatible-rollbacks-forward-fixes/view) makes the same point. It splits "rolling back" into four operations that are not equivalent: - Sending users back to the previous version of the program. - Redeploying a known earlier build of the program. - Reversing a change to the database's structure. - Restoring the data from an earlier copy. The last one is the risky one. Restoring an earlier copy of the data can throw away legitimate work done after that copy was taken. Say customers placed 200 orders since the release: a restore to the pre-release copy could erase those 200 orders. The write-up also notes that reversing a change to the database's structure does not necessarily undo a conversion of the data already done. So when someone says "we can just roll back", ask which kind they mean. ## What do teams do when they cannot go back? They fix forward. Instead of reversing the change, they ship a corrected release on top of it. The same write-up says to use a forward fix when new writes or a change that cannot be reversed make the old behaviour unsafe. It adds that the fix should be a built, reviewable piece of work rather than a manual edit to the live system, and that the team should rehearse in a throwaway copy of the environment before they need it. Teams also reduce the problem by splitting risky changes into steps. Both Fowler's page and the write-up describe the same pattern: 1. First, change the database in a way that old and new versions of the program can both live with. Fowler notes this gives you a point to go back to. 2. Then release the new program. 3. Remove the old structures later, in a separate release, once things have settled. Done this way, there is a safe point to return to after each step. Removing old data structures is the step that cannot be undone, so it is kept until last. You do not need to run these steps yourself. You need to know they exist, so you can ask whether the plan keeps a way back open. ## Is a backup the same as a rollback? No. A backup is a saved copy of your data. A rollback is a way of going back to an earlier version of the program. You usually want both, because they cover different failures. A backup only helps if it works. A backup that has never been restored is a hope, not a safeguard. Ask whether anyone has restored the backup to a test copy and checked that the data is there. ## Is this the same as "undo" in the AI tool? It is not, and mixing them up causes trouble. Claude Code, the AI coding tool from Anthropic, has a feature called checkpoints. According to its [checkpointing documentation](https://code.claude.com/docs/en/checkpointing), it tracks the file edits the agent makes during a session, so you can rewind your code to an earlier point. That is useful while the agent is working. But the same page lists limits. A file that was only ever changed by commands run in the terminal, and never edited by the agent directly, is not tracked. Edits made by helper agents are usually not captured. Changes you make outside the session are normally not tracked either. And the page says checkpoints are for quick recovery within a session, not a replacement for version control, the permanent history of every change to your code. None of this touches your live database or the release your customers are using. An agent's undo is a drafting tool. A rollback is a release tool. Treat them as separate safety nets. ## What should you ask before approving a release? You do not need to read code to ask good questions. Try these: - **What is the way back?** The answer should be specific: "we return to version X, and it takes about N minutes", not "we can fix it if needed". - **Does this release change the database?** If yes, rollback is harder, and the next questions matter more. - **Is there a backup, and has it been restored somewhere to prove it works?** - **Was the database change rehearsed on a copy first?** A rehearsal finds problems when they cost nothing. - **What would we do if it fails at 6pm on a Friday?** Who decides, and who acts? - **How will we know it is working?** Someone should check after the release, not assume. Notice that the last question belongs after the release. A way back is only useful if you notice early that you need it. ## How Atlas handles this Atlas is a team of AI engineers built on Claude Code. For releases beyond the Mac, it follows eight steps: the way back is marked, data is backed up and the backup is proven by restoring it, database changes are rehearsed on that copy, then the release goes out and is checked. Atlas never decides a production go-live for you; that stays your call. Atlas does not describe a one-step "go back" button today. A guided rollback that picks the right kind of way back for each release is coming to Atlas, built in, so it needs no setup. Until then, use the questions above with whoever releases your software, and check that the marked way back and the proven backup exist before you approve. You can read more on the [Atlas home page](https://bridge-terminal.com/atlas/). ## Conclusion Rollback is a good safety net, but it is not a promise that anything can be undone. Program changes are usually easy to reverse. Data changes are not, and that is where owners should focus their questions. Before you approve a release, get a clear answer to three things: what the way back is, whether the backup has been proven to restore, and who decides to use it. If the answers are vague, delay the release. A day of waiting costs far less than a night of lost orders. ## Questions people ask ### What does rollback mean in software? A rollback means putting the previous working version of the software back after a new release causes problems. It is usually quick when only the program changed, and harder when the database changed too. ### Can you roll back a database change? Sometimes, but it is riskier than rolling back the program. Restoring an earlier copy of the data can erase legitimate work done since that copy, so teams often prefer to ship a prepared, corrected release instead. ### What is the difference between a rollback and a backup? A rollback returns the program to an earlier version. A backup is a saved copy of your data. You usually want both, and the backup should be proven by restoring it to a test copy. ### What does fix forward mean? Fixing forward means shipping a corrected release on top of the faulty one instead of reversing it. Teams do this when new data or an irreversible change makes the old version unsafe to return to. ### Does Claude Code's rewind undo a bad release? No. Rewind restores files the agent edited during a session. It does not change your live database or a release customers are already using, and Anthropic's documentation says checkpoints are not a replacement for version control. ## About Atlas: A marked way back in every release Atlas releases beyond the Mac follow eight steps: the way back marked, data backed up and the backup proven by restoring it, database changes rehearsed on that copy, then released and checked. A guided one-step rollback is coming to Atlas, built in, with no setup. Production go-lives always wait for you. — https://bridge-terminal.com/atlas/ ## Sources - [Martin Fowler: Blue Green Deployment](https://martinfowler.com/bliki/BlueGreenDeployment.html) - [Can You Safely Roll Back a Database Change? (OneUptime)](https://oneuptime.com/blog/post/2026-08-06-database-compatible-rollbacks-forward-fixes/view) - [Checkpointing - Claude Code Docs](https://code.claude.com/docs/en/checkpointing) _Researched and drafted with Claude, then checked against the sources above. Atlas is an independent product, not affiliated with Anthropic or OpenAI._ ## Related - [Database Backups Before an AI Release: What to Ask](https://bridge-terminal.com/atlas/blog/database-backups-before-ai-release-what-to-ask/) - [What Is a Staging Environment? A Plain Guide for Founders](https://bridge-terminal.com/atlas/blog/what-is-staging-environment-plain-guide/) - [How AI-Built Software Gets Released: A Plain Guide](https://bridge-terminal.com/atlas/blog/how-ai-built-software-gets-released-plain-guide/)