Every implementation ends with a cutover: the moment the business stops running on the old system and starts running on the new one. It is a small window of time carrying the weight of the whole project, and it goes well when it is rehearsed and sequenced rather than improvised. This playbook is the sequence.
Before the day: the readiness gate
Cutover should not begin unless the project is genuinely ready. In the days before, confirm the conditions: the data migration has been dry-run and validated, the users are trained, the new system has passed acceptance, the cutover steps have been rehearsed end to end, and the time they take is known. If these are not all true, the honest move is to move the date. A cutover begun on hope is the most expensive kind.
Step 1: Freeze the old system
Cutover starts by stopping change in the legacy system. From the freeze, no new transactions are entered in the old system. The freeze is what makes a clean data extract possible: without it, the migration is chasing a moving target. Communicate the freeze time clearly and in advance; everyone needs to know the old system is now read-only.
Step 2: Run the final data migration
Extract from the now-frozen legacy system and run the full migration into production Odoo. This is the rehearsed procedure from the data migration playbook, run for real. Because it was rehearsed, the duration is known and the steps are familiar. This is not the moment to discover anything.
Step 3: Validate against the gates
Before anyone is let onto the new system, validate the migrated data against predefined gates, the same checks used in the migration dry runs. Record counts. Financial totals tying to the legacy system. A hand-checked sample of records. The validation gates are defined in advance precisely so that, under cutover pressure, the pass or fail decision is mechanical rather than a judgment call made by tired people.
Step 4: The go/no-go decision
With validation complete, make an explicit go or no-go decision, with a named decision-maker. Go: the gates passed, the new system opens to users. No-go: a gate failed in a way that cannot be fixed inside the window, and the fallback is invoked. Making this an explicit, owned decision, rather than a thing that just drifts into "go", is what keeps a bad cutover from being discovered after users are already on the system.
Step 5: Hold the fallback ready
Until go is declared and confirmed, the old system remains intact and recoverable. The fallback is simple: if cutover fails, the freeze is lifted and the business continues on the legacy system while the problem is addressed. The fallback is not an admission of failure; it is what makes the go decision safe to make. Do not decommission the old system on cutover day. Decommission it weeks later, once the new system has proven itself in real use.
Step 6: Hypercare
Go-live is the start of the riskiest period, not the end of the project. For the first days, run hypercare: heightened support, the implementation team close at hand, fast response to whatever the first real use surfaces. The issues that only appear under real load and real users appear now, and a planned hypercare period is what catches them calmly.
The note for the file
A good cutover is undramatic: freeze, migrate, validate, decide, open. The drama is removed in advance, by rehearsal, by predefined gates, by a fallback that stays ready. Cutover day should feel like running a procedure you have run before, because, if the playbook was followed, it is.