How to Prepare Your Team Before an Odoo Go-Live

The day an Odoo go-live goes badly, it almost never goes badly because the software broke. It goes badly because the warehouse staff did not know which button to press, the salesperson took a phone order and wrote it on paper because she did not want to look slow in front of a customer, and the accountant decided to “just check the old system” and ended up running both systems for a month.

The software was ready. The team was not. That gap is closeable, but only if you start closing it before the launch date, not after.

Here is a four-week pre-go-live preparation plan that has worked across the Indonesian SME projects we have run. The specifics shift by industry, but the shape holds.

Week minus 4: identify your power users and your skeptics

Every department needs two people: a power user and a skeptic. Pick them now.

The power user is the person who will become the internal expert. They join testing earlier than everyone else, they sit with the consultant for extra walkthroughs, they end up being the person colleagues ask when they get stuck. This is not necessarily the most senior person. It is often a mid-level staff member who is curious about systems and gets things done. The owner of a Bandung textile distributor we worked with picked her warehouse coordinator — a 28-year-old who had never used an ERP — over her warehouse manager who had used three. She was right. The coordinator picked Odoo up in two weeks and trained everyone else.

The skeptic is the person most likely to resist the change. Not the loudest complainer — the quiet one who has been doing the job a certain way for fifteen years and has no intention of changing. Bring them in early. Ask them to find things that will not work in the new system. Take their objections seriously. Most of them will be answered by training. The ones that are not are usually real workflow gaps that need to be addressed before launch. Skeptics who feel heard become accepters. Skeptics who feel steamrolled become saboteurs.

Week minus 3: training, in the right format

Most consultants run training as a four-hour classroom session per department. People retain almost none of it. The right format depends on the role.

For transactional roles — cashiers, warehouse staff, sales admin — train hands-on inside the actual sandbox with realistic scenarios. “Customer Ibu Sari from Toko Mawar walks in and buys five items, pays half in cash and half by GoPay, then asks for a return on one item from yesterday’s purchase.” Run that scenario. Make them do it themselves. Repeat with variations until it is muscle memory. A 90-minute hands-on session beats a four-hour classroom session every time.

For decision-making roles — managers approving purchases, finance reviewing reports — train on the workflow logic, not the buttons. They need to understand what the system does in their name when they click approve, not just where the approve button is. A 90-minute walkthrough of an end-to-end purchase order flow from request through approval through receipt through bill payment teaches the manager why each step exists, which matters when they need to make exceptions later.

For executives — owners, directors — train on the reports and dashboards, not the modules. They will rarely enter data. They will look at numbers daily. Make sure the numbers they will look at are configured, labelled clearly, and located where they will look for them.

Week minus 2: parallel running, with a deadline

This is where most projects either get it right or get it wrong.

Running parallel — the team uses the old system and Odoo at the same time, comparing outputs — is the standard recommendation. The reason it usually fails is nobody sets an end date. The team uses both for two weeks, then a month, then three months, and the old system becomes the real source of truth while Odoo becomes the side project. The data in Odoo gradually rots because nobody is committed to it.

The fix is brutally simple. Set a hard parallel-run end date before parallel running starts. Two weeks, not “until we are comfortable.” During those two weeks, every transaction goes into both systems and the consultant reconciles outputs. Day 14, the old system is read-only. Day 21, the old system is archived.

This forces the team to surface problems in week one of parallel running, not month three when escape velocity is gone.

Week minus 1: dress rehearsal

The week before go-live, run a full day where the team uses only Odoo, with the old system off-limits. The consultant sits in the room. Every issue that surfaces gets logged and triaged. If a critical issue surfaces, slip the go-live by a week. Going live with known critical issues is worse than slipping.

This dress rehearsal also exposes process gaps that no amount of training catches. The cashier who has run POS five times in training but has never had to handle a return for a payment method that was originally split between cash and OVO. The warehouse staff who has done transfers in training but never had to handle a transfer where the count comes up two units short. These are the situations that break confidence on day one of go-live. Surfacing them on dress rehearsal day means you fix them in the calm before launch.

Day zero: who is in the room

The morning of go-live, key people are physically present. The owner or sponsor. The consultant or partner. The power user for each department. The skeptic — let them watch. The IT person. A WhatsApp group for fast issue triage. A whiteboard for tracking open issues and ownership.

The team needs to see leadership treating launch day as the priority, not as a normal day with go-live happening in the background. Owners who answer phone calls and take meetings during go-live send a clear signal that this is not actually important. Owners who clear their calendar and stand on the floor send the opposite signal. Both work.

What no training fixes

One pattern worth naming. Some staff will not engage with Odoo no matter how much training you provide, because they personally do not want to change. This is rare but real. Identify them by week minus 2. The conversation that needs to happen — about whether they will adapt or whether the role changes — needs to happen before go-live, not after the launch goes badly. This is the uncomfortable part of digital transformation that nobody puts in proposals, but it is real.

The goal of all this preparation is not perfect launch day. Launch day will have issues. The goal is a team that knows what to do when issues happen and trusts that someone is there to help. A team in that state recovers from a rough launch week and ends up loving the system within a month. A team that was not prepared blames the software forever.

If you are heading toward a go-live and want a second pair of eyes on your readiness plan, we walk through that on one-hour calls, free of charge. Specific, candid, no pitch.