The Odoo implementation checklist

Most implementation checklists are prose with bullet points in front of it. This one is meant to be worked. Print it, put a name against each line, and stop the project moving to the next section until the current one is ticked.

It follows the six phases we run: discovery, solution design, configuration and prototype, data migration, training and cutover, then hypercare. The full engagement structure sits on the implementation service page, and the calendar it maps onto is in the timeline, week by week.

Before you sign anything

A named decision maker per function, with authority to change a process rather than just describe it
A project owner on your side who can free those people up when the schedule needs them
A go-live date chosen against your operating calendar, avoiding your busiest weeks and your period close
Scope written as outcomes and gaps, not as a list of module names
Every gap carries a disposition and a cost: configure, customise, change the process, or leave out
A written change-request route for anything raised after sign-off
Out of scope stated in writing, including hardware, subscription fees and third-party licences
Agreement on which reports are conditions of go-live and which are phase two

Discovery: what you have to supply

An export of the legacy data, plus someone who can explain what the odd columns mean
The chart of accounts and the opening balances, signed off by whoever closes your books
Sample documents you want back out of the system: a quotation, an invoice, a purchase order, a delivery note
Credentials and a technical contact for every system that has to stay connected
Real user time for testing and training, blocked out in calendars in advance
The reporting pack the business is actually run on, including the spreadsheets

Discovery: what has to come out of it

A walkthrough per function in scope: sales, purchasing, warehouse, finance, HR
The exceptions recorded, not just the happy path
Every report someone actually reads, listed, with the name of who reads it
The numbers the business is managed by identified, because those decide the chart of accounts and the analytic structure
The physical operation walked, where there is one: the warehouse, the shop floor, the counter
The sceptic interviewed. The person who thinks the project is a mistake usually knows something the sponsor does not
A written process map, a numbered gap list, and the module list that follows from it

Solution design: the decisions to close

Big bang or phased, decided on the size of the business rather than on preference
How much history to bring. Masters and open items are not optional; full transactional history is a cost decision
Chart of accounts, numbering conventions and product coding scheme agreed, in that order
User roles and record-level access defined before any user is created
Integration boundary fixed: which system is master for customers, for stock, for prices
Owner named for the product file and the customer file after go-live
Each customisation defended on its merits rather than inherited from the old system
A signed scope where every gap has a disposition and a cost

Configuration and prototype

Company, warehouse, journal and pricing structure built
A representative slice of masters loaded: your awkward products, not your simple ones
Pilot transactions run end to end, from order through to the ledger entry
A weekly demo against the process map, with the gap list as the checklist
Custom work started only after the standard flow has been run by real users
Anything that loops over records or computes across a table checked at real volume, not on demo data
Access rights written with each custom model, not added at the end
A defect and change log that both sides can see

Data migration

Cleaning and de-duplication done in the extract, before loading, never after
Every legacy field mapped to a target field in writing, including the ones you decide to drop
Load run in dependency order: partners, products, then balances, then open documents
Control totals reconciled against the old system and signed off with whoever closes your books
A cut-off date agreed, and changes frozen in the legacy system from that point
A repeatable import that logs its errors, so a re-run is not a manual rebuild
Duplicate customers caught at creation rather than merged later

Local compliance, before the build not after it

Your e-invoicing model confirmed: clearance, reporting, post-audit, or nothing in force
If reporting: the accredited intermediary chosen, contracted, and given its own timeline
Every in-scope document type on the test plan, including credit notes, corrections and foreign currency
Master data profiled against the validation rules before the build, not after the first rejection
A named role with a daily routine for the rejection queue
Inbound supplier e-invoices in scope or explicitly out, because receiving is the half people forget
Archive designed to be portable and readable independently of the live database
Payroll confirmed as localized in the box for your market, or budgeted as a build
Requirements attributed to the adviser who confirmed them, in writing. Not to a software vendor

The per-market detail behind those lines is on the country pages, for example Saudi Arabia, UAE and India, and the model distinction is worked through in clearance or reporting.

Integrations

One direction per object, or two-way stated explicitly and deliberately
Master of record named per field, not per object
Matching key between systems decided, and the behaviour when it is missing
Separate test and live credentials, with a staging instance that cannot touch live data
Rate limits and pagination read and designed inside, not discovered in production
Idempotency on every inbound message, so a replay cannot double-post
Failures go to a queue with an owner and an alert, not to a log file
Refunds, cancellations, partial shipments and returns on the test plan explicitly
A scheduled reconciliation comparing counts and totals on both sides

Training and UAT

Training on your configured system with your data, not a generic instance
Short sessions per role, close to the work, rather than one long session for everybody
Returns, corrections and cancellations taught deliberately
Testing scripted, and run by the people who will use the system daily
The sceptics included in the test group
A short practical assessment per role, because attendance is not competence
Defects triaged into blockers, fix-before-go-live, and phase two
Material handed over in editable form with your internal owner named
A refresher session scheduled for after the first period close

Cutover

A written runbook with timings, owners and a marked rollback point
A full backup taken before anything starts, from a backup routine that has been restored at least once
Smoke test of the critical paths before users are let in
The legacy system readable but not writable for a defined period
Someone present on the floor on the first busy day, for a counter or warehouse operation
Redirects mapped, tested on staging and verified again straight after launch, for any web replatform

Go or no-go

Call it against these, not against the calendar.

UAT signed off by each functional area
Control totals reconciled and signed
No open blockers, and the fix-before-go-live list closed
Payroll, where in scope: two consecutive periods reconciling with no unexplained difference
Bank output tested with the bank, not only against its specification
Every integration retested after the final configuration freeze
The rollback point, the freeze time and the person who calls it are all written down
The date is not on a period close or in a peak trading week

The first thirty days

Daily triage, tapering as volume settles
Reports people actually opened tuned, and the ones nobody opened retired
Administrator handover covering users, access, backups and scheduled actions
Scheduled actions monitored on outcome, not just on whether the server is up
A restore drilled and its duration recorded, because that duration is your real recovery time
A written phase two backlog built from everything deferred during UAT
A decision on what happens when hypercare ends: a support agreement, or your team

Who owns what

Item	Owner
Every gap disposition and its cost	Your decision maker for that function
The legacy extract and what its columns mean	Your side, named person
Mapping, load and reconciliation	Implementation team
Chart of accounts sign-off	Whoever closes your books
The rejection or exception queue	A named role on your side, daily
Product file and customer file after go-live	Named at design time, not after
Backups, restores and scheduled actions	Your administrator, or a support agreement

FAQs

Can we use this checklist with another partner? Yes. Nothing on it is specific to us. If a vendor cannot tell you who owns each line, that is the finding.

What if we cannot tick something before the phase ends? Then the project is not in the next phase. Moving on with an open item does not save the time, it moves the cost to a worse week.

Which lines get skipped most often? The reconciliation sign-off, the assessment after training, and the restore drill. All three are dull, all three are the ones that hurt.

We are already live and skipped most of this. Where do we start? Backups restored, scheduled actions monitored, and an owner named for every exception queue. Those three stop the bleeding. After that, a read-only health audit will tell you what else is open, with a severity and an effort against each finding so it can be budgeted rather than filed.

How long should the discovery section take? Long enough to produce a numbered gap list with a cost against every line. On a single-module project that is days. On a multi-country programme it is the phase that decides whether the rest of the plan is real.