A realistic 90-day Odoo implementation plan, phase by phase

A 90-day Odoo implementation is realistic for a single company running core apps such as Sales, Purchase, Inventory and Accounting, with limited customisation and clean master data. It works in five phases: two weeks of analysis, about five weeks of configuration and build, three weeks of data loads and testing, a week of training, and two weeks for go-live and support. Projects take longer when scope grows, customisation is heavy, integrations are many, data is messy, or decisions wait on people.

The plan below is a template, not a promise. Use it to test whether your scope fits 90 days, and to see where your own team's time is needed.

The 90-day plan at a glance

Weeks 1–2: analysis and scope

The partner runs workshops with the people who do the work: sales, purchase, stores, accounts. Each process is written down in plain terms and matched to standard Odoo. Anything Odoo doesn't do as standard goes on a gap list, with a proposed answer: a configuration, a Studio change, a custom module, or a change to how you work.

Three decisions close this phase:

• Edition and hosting. Community or Enterprise, and Odoo Online, Odoo.sh or on-premise. Custom modules rule out Odoo Online. See hosting options.
• The gap list. Each gap is approved, deferred to a later phase, or dropped.
• The go-live date. Fixed now, with the cut-over approach agreed.

Also list every data source: Tally or another accounting system, spreadsheets, the existing billing software. Who owns each one, and how clean it is.

Weeks 3–7: configuration and build

Configuration starts with the base: company details, users and access rights, the localisation, chart of accounts, taxes and journals. Then each app in the order work flows: products and pricelists, sales, purchase, inventory routes and warehouses, invoicing and payments. The company and users guide and accounting setup guide cover the first steps.

Custom modules and integrations are built in parallel, against the approved gap list. Show each app to its key user as soon as it's configured, not at the end. A wrong assumption found in week 4 costs an hour. Found in week 10, it costs a test cycle.

Your team's main job in this phase is master data: customers and vendors with GSTINs and states, products with HSN codes, units and costs. It always takes longer than planned, so start it in week 3, not week 8.

Weeks 8–10: data loads and testing

Load the masters and a trial set of opening balances into a test copy of the database. Check that figures tie: open invoices to the debtors balance, stock value to the inventory ledger, the trial balance to the old system. For Tally users, our Tally migration guide sets out the order.

Then test end to end with real scenarios written in your own terms:

• Quote, confirm, deliver, invoice an interstate customer, receive payment.
• Purchase, receive partially, post the vendor bill, pay with TDS.
• Return goods, raise a credit note, check the GST effect.
• Close a month and compare the reports with what your accountant expects.

Log every issue, fix it, and re-test. Do at least two full data-load rehearsals before go-live, so the final load is routine.

Week 11: training and cut-over rehearsal

Train key users first, in the processes they tested, then let them train their teams. Training works best on a copy of your own data, not a demo database. Users should practise the tasks they'll do on day one.

Write the cut-over plan as a checklist with times and owners: when the old system stops taking entries, when final balances are exported, who loads them, who checks them, and the point at which you decide to go or wait.

Weeks 12–13: go-live and hypercare

Freeze the old system, load final balances, check them, and start working in Odoo. The first two weeks are hypercare: the partner is on call, issues are fixed the same day where possible, and key users sit with their teams. Run the first month-end close and the first GST return from Odoo with your accountant checking the figures.

What makes an Odoo implementation take longer than 90 days

• More scope. Manufacturing, multiple companies, multiple warehouses, Point of Sale across stores, HR and payroll. Each adds configuration, testing and training. Consider phasing: core operations first, the rest in a second wave.
• Heavy customisation. Each custom module has to be specified, built, tested and fixed. A long gap list is the most common reason a plan grows.
• Integrations. Marketplaces, payment gateways, logistics, banks and legacy systems each depend on another party's API and timetable.
• Messy data. Duplicate customers, products without HSN codes, stock that doesn't match the books. Cleaning it is your team's work, and it can't be rushed at the end.
• Slow decisions. When a gap waits two weeks for an answer, the plan slips two weeks. Name one person who can decide.
• Key users without time. If the people who know the processes are also running daily operations, testing waits. Free up their time in the plan, not as a favour.
• Scope added mid-project. New requirements after week 2 should go to a change list for a later phase, unless they block go-live.

Most of these are covered in more depth in why Odoo implementations fail.

How to tell whether 90 days fits your project

1. Count apps. Four or five core apps fit. Ten apps in one go usually don't.
2. Count gaps. A handful of Studio changes and one or two small modules fit. Many custom modules don't.
3. Count integrations. None or one fits. Several need their own timeline.
4. Check data. If masters need weeks of cleaning, start that before the project.
5. Check people. One decision-maker and named key users with time set aside.

If two or more of these don't fit, plan a longer project, or split it into phases with the first one sized to 90 days. For the budget side, see what an Odoo implementation costs in India.