Odoo Migration Rollback Planning: Deciding Before You Need To

Rollback is a plan, not a capability

"We have backups" is not a rollback plan. It is a precondition for one.

A plan answers three questions, and if any is unanswered you do not have it:

• Who can authorise going back, and are they reachable during the cutover?
• What would trigger it, stated specifically enough that two people would agree it had happened?
• When does it stop being an option?

The third is the one people get wrong.

The window is shorter than you think

Restoring the old database means discarding everything entered since the cutover. So the rollback window is not bounded by technical capability, it is bounded by how much real work has accumulated.

Once the warehouse has shipped a day's orders and finance has posted a day's invoices in the new version, going back means losing that day and re-entering it from paper. In practice that means the decision window is hours, and it closes as soon as users are let in.

This has a design consequence: your go-live checks have to be fast and specific. Exploratory testing on go-live night burns the window it is supposed to protect. The checks should be the same reconciliation you rehearsed, run in the same order, producing a yes or a no in under an hour.

Freeze the data, and mean it

An upgrade running against a live database produces a result that corresponds to no consistent point in time. Records written mid-conversion may or may not be present, and you will not be able to tell which.

So the cutover needs a freeze: a stated window in which nobody writes to the old system. Announce it well in advance, name the exact times, and make sure the people who work outside office hours know, because the warehouse night shift and the overseas office are the two groups who reliably do not get the message.

Then verify the freeze rather than trusting it. A quick count of records created in the last hour tells you whether it held.

Decide the triggers in advance

At 3am, under pressure, with everyone tired, "is this bad enough to roll back" is an argument. Written down a week earlier it is a decision.

Useful triggers are specific and observable:

• A core process cannot be completed at all. Not slow, not ugly. Cannot complete.
• The reconciliation checks do not match and the cause is not understood.
• The cutover has passed its agreed end time with steps outstanding.

That last one matters more than people expect. Overrun is the most common real trigger, and it is the easiest to rationalise away in the moment, which is exactly why it belongs on a list somebody agreed to in daylight.

Rehearse the restore, not just the upgrade

Teams rehearse the upgrade and assume the restore. Then on the night they discover the restore takes four hours, or needs a credential nobody has, or that the filestore was not included in the backup and every attachment is gone.

Time a full restore during testing. It is part of the go-live duration whether or not you measure it, and knowing the number is what lets you set an honest deadline instead of an optimistic one.

What happens after the window closes

Once rollback is off the table, the plan changes shape: you are now fixing forward, and the useful preparation is different. Know who is on call, know how to reach whoever built your custom modules, and have a way to communicate to users that something is known and being worked on.

Most upgrades never use the rollback plan. That is not evidence it was unnecessary. It is what a plan that worked looks like, and the same is true of the testing that made the rollback unnecessary in the first place.