The date comes first, and that's the problem
In most Bangladeshi ERP projects I've seen go wrong, the go-live date was fixed before discovery finished. It might have been the start of the fiscal year in July, a board meeting, or a buyer audit. Everything after that became a race to hit the date. Testing got shortened. Data was loaded "as is, we'll clean it later". Training became a one-hour demo on Thursday before a Sunday go-live.
Then the system went live. It technically worked, and within three weeks the accounts team was keeping Tally open "just to check", the warehouse had a parallel Excel sheet, and the MD was asking why nobody trusts the stock report.
None of that was a software failure. Odoo did what it was configured to do. The company simply wasn't ready, and nobody had written down what ready meant, so there was nothing to say "not yet" with.
Teams write a detailed configuration spec but never write down the conditions under which they would not go live. A one-page list of those conditions, signed by the sponsor, is often the most useful document in the project. Once it exists, the date stops being the boss.
The four readiness gaps
When a go-live fails, the cause almost always sits in one of four places. Learn to check all four, because each one fails differently.
| Gap | What it looks like after go-live | How you detect it before |
|---|---|---|
| Data | Opening stock doesn't match the shelf; customer balances are wrong; duplicate products | Trial loads reconciled to the taka; a physical stock count, not a system count |
| People | Users can log in but can't do their job; Excel workarounds appear within days | A practical assessment per role, not attendance at a demo |
| Process | Transactions get stuck at approvals nobody owns; edge cases have no answer | UAT scripts built on real scenarios, including the ugly ones |
| Support | Small questions wait days; users give up and go back to the old way | A named hypercare roster, internal superusers, severity SLAs |
Notice that software bugs aren't on this list. Bugs happen, but a good hypercare process absorbs them. The four gaps above are what make a go-live collapse, because they undermine trust. Once users decide the system is wrong, they stop entering data into it, and then it really is wrong.
Readiness is a checklist, not a feeling
"Are we ready?" asked in a meeting always gets the answer "mostly". That isn't a decision. Replace the question with criteria that can only be answered yes or no, with evidence:
- All Must UAT cases have passed, and there are no open S1 or S2 defects.
- The second trial data load reconciled to the taka: AR, AP and stock value all match the legacy trial balance.
- A physical stock count has been completed and approved by finance.
- Every user has passed a practical assessment for their role.
- Opening balances have been approved in writing by the finance head.
- Printers, scanners and the internet, including a backup link, have been tested at every site that will use the system.
- The hypercare roster is agreed: who is on site, on which days, and who answers the phone at 9 PM.
- There's a written rollback plan.
We'll build each of these in the lessons that follow. By Lesson 06 you'll have a complete go/no-go checklist, and the roadmap template already includes one.
The Bangladesh calendar is a readiness criterion too
Some dates are simply bad for going live here, however ready the system is:
- The two weeks before Eid. Production peaks, festival bonuses are calculated, and half the key users take leave straight after. If payroll is in scope, going live in the Eid bonus month doubles the risk.
- Fiscal year-end (June). Finance is closing the old books. Asking them to also learn the new system and reconcile opening balances in the same weeks is how year-end gets delayed.
- VAT quarter-end. Since the Finance Act 2026, VAT returns are quarterly, due 15 days after the cycle ends. Don't cut over in the last week of a VAT quarter unless you've tested the return data first.
- Buyer shipment peaks for exporters, when the warehouse can't afford a slow day.
A good time is usually the start of a month in a quiet period, with the cut-over over a weekend (Friday–Saturday) and the first working day on Sunday.
You don't choose a go-live date. You choose readiness criteria and a target window, and the date is the first day in that window when every criterion is met.
Who decides
The go/no-go decision belongs to the project sponsor, usually the MD or CFO, not the vendor and not the IT manager. The client project manager presents the evidence against each criterion, process owners confirm their areas, and the sponsor decides. Write this into the project charter before the project starts. If you have a charter already, check that it says so. The charter template has a governance section for exactly this.
Vendors have an understandable interest in going live on schedule: it triggers their milestone payment. That's not a criticism, just a reason why they shouldn't be the ones deciding.
Exercise (10 minutes). Write down your current planned go-live date. Next to it, list which of the eight readiness criteria above you could answer "yes, with evidence" today. For each "no", write the name of the person who owns closing it. If you don't have a planned date yet, even better: write the criteria first.
Key takeaways
- Go-lives fail because of data, people, process and support gaps, rarely because of software.
- Readiness must be a yes/no checklist with evidence, signed off by the sponsor.
- Plan around Eid, fiscal year-end, VAT quarter-ends and shipment peaks.
- The date follows the criteria, not the other way round.
Before the next lesson, check how ready your company is overall with the ERP readiness assessment. It takes about five minutes.