← All articles

Blog

Odoo Implementation Timeline: What 60 Days Actually Looks Like

A week-by-week look at a real 60-day Odoo implementation for an Indonesian SME — what happens, who's involved, and where projects usually slip.

6 min read
  • mid

Most Odoo proposals quote a timeline. “Eight weeks to go-live.” “Three months end to end.” The number lands in the inbox and the owner mentally adjusts their plans around it. Then month two arrives, the project is somehow only at the data migration stage, and nobody is quite sure when the actual launch happens.

The fault is rarely the vendor inflating the number on purpose. The fault is that ERP project plans get presented as gantt charts with crisp boxes, when in reality there are five or six places where the timeline always wobbles by a week. Knowing where those wobble points are turns “we’re delayed” into “we’re at week 5 of the master data step, this was always going to happen.”

Here is what a real 60-day Odoo implementation looks like for an Indonesian SME with 30–80 users, three or four core modules, and a moderate amount of Indonesian localization work.

Week 1 to 2: scoping and process mapping

This is the foundation step everyone wants to rush through. The work is structured workshops with each department head — usually sales, purchasing, warehouse, accounting, and either HR or production depending on your scope. The output is a written list of every process that will run through Odoo and how each one maps to a standard Odoo flow.

Most projects discover their first surprise here. A common one: the sales team takes pre-orders by WhatsApp with non-standard payment terms by customer, and there is no documented rule for how those become sales orders. Odoo can handle this, but only if someone decides on the rule. The decision is the project’s, not the consultant’s.

Deliverable end of week 2: a process map document, a finalised module list, and a list of “configurable items” — chart of accounts, tax codes, warehouse structure, user roles, approval flows.

Where it slips: getting time on the calendar of busy department heads. Block four full half-days in their schedules before kick-off, not on the fly.

Week 3 to 4: configuration and master data preparation

Configuration is the consultant setting up Odoo to match the decisions from weeks 1–2. Chart of accounts loaded, taxes configured (PPN 11%, PPN 12% if applicable to your goods, withholding tax categories), warehouses and locations set, user roles assigned, approval flows wired up.

Master data preparation is your team’s homework. Products, customers, suppliers, opening stock, opening AR and AP balances — all of it has to be cleaned in spreadsheets to a format Odoo can import. If your customer list lives in three different files with inconsistent naming, this week is when reality bites.

Deliverable end of week 4: a sandbox Odoo environment configured for your business, and a set of clean import-ready CSV files. Probably about 70 percent clean, with another pass needed.

Where it slips: master data quality. Almost every project we run loses a week here because the spreadsheets the team thought were clean turn out to have duplicate SKUs, missing supplier tax IDs, or inconsistent units of measure.

Week 5 to 6: data migration and integration build

Now the real CSVs land in the sandbox. Products import, customers import, suppliers import, opening balances post. The team sees their actual business inside Odoo for the first time. Almost always, the first import reveals problems — a category that did not map cleanly, a tax code that needs splitting, a customer who is also a supplier and needs both records.

This is also when integrations get built. Tokopedia and Shopee connectors configured. Midtrans or Xendit payment gateway tested. The e-Faktur export module installed and tested against a sample invoice. If you are pulling data from an existing system (Accurate, Zahir, a custom ERP), the migration script runs and the output is validated.

Deliverable end of week 6: a sandbox with your real data, working integrations, and a test plan written for user acceptance testing.

Where it slips: integrations. Marketplace API quirks, payment gateway sandbox keys, the Odoo Indonesian localization having a quirk with a specific tax code. Plan for a 5-day buffer here.

Week 7: user acceptance testing

This is where the team finally touches the system. Sales runs through entering a real quote, converting to order, delivering, invoicing. Warehouse runs through receiving a purchase order, doing a transfer, doing a cycle count. Accounting reconciles a bank statement and closes a test month. HR runs payroll for one employee.

Every team will find issues. That is the point. The issues are sorted into three buckets: bugs (something broken, the consultant fixes), training gaps (the user does not yet know the right way, training resolves), and scope changes (the user wants a different process than what was agreed — these get logged, prioritised, and either done now or deferred).

Deliverable end of week 7: a sandbox the team has stress-tested, a list of issues with status, and a go/no-go decision based on remaining critical issues.

Where it slips: scope creep dressed up as bug reports. Watch this carefully. Some friction is the team learning a new tool, not the tool being wrong.

Week 8: training and go-live

Training is usually 3–5 days of structured sessions per role, then 1–2 days of side-by-side support as the team uses the system on real work. Then a cutover weekend — final data migration from production, final reconciliation, go-live Monday morning.

Day one of go-live is messy. Day three is calmer. Day ten the team is mostly off the old process. Day thirty they have forgotten what the old system looked like, except for one or two people who keep wanting to do things the old way.

Deliverable end of week 8: a live Odoo running real business, hypercare support active for the next 30 days, and a list of phase-2 items to revisit.

Where it slips: go-live readiness. If the team has not committed to a cutover date by week 7, sliding by a week is the safer call. Going live with a team that is not ready costs more than the delay.

What the 60 days does not include

Two things people forget. First, hypercare — the 4–8 weeks after go-live where the team is using Odoo on real work and surfacing issues every day. Budget for this explicitly. Second, phase 2 — the items deferred from initial scope, plus the things you only realised you wanted once the system was running. Most successful Odoo deployments have a phase 2 roadmap that runs another 3–6 months.

If your project genuinely fits this shape, 60 days is realistic. If you have heavy customization, multi-entity consolidation, or unusual industry workflows, plan for 90–120 days instead. The number itself is less important than knowing where it will wobble.

If you want a sanity check on a timeline you have been given by a vendor, or help planning one of your own, we do free one-hour calls walking through exactly that. No obligation, candid feedback.