Go-live readiness and the first close

Go-live is not a switch. It is a planned sequence with a named owner for every step, agreed weeks in advance, and it should be boring.

Choosing the date

Pick it for your business calendar, not the project’s.

• Go live at a period start. Mid-month cut-over means splitting a period across two systems, and your accountant will pay for that for years.
• Avoid your busy season. Whatever it is — Ramadan, quarter end, the annual audit, peak shipping.
• Avoid the day before a holiday. Problems appear on day two, and you want people at their desks.
• Leave a freeze window. Two weeks before go-live, nothing new is built. Only defect fixes. Every project is tempted to break this rule and every project that does regrets it.

The go / no-go decision

Hold a meeting a week before, with a written decision. The sponsor decides, not the project manager and not the partner.

GO / NO-GO ............................. date ......

  UAT exit criteria met ................ yes / no
  Critical and High defects ............ zero open / accepted in writing
  Parallel run closed and reconciled ... yes / no
  Opening balances agreed by accountant  yes / no
  All roles trained .................... yes / no
  Cut-over plan with named owners ...... yes / no
  Rollback plan tested ................. yes / no
  Support cover arranged for week one .. yes / no
  Old system read-only plan ............ yes / no

  DECISION ........ go / no-go / go with named exceptions
  Signed .......... sponsor, date

“Go with exceptions” is legitimate and common. What is not legitimate is going live with exceptions nobody wrote down.

The cut-over sequence

Write the plan as a table with a row per step: what, who, when it starts, how long, and how you know it worked. On the day, that table is the only document anyone should need.

What has to move across at cut-over:

• Opening balances per account, agreed with your accountant
• Stock quantities and values per location, from a physical count
• Open customer invoices and vendor bills, individually — not as one total
• Open sales orders and purchase orders not yet delivered
• Master data: customers, suppliers, products, prices, employees
• The last document numbers, so numbering continues rather than restarts

Reconcile before anyone logs in

The verification step is the one under time pressure, and the one never to shorten. Before users are allowed in:

• Trial balance in the new system equals the closing trial balance of the old one.
• Total stock value matches the counted value, per location.
• Customer and supplier open balances match, per partner, not just in total.
• The sum of open orders looks right.

If these do not agree, you do not open the doors. Going live on wrong opening balances means every report is wrong until someone finds it, usually at the audit.

The rollback

Write it down, and make sure it has actually been tried:

• What is the point of no return, and who declares it?
• How does the old system come back to writeable?
• What happens to transactions entered in the new system before rollback?
• Who tells the staff, and how?

You will almost certainly not use it. It exists so that the decision to continue is a real decision and not a trap.

Week one

Expect the first week to be slow and noisy. That is normal, and it is not evidence of failure.

• Have the partner on site, or at minimum instantly reachable, for the first three days.
• Put a super-user in each department — someone trained early who answers the easy questions so the partner handles the hard ones.
• Log everything, even the trivial. The pattern of questions in week one tells you exactly where training was weak.
• Do not add anything. No new requirements for a month. The system needs to stabilise before it changes again.

Before — on paper 6 steps

1. Closing takes three weeks, every month, forever.
2. The stock figure comes from a count somebody did when they had time.
3. Half the entries are typed by hand from other systems.
4. Every month the trial balance is chased for a difference somebody transposed.
5. The auditor asks for a report that has to be built from scratch each year.
6. Management sees last month's numbers when this month is nearly over.

Two weeks of qualified finance time every month, spent rebuilding what already happened.

After — in Odoo 4 steps

1. Most entries are already there, posted by the operations that created them.
2. Stock value in the ledger matches the warehouse, because one movement made both.
3. The bank is reconciled against invoices that already exist in the system.
4. The close is a review and an approval, and the figures go to management in the first week.

Decisions get made on figures that are current, and the audit stops being an annual crisis.

The first close

Go-live is not finished until you have closed one full period in the new system. That is when the real problems appear: a tax that posts to the wrong account, a stock valuation that does not match, a report the auditor wants in a shape nobody built.

Plan for it. Keep the partner engaged, contractually, through that first close — this is precisely what the retention payment is for. Book time from your accountant. Expect adjustments.

When the first close reconciles and the auditor is satisfied, the project is done. Not before, whatever the go-live date said.