Going live after your Odoo upgrade: the data gap, explained

Here's the question sharp customers always ask: "While you're upgrading, we're still using our old system every day. What happens to everything we enter during that time?" This guide answers it honestly — including the option most upgrade quotes never mention.

Your live system never stops. We work on a copy.

An upgrade with us starts from a backup of your database. Your real, live Odoo — the one your team uses every day — keeps running the old version, completely untouched, for the entire project. We never connect to it, never modify it, never ask for its passwords.

That's deliberate. It means the upgrade carries zero risk to your daily operations: if anything went wrong on our side, your business wouldn't notice. You keep invoicing, shipping, and buying exactly as before while we work.

But that opens a gap

The copy we upgrade is frozen at the moment your backup was taken. Meanwhile, real life continues in the old system: new sales orders, new purchase orders, new invoices, deliveries going out, stock arriving. None of that exists in the upgraded copy — it can't, because it happened after the backup.

By the time you've tested the upgraded copy and you're ready to switch, there's a gap of days or weeks between what's in it and what's really happened in your business. Before you can go live, that gap has to be closed. There are two honest ways to do it.

Option 1: Catch up by hand

The straightforward way. You go live on the upgraded system we delivered, and your team re-enters what happened during the gap: the sales orders, purchase orders, and invoices created in the old system since the backup was taken. Because stock moved in the meantime too, you finish with an inventory count — Odoo's built-in stock adjustment — so the new system's stock matches the shelves.

This works fine when the gap is small: a quiet system, a handful of documents a day, a short project. Many businesses do exactly this over a weekend and are done by Monday.

But we won't pretend it's free. If your business creates dozens of documents a day and the project ran three weeks, that's hundreds of entries to redo by hand — real hours, and every manual re-entry is a chance for a typo. For busy systems, there's a better way.

Option 2: A scheduled final run (the smart way for busy systems)

Here's the thing about the upgrade work that makes this possible. It splits into two parts:

Your custom modules. Bringing these to the new version is done once. Finished code doesn't care which backup it runs against — once your addons work on the new version, they're done forever.
Your database. Moving it forward isn't hand-work we'd have to redo from scratch — during the first upgrade we build a set of migration steps tailored to your exact system, and those steps are repeatable. They can be run again, on a fresher backup, in a fraction of the original time.

So once you've tested the first upgraded copy and confirmed everything works, we can schedule a final run:

Pick a date together — typically a Friday evening or a weekend, whenever your business is quietest.
Take a fresh backup. Your team stops entering data for the cutover window, and you (or your IT person) take a new backup — same button as before.
We re-run the migration. The same proven steps from the first round run against the fresh backup. Your modules don't need touching — they're already done. This takes hours, not weeks, because everything was solved the first time.
We verify the numbers again. You get the same verification report as before — row counts, financial totals, stock on hand, invoice numbers — compared against the fresh backup.
You go live. On a database that's hours old, not weeks old. The catch-up is a morning's worth of orders at most, often nothing at all.

Why the second run is fast and safe

The first upgrade is where every surprise gets found and solved — that's the part that takes time. The final run just replays those solutions against newer data. Nothing is being figured out on cutover night; it was all figured out, tested, and verified by you weeks earlier.

Which should you pick?

Catch up by hand if your system is quiet — a few documents a day — or the project is short. Simplest, no scheduling needed.
Scheduled final run if your system is busy, stock accuracy matters (warehouse, manufacturing, retail), or re-entering weeks of documents sounds like a nightmare. This is the right call for most companies with daily order flow.

One honest note either way: if your warehouse is busy, a quick stock count after go-live is good practice even with a scheduled final run — but the adjustments should be minimal, because the data is only hours behind reality.

What it costs

If you want the scheduled final run, tell us when you ask for your quote — we price it alongside the upgrade itself, so you see both numbers upfront, fixed, before you commit to anything. No surprise line items at cutover time.

The timeline, end to end

You send a backup and your custom modules. Your live system keeps running.
We upgrade the copy, you test it, the numbers check out, you pay. Your live system is still running the old version, untouched.
Either you go live on the delivered copy and re-enter the gap by hand, or we schedule a final run: fresh backup in the evening, upgraded and verified database back, go live with hours of gap instead of weeks.

Either way, the switch itself — pointing your server at the new database and code — is done by whoever runs your system today, with plain go-live instructions from us written for them. Nothing about your day-to-day support changes.