Every ERP project gets judged on about 72 hours. Months of configuration, testing, and training all collapse into a single weekend where the old system stops being the truth and the new one starts. Handle that handoff well and the team barely notices. Handle it badly and you spend the next quarter explaining why nobody can invoice.
The uncomfortable part is that cutover is rarely a technology problem. The software works. What breaks is sequencing: who stops entering orders and when, which balances got loaded, whether the warehouse can ship on Monday without calling accounting. Those are operator questions, and they need operator answers before the weekend starts.
Define the freeze, not just the date
"We go live October 1" is not a plan. A plan says: last invoice in the old system posts Thursday at 4pm; inventory counts are locked Friday morning; no new purchase orders after Wednesday; the sales team logs Friday's verbal commitments on paper and enters them Monday.
Write that as a schedule with names and times attached, and walk it through with each department lead. You will immediately find the conflicts — the customer who always places a big order on Friday afternoon, the payroll run that lands mid-freeze, the month-end close nobody wanted to move. Better to find them two weeks out than at 9pm on cutover Saturday.
One rule that saves enormous pain: pick a cutover date that is not also a month-end, quarter-end, or peak season. The cost of waiting three weeks is almost always lower than the cost of doing your first close in a brand-new system while the warehouse is at capacity.
Move balances, not history
The instinct is to bring everything. Ten years of transactions, every closed order, every legacy note. It feels safer. In practice it multiplies the data-cleanup burden, slows validation, and imports errors you had already learned to work around.
What actually needs to be in the new system on day one is narrower than most teams expect:
- Open items: unpaid customer invoices, unpaid vendor bills, open sales and purchase orders, work in progress
- Trial balance as of the cutover date, so the general ledger ties out
- Current inventory quantities and valuations, counted as close to cutover as possible
- Active master data: customers, vendors, items, price lists, employees — cleaned, deduplicated, and owned by a named person
Historical detail can stay in the old system in read-only mode, or be archived into a reporting layer later. Give people a documented way to look things up and the appetite for full history usually disappears.
Rehearse it with a stopwatch
A mock cutover is the highest-value week in any ERP implementation. You run the entire sequence on a copy of the system: extract, transform, load, validate, reconcile. You time each step. You write down every surprise.
The rehearsal answers questions you cannot guess at. How long does the inventory load actually take? Does the trial balance tie on the first try, or does someone need four hours to chase a rounding difference in foreign currency? Who has to be awake at 6am Sunday?
The output is a runbook — a numbered list of tasks with owners, durations, dependencies, and a clear checkpoint where you decide to proceed or stop. If you have not done the sequence at least once end to end, you do not have a plan. You have a hope.
Day one is about transacting, not reporting
Set expectations before the weekend: the first few days measure whether the business can operate, not whether every dashboard is perfect. Can we take an order, pick it, ship it, invoice it, receive a payment, pay a vendor, and run payroll? That is the bar.
Reports will look strange at first because comparative periods are empty and people are used to a different layout. That is expected and fixable. A blocked shipment is not. Keep the go/no-go criteria focused on transaction flow, and route report complaints into a queue for week three.
Staff hypercare like a shift, not a favor
The two weeks after go-live decide adoption. This is when workarounds get invented — the spreadsheet on the side, the manual override, the "just call me and I'll do it." Every one of those becomes permanent if nobody is there to answer the question properly in the moment.
So staff it deliberately. Floor support in the warehouse. Someone sitting with the AR clerk for the first close. A single intake channel for issues, triaged daily, with a visible list of what's fixed. Protect your power users' calendars — they are support staff for a fortnight, not their usual job plus support.
Also decide in advance what would trigger a rollback and who makes that call. Almost nobody uses it, but the conversation forces clarity about which failures are survivable and which are not.
The real measure of a good cutover
A successful go-live is boring. Orders flow, the ledger ties, and by week three people stop talking about the system and go back to talking about the business. That outcome comes from sequencing and rehearsal, not from heroics on Saturday night.
If you have an ERP go-live on the calendar — or a stalled implementation that needs a credible path to a date — we've run this playbook many times across Odoo and integrated systems. Reach out to Infraxio and we'll walk your cutover plan with you before it's the weekend.