Twelve weeks is the target for a focused, well-resourced Odoo implementation at a Bangladesh SME covering core modules: accounting, inventory, purchase, sales, and either manufacturing or HR/payroll. This timeline is achievable. I have delivered it. I have also seen projects drag to 30 weeks — not because Odoo is complex, but because the project lacked structure.
This roadmap is based on what I have learned across multiple Bangladesh manufacturing and trading implementations: what must happen in which sequence, where projects lose weeks, and what the specific Bangladesh context (Tally migrations, NBR fiscal calendar, Eid scheduling) changes about the standard playbook. Use it as a live planning document — share it with your project team on day one.
The week you skip discovery shortcuts will cost you three weeks in UAT. The projects that finished on time were the ones that were most thorough in weeks one and two.
Project team & RACI matrix
Before week one begins, every role in the table below must be named with a real person. An empty cell in a RACI matrix is a gap that will surface as a crisis in week seven. The most common gap in Bangladesh implementations: a client-side Project Manager who has authority to approve configuration decisions without escalating every item to the Managing Director.
| Activity | Sponsor (MD/CFO) |
Client PM | Odoo Consultant |
Key Users (Dept Heads) |
IT Admin |
|---|---|---|---|---|---|
| Scope sign-off | A | R | C | C | I |
| Business process documentation | I | A | R | R | I |
| Odoo configuration decisions | I | A | R | C | I |
| Server setup & user provisioning | I | A | C | I | R |
| Data extraction from legacy system | I | A | C | R | R |
| Data cleaning & validation | I | A | R | R | I |
| UAT test execution | I | A | C | R | I |
| Training delivery | I | A | R | R | I |
| Go-live decision | A | R | C | C | C |
| Hypercare issue escalation | I | A | R | R | C |
R = Responsible · A = Accountable · C = Consulted · I = Informed
5-phase overview
- Project kickoff, team roles confirmed, communication plan agreed
- AS-IS business process workshops (all modules in scope)
- Gap analysis: what current processes Odoo handles natively vs. what needs customization
- Server provisioned, Odoo installed, development instance created
- Data audit: review legacy system exports, identify data quality issues
- Company setup: fiscal year (July 1 for BD companies), currency, tax positions
- Chart of accounts aligned to Bangladesh accounting standards
- Module-by-module configuration: inventory → purchase → sales → accounting
- Manufacturing/HR modules (if in scope) configured and tested internally
- Bangladesh compliance configuration: Mushak tax positions, TDS withholding, payroll rules
- Custom reports and print templates (invoices, delivery notes, Mushak 6.3)
- Master data cleaned and validated (customers, vendors, products, employees, chart of accounts)
- Opening balances calculated and agreed with accounts team
- Test import run: identify import errors, resolve, re-import
- UAT test scripts executed by key users for every module in scope
- Defect log maintained; critical defects fixed and re-tested before UAT sign-off
- Super-user training: key users trained to train and support their teams
- Role-based end-user training: warehouse, accounts, procurement, management
- Training on Odoo in Bangladesh context: Mushak printing, payroll approval workflows
- Practice exercises in UAT environment using real company scenarios
- Training assessment and sign-off: each user confirms core tasks
- Go/no-go meeting: all checklist items reviewed, decision documented
- Production data cutover: final import of opening balances and master data
- Day 1 on-site support: consultant present for all operational hours
- Daily defect review and priority triage for first two weeks
- Handover to post-go-live support structure (L1/L2/L3)
Phase 1 — Discovery & Setup (Weeks 1–2)
- Hold kickoff meeting: confirm scope, timeline, team, escalation path
- Distribute and agree the RACI matrix — every role named
- Set up shared project tracker (Excel or shared document)
- Run AS-IS workshop for each module: observe current workflow, document steps
- Identify integration points: what connects to what (payroll ↔ HR, purchase ↔ accounts)
- Request data exports from legacy system (Tally, SAP, custom software)
- Document TO-BE processes in Odoo — walk key users through Odoo demo
- Build gap analysis register: for each gap, decide configure / customize / defer
- Agree customization scope and log in change register
- Server provisioned: on-premise (Ubuntu 22.04 + PostgreSQL) or cloud (Odoo.sh / VPS)
- Odoo installed, development database initialized, module list activated
- Data audit: review exported legacy data for duplicates, missing fields, naming inconsistencies
Most Bangladesh SMEs migrate from Tally Prime or Tally ERP9. Tally exports are available as XML or Excel via the Tally ODBC bridge. The most common data issue: Tally ledger names use inconsistent formatting (vendor names spelled differently across transactions), which must be deduped before import. Budget 3–5 working days for data audit if Tally is the source system. For custom-built legacy software, extract raw SQL dumps early — week 2 data audit often reveals the legacy system lacks structured master data entirely.
Phase 2 — Core Configuration (Weeks 3–6)
- Company information: BIN number, trade license, legal address, fiscal year (July 1 – June 30)
- Chart of accounts: map from existing CoA or build from Bangladesh standard
- Tax configuration: VAT 15% (standard), VAT 0% (export), TDS rates by vendor category
- Fiscal positions: local taxable, export (zero-rated), EPZ (exempt)
- Currency setup: BDT (primary) + USD/EUR for export companies
- Payment terms, bank accounts, journal configuration
- Warehouses and storage locations configured (include bonded/EPZ if applicable)
- Product categories and costing method (AVCO vs FIFO) decided and configured
- Units of measure: set up local units (pcs, dzn, kg, yards, bales) with conversion factors
- Purchase workflow: 3-way match (PO → receipt → bill) or 2-way configured per policy
- Sales pricelist and discount structure configured
- Vendor and customer payment terms configured per company policy
- Manufacturing: Work centers, routing, BOM structure for top 20 products
- Production order workflow: plan → confirm → produce → post inventory
- Quality control points configured (incoming, in-process, final)
- HR/Payroll: Employee structure, departments, job positions
- Salary structure: basic, house rent, medical, transport per Bangladesh Labour Act
- PF (10% employer), gratuity calculation rule, income tax slab configuration
- Mushak 6.3 sales invoice template: BIN, challan number, Mushak report format
- TDS deduction on vendor bills: withholding tax lines, TDS certificate template
- Custom print templates: purchase order (company letterhead), delivery note, payslip
- Bank reconciliation workflow tested with sample statement
- Access rights reviewed: who can confirm/validate/cancel each document type
- Internal review: consultant walks key users through configured system end-to-end
Phase 3 — Data Migration & UAT (Weeks 7–9)
- Customer master: deduplicate, standardize names, add BIN/TIN where applicable
- Vendor master: verify TIN for TDS classification, complete bank account details
- Product master: ensure all products have category, UoM, cost price, internal reference
- Employee master: NID number, joining date, department, designation
- Opening stock: physical count reconciled to legacy system balances
- Test import run → review errors → fix source data → re-import
- Opening balances imported: trial balance, AR aging, AP aging, inventory valuation
- Accounts team reconciles Odoo trial balance vs legacy system trial balance
- UAT begins: key users execute test scripts for their module
- Defects logged: severity 1 (blocker) vs severity 2 (workaround available)
- Severity 1 defects fixed within 48 hours; re-tested before UAT continues
- Remaining UAT test cases executed and signed off by each module owner
- Zero open severity 1 defects — confirmed by client PM and consultant
- Severity 2 defects: either fixed or formally deferred to post-go-live backlog
- Performance test: concurrent user load on target server
- Production server commissioned: separate from development, full backup configured
- Cutover plan documented: exact sequence and timing for go-live weekend
- Key users not given protected time — they run UAT between regular duties and rush it
- Test scripts not written — users test randomly, missing coverage
- Opening balances not reconciled before UAT — accounts team spends UAT time on reconciliation
- No defect log — verbal "it doesn't work" without written evidence to track or fix
Phase 4 — Training (Weeks 10–11)
- Key users (one per module) trained to full depth: configuration options, override procedures, period-close tasks
- Super-users can: approve/reject workflows, correct posting errors, reset passwords
- Bangladesh-specific tasks trained: monthly Mushak report extraction, payroll batch processing, TDS certificate generation
- Super-users practice training delivery — they will train their own teams in week 11
- Role-based sessions: warehouse (GRN, goods issue, stock count), accounts (AP/AR, bank reconciliation), procurement (PO creation, vendor bill), management (reports, dashboards)
- Training in UAT environment using real company scenarios
- Each user completes a minimum 3 end-to-end transactions in their role before sign-off
- Sign-off sheet signed by user and supervisor — no user goes live unsigned
Phase 5 — Go-Live & Hypercare (Week 12+)
- All checklist items reviewed (see go/no-go table below)
- Decision documented — Sponsor confirms go-live approved
- Legacy system freeze announced: no new transactions from cutover date
- IT Admin confirms: production server backed up, firewall rules set, SSL active
- Final data export from legacy system (closing balances as of cutover date)
- Production import: master data → opening balances → opening stock
- Trial balance check: Odoo vs legacy — must match to BDT 1
- User accounts activated in production — passwords distributed
- Consultant on-call all night until import confirmed clean
- Consultant physically present at client site from opening of business
- First transactions: opening PO confirmed, first sales order, first GRN
- Issue log opened: every user concern logged with severity rating
- Escalation: consultant resolves severity 1 in real time; severity 2 by end of day
- End-of-day review: what worked, what needs urgent fix tonight
- Consultant available daily (remote) for 2 weeks post go-live
- Issue log reviewed in daily 15-minute standup with client PM
- First month-end close supported by consultant
- First payroll run (if HR module) supported by consultant
- Transition to BAU support at end of week 14 when no new severity 1 issues for 5 consecutive days
Go / no-go criteria
The go-live decision is binary. Every item below must be green. An amber item requires documented mitigation. A red item is a go-live blocker — the date moves, not the standard.
| Criteria | GO condition | NO-GO condition |
|---|---|---|
| UAT sign-off | All severity 1 defects resolved and re-tested. Sign-off sheet signed by all key users. | Any open severity 1 defect. Key user sign-off missing for any module in scope. |
| Opening balances | Odoo trial balance matches legacy system trial balance to BDT 1. Accounts team confirms in writing. | Any unexplained variance in trial balance. Opening AR/AP aging not reconciled. |
| Data migration | Master data import completed. Error rate below 1%. Product, customer, vendor records verified by key users. | Import errors above 1%. Opening stock quantities not confirmed by warehouse team. |
| User training | All users attending go-live have signed training sign-off sheet. Super-users confirmed for each module. | More than 20% of go-live users unsigned. No identified super-user for any in-scope module. |
| Infrastructure | Production server live, daily backup configured and tested, UPS power cover confirmed, internet redundancy confirmed. | Production server on the same machine as development. No backup restoration test completed. No UPS on server. |
| Access rights | Every user can log in with correct role. Sensitive access (account confirmation, inventory valuation) restricted to authorized users only. | Admin credentials distributed to all users. Access rights not reviewed and signed off by client PM. |
| Legacy system freeze | Legacy system freeze communicated to all staff. Final closing balances exported and confirmed. | Transactions still running in legacy system. Cutover date not communicated to all departments. |
Bangladesh calendar planning rules
The Bangladesh business calendar has specific windows that significantly affect implementation scheduling. Ignoring these has derailed otherwise well-run projects.
- NBR fiscal year starts July 1. For accounting-heavy companies, a September–October go-live means the first full year of Odoo runs on a clean year. Going live in March–June means your first year-end close in Odoo is only months away — a high-risk situation for an accounts team still learning the system.
- Eid-ul-Fitr and Eid-ul-Adha: Do not schedule go-live within 3 weeks of either Eid. Staff are on staggered leave starting 2 weeks before, and the support team will be at skeleton capacity exactly when you need them most.
- Ramadan: Working hours are reduced, energy is low, and evening training sessions (common for factory floor staff) are not possible. Defer training-heavy phases to after Ramadan.
- Week starts Sunday: The Bangladesh work week is Sunday–Thursday. When aligning with international Odoo partners, confirm that support SLAs account for the Bangladesh week — Friday and Saturday are weekend days here, not Saturday and Sunday.
- Year-end close pressure: June is financial year-end for NBR. Accounts teams are fully occupied. Do not schedule configuration workshops or UAT sessions in May–June for any module touching accounts.
Common failure modes by phase
Understanding why ERP implementations fail in Bangladesh is essential context for every project team member. These are the phase-specific failure modes I observe most frequently:
- Phase 1: Discovery workshops attended by department heads but documented by the consultant alone. Process maps are approved without being read. Result: configuration doesn't match how the team actually works.
- Phase 2: Scope creep accepted informally — a key user asks for a new feature in week 4 and the consultant builds it without logging it. The timeline extends invisibly until it visibly blows up in week 9.
- Phase 3: Opening balances treated as a week-8 task instead of a weeks-3-through-8 ongoing activity. The accounts team surfaces a 3-year-old unclaimed receivable in the legacy system in week 8 and debates whether to migrate it. UAT is blocked while this is resolved.
- Phase 4: Training scheduled for the two days before go-live. Users see Odoo for the first time on the day they are supposed to be using it in production.
- Phase 5: No on-site support on day one. The consultant "is available by phone." Warehouse staff cannot figure out how to confirm a delivery order and revert to paper. Within 48 hours, there is a discrepancy between Odoo inventory and physical stock that takes two weeks to reconcile.
This roadmap works when three things are true: the client PM has real authority, key users have protected time, and the go-live date is treated as earned (not given). Projects that fail do so because one of these three was missing. Before signing a contract with any Odoo implementer in Bangladesh, confirm that they have a week-by-week plan they can hand you on day one. If they don't — that is information. To pressure-test a vendor's budget against independent benchmarks before you negotiate, run your scope through the Odoo cost estimator. Planning an Odoo implementation? Let's review your roadmap together →
Frequently asked questions
How long does Odoo implementation take in Bangladesh?
For a Bangladesh SME with 25–100 users implementing core modules (accounting, inventory, purchase, sales), a realistic timeline is 10–14 weeks. The 12-week roadmap in this guide is the target for a well-resourced project. Complex manufacturing deployments (production scheduling, quality control, custom compliance) typically run 16–24 weeks. Projects that extend beyond 20 weeks usually do so because of data quality issues, scope creep, or inadequate client-side resource allocation — not because Odoo is difficult to configure.
What is the best time of year to go live with Odoo in Bangladesh?
The ideal go-live windows for Bangladesh companies are: August–September (after NBR fiscal year start, before Eid-ul-Adha preparation) and November–December (post-Puja, before year-end close rush). Avoid Ramadan (reduced working hours), the 3 weeks around each Eid, and May–June (NBR fiscal year-end when accounts teams are fully occupied).
Who should be on the Odoo implementation project team in Bangladesh?
A standard Bangladesh SME team requires: Project Sponsor (MD/CFO) who owns budget and go/no-go decisions; Client Project Manager with authority to approve configuration decisions; Key Users / Module Champions (one per major module: accounts, warehouse, procurement, HR); IT / System Admin for server and access management; and the Odoo Consultant (1–3 people depending on scope). The most common gap: a Client PM who must escalate every decision to the MD, adding 2–3 days to every configuration approval.
What are the most common Odoo implementation failures in Bangladesh?
Based on projects across Bangladesh manufacturing and trading companies: (1) data not cleaned before migration — dirty Tally exports imported directly into Odoo; (2) scope creep accepted without timeline adjustment; (3) key users not given protected time for testing; (4) training deferred to go-live week; (5) no parallel run or on-site support on day one. Each failure mode is avoidable with the structure described in this guide.