Odoo ERP Go-Live Checklist for Zimbabwe Enterprises

Your finance team has closed the month in the legacy system, inventory is ready for verification and the project manager asks whether Odoo ERP can go live. The answer should not depend on whether the software looks finished. It should depend on whether the enterprise can transact accurately, protect approvals, serve customers and recover from an interruption.

For Zimbabwean enterprises, an Odoo go-live decision is a business acceptance decision. Finance, Operations, IT and executive management need documented proof that the system works under realistic conditions. A completed import, a successful demonstration or high training attendance is not sufficient evidence on its own.

What an ERP go-live checklist must prove

Every readiness item should have a named accountable owner, a clear acceptance criterion, dated evidence and a recorded decision. Test complete business processes, not isolated screens: an order must move through fulfilment, invoicing, payment and reconciliation with the right approvals and reports.

| Readiness area | What must be proved | Evidence for sign-off | | End-to-end processes | Core transactions work from beginning to end | Completed test scripts, actual results, defect log and process-owner approval | | Migrated data | Opening balances and operational records are accurate | Signed reconciliations, exception register and data-owner approval | | People and roles | Users can complete their assigned work | Practical role tests and evidence of resolved training gaps | | Financial and operational controls | Access, approvals and audit controls work as designed | Role-based tests, posting checks and documented review | | Continuity and recovery | The business can pause, recover or use controlled workarounds | Verified backup, restore exercise, cutover and communications plan |   At minimum, test order to cash, procure to pay, receiving and delivery, returns, approvals and accounting close. Where a group operates several entities, test differences in tax settings, journals, authorisation limits and reporting for each relevant entity.

Agree the acceptance standards before testing

Clear go/no-go rules protect decision-makers from pressure to ignore an unresolved defect during cutover. The standards below are SERPA-recommended governance controls, not universal Odoo software thresholds.

•  Complete all agreed critical business scenarios, with signed results showing the expected and actual outcomes.

•  Do not proceed with unresolved Severity 1 defects or another failure that prevents a critical transaction or control.

•  Resolve material opening-balance discrepancies and obtain formal approval for any genuinely acceptable, immaterial exception.

•  Test every assigned go-live role through practical tasks using realistic access permissions, rather than relying on attendance records.

•  Give every accepted lower-severity defect an owner, mitigation, due date and business approval before go-live.

Treat these rules as acceptance gates. A dashboard marked “complete” is not a substitute for working evidence and authorised sign-off. The business should also define its own tolerances for stock variances, service continuity and incident response based on its risk profile.

Reconcile migrated data before signing acceptance

Data migration succeeds when the organisation can rely on its records, not merely when imported row counts match. Finance should validate the chart of accounts, journals, tax settings, customer and supplier balances, inventory records and document sequences against the approved closing position in the legacy system.

The signed finance acceptance pack should demonstrate:

•  A balanced opening trial balance, tied to the agreed closing accounts and approved adjustments.

•  Receivables and payables that agree to the supporting customer and supplier sub-ledgers, including invoices, credit notes, payments and other valid adjustments.

•  Inventory quantities and valuation reconciled using the organisation’s configured costing and accounting methods.

•  Clearing, suspense and migration accounts investigated and cleared or supported by authorised exception records.

•  An extract date, preparer, independent reviewer, exception owner and business sign-off for each material reconciliation.

Consider a Zimbabwean distributor that discovers inconsistent inventory values after importing stock from separate warehouse files. Rather than approving the migration because the records appear complete, the finance and operations owners should trace the affected products, quantities, costing method and postings. Correcting the underlying cause before production protects margins, customer fulfilment and management reporting.

A business with limited transactions may need a smaller reconciliation pack than a high-volume manufacturer. The evidence standard remains the same: balances and records must support the work that will begin at go-live.

Test the controls using real business roles

An invoice that posts successfully has not passed a control test if the wrong employee can authorise payment. Run final tests with production-like user permissions, not unrestricted project-administrator credentials.

Check role-based access, segregation of duties, purchasing and payment approvals, credit notes, accounting lock dates, document sequencing, tax configuration and audit evidence. Confirm that staff can complete necessary exception handling without bypassing policy.

For example, a retail accounts clerk may need to capture a supplier bill while payment approval belongs to a finance manager or another authorised official. If an inherited administrator role allows the clerk to approve the payment, remove that access and repeat the test. Evidence should record the user role, expected restriction, actual result and retest outcome.

Make cutover and recovery a signed plan

A backup is not a recovery strategy until it has been restored and checked. Before cutover, agree who can pause the move, which incidents trigger rollback or a controlled workaround, and how staff will communicate with customers and suppliers if service is interrupted.

| Cutover control | Decision or evidence required | | Executive decision owner | Named authority to proceed, pause or cancel cutover | | Rollback and stop conditions | Trigger, feasibility, recovery steps and ownership | | Verified backup | Date, owner, scope and secure storage confirmation | | Restore test | Successful restore result and validated data checks | | Manual workarounds | Controlled capture of orders, deliveries, receipts and approvals | | Communication plan | Contacts for staff, executives, customers and implementation support | | Initial support cover | Named escalation owners and agreed incident-response expectations |   If the organisation temporarily operates the legacy system alongside Odoo, define exactly which system owns each transaction and how entries will be reconciled. Uncontrolled parallel processing can create duplicate invoices, stock movements and unclear balances. For complex deployments, rollback feasibility must be checked before promising that a live cutover can simply be reversed.

Check Zimbabwe-specific operational readiness

Confirm that local tax and statutory reporting settings have been reviewed by the finance and compliance teams, including relevant ZIMRA registration details and the treatment of applicable taxes. Where the business works in more than one currency, test currency setup, exchange-rate handling, reconciliation and reporting using realistic transactions.

Check that the business can reproduce the source documents, approvals and audit trail needed to support financial records. The exact controls depend on the modules, industry, applicable law and business model; tax localisation should be validated against current requirements rather than assumed to work because an imported invoice posts successfully.

Why a disciplined go-live protects business value

The benefits extend beyond a cleaner launch. Verified balances give managers credible reports from the first operating period. Tested roles reduce payment and stock-control exposure. Practical user testing shortens avoidable disruption, while a rehearsed response plan protects customer service and business continuity.

Most importantly, documented acceptance gives executives a defensible basis for the decision. It shows what was tested, what remains open, who accepted the risk and what support will be available after launch. This is more valuable than a ceremonial “system live” announcement.

Record a clear go / conditional go / no-go decision

At the decision meeting, Finance should sign reconciliations and close controls; Operations should approve fulfilment and inventory processes; IT should confirm access, backups and recovery; and the executive sponsor should record the final cutover decision. The implementation partner can prepare supporting evidence but should not be the sole approver of the business’s readiness.

•  GO: All critical scenarios and controls pass, material differences are resolved and the cutover and support arrangements are approved.

•  CONDITIONAL GO: Only formally accepted lower-risk issues remain, with effective workarounds, accountable owners and clear deadlines.

•  NO-GO: A critical process, financial reconciliation, access control or recovery requirement remains unsafe or unproved.

Frequently asked questions

Who should sign the ERP go-live checklist?

The accountable business owners should approve their domains: Finance for balances and reporting, Operations for inventory and fulfilment, IT for access and recovery, and an executive sponsor for the final decision. Each approval should be supported by evidence.

Is completing user training enough to approve go-live?

No. Training attendance shows participation. Practical tests show whether employees can perform their assigned tasks, manage exceptions and use the correct approval paths in the live operating model.

What is the most important migration check?

No single number is sufficient. Trial balances, receivables, payables, inventory records and relevant clearing accounts must reconcile, and business owners must approve the resulting data and documented exceptions.

Can lower-severity defects remain open at go-live?

Yes, where the business has assessed and accepted the risk, named a responsible owner and deadline, and confirmed that the defect does not undermine a critical process, financial control or continuity requirement.

Move to Odoo with evidence, not assumptions

SERPA Africa helps enterprises turn configuration, migration, control testing and cutover evidence into a board-ready ERP acceptance pack. Book an ERP Readiness Audit to identify gaps before launch and enquire for a tailored Odoo implementation or support proposal.

Editorial note: Confirm current Odoo product behaviour, configured modules and applicable Zimbabwean tax or reporting requirements before publication and client implementation.