Most businesses underestimate how long ERP implementation takes. The vendor says three months, the project runs five, and the frustration builds because nobody set the right expectation upfront.
Here's a realistic breakdown of what actually happens during an ERP implementation, and why each phase takes as long as it does.
Phase 1: Discovery and Requirements (Weeks 1-4)
This is the phase that determines whether everything else goes smoothly. The implementation team spends this time understanding how your business actually works — not how you think it works, and not how a generic ERP assumes it works.
Good discovery involves sitting with the people who do the work: the finance staff who process invoices, the warehouse team who manage stock movements, the HR person who runs payroll. Not just managers explaining the process from above.
What gets documented during discovery:
- Current workflows and their pain points
- Data that needs to exist in the system
- Reports and dashboards required by each role
- Integration requirements with other systems
- Business rules (approval thresholds, pricing tiers, credit limits, tax configurations)
Four weeks is a realistic minimum for a business with 5-10 modules in scope. Rushing this phase creates problems that surface much later — typically during UAT, when it's expensive to fix.
Phase 2: System Design (Weeks 5-7)
Based on discovery, the team designs the system architecture: database structure, module relationships, user roles, screen flows, and the logic for any custom business rules.
This is mostly an internal activity for the development team, but key stakeholders should review and sign off on the design before development starts. Changes after development begins are significantly more expensive than changes made on paper.
For businesses with complex operations — multi-location inventory, manufacturing with bill of materials, or custom pricing logic — this phase can extend to three or four weeks.
Phase 3: Development (Weeks 8-20)
Development is where the system gets built. For a custom ERP, this means writing code. For a packaged system like Odoo, it means configuration plus any custom development for requirements the base product doesn't cover.
The development timeline scales with scope:
- Simple implementations (3-4 modules, single location, standard workflows): 6-8 weeks
- Medium implementations (5-7 modules, some custom logic, integrations): 10-14 weeks
- Complex implementations (full suite, significant customization, multiple integrations): 14-20+ weeks
Development happens in sprints. At the end of each sprint — typically two weeks — there should be working functionality you can see and test. You shouldn't be waiting 16 weeks for the first demonstration of a working system.
Phase 4: User Acceptance Testing (Weeks 18-22)
UAT is when your team tests the system against real business scenarios before go-live. This is not a rubber stamp — it's a genuine testing phase that will surface issues.
Plan for 2-4 weeks of UAT depending on complexity. Allocate real time from real users. The finance manager needs to run payroll in the test environment. The warehouse team needs to process receipts and transfers. These tests surface edge cases that developers don't think of, because they don't know your business the way your staff does.
What makes UAT go poorly: assigning it to junior staff who don't understand the full process, or treating it as optional. What makes it go well: a structured test script based on real daily tasks, clear defect tracking, and a defined threshold for what "pass" means before go-live is approved.
Phase 5: Data Migration (Runs Parallel, Final Week Before Go-Live)
Data migration runs alongside development rather than as a separate sequential phase. The team builds the migration scripts while the system is being developed, then validates them on real data before go-live.
What typically needs to migrate:
- Master data: customers, suppliers, products with specs and pricing, chart of accounts
- Opening balances: AR balances, AP balances, stock quantities as of the cutover date
- Historical transactions: 1-3 years of sales, purchases, and financial data for reporting continuity
The final cutover — loading the actual live data — happens in the week before go-live. This is a critical moment. Most implementations run a "dry run" migration first to catch errors, then do the real migration once everything validates cleanly.
Phase 6: Training (Weeks 22-24)
Training happens after UAT is substantially complete, not before. Trying to train users on a system that's still changing wastes their time and creates confusion. How you handle this training phase has a direct impact on adoption — managing user adoption during rollout is worth thinking through before you reach this stage.
Effective training is role-specific. The finance team needs training on the finance modules. The warehouse team needs training on inventory and receiving. Nobody needs to sit through a three-hour overview of modules they'll never touch.
Allocate one to two weeks for training across the organization. For larger teams, train department by department rather than everyone at once.
Phase 7: Go-Live and Hypercare (Weeks 25-28)
Go-live is not the finish line — it's the start of the most intense phase.
The first four weeks after go-live are critical. Users are working in a new system while still trying to do their actual jobs. Questions come up constantly. Bugs that slipped through UAT surface in real-world use. The team needs dedicated support available to respond quickly.
This is sometimes called "hypercare" — a period of intensive post-launch support before the project transitions to normal maintenance. A good implementation partner plans for this explicitly rather than walking away on launch day.
Total Timeline: What to Expect
For most Indonesian SME implementations:
- Small scope (3-4 modules, single location): 3-4 months
- Medium scope (5-7 modules, some integrations): 4-6 months
- Full suite with complexity: 6-9 months
Why Timelines Extend
The most common reason projects run longer than expected is scope change. The business discovers something during development or UAT that they want added — and that's often legitimate. Business requirements evolve, and rigid scope can produce a system that doesn't actually serve the business.
The key is managing scope change with a formal process: document the change, assess the impact on timeline and cost, get approval, then proceed. Informal scope additions are where projects lose control.
Client-side availability is the other major factor. If key users can't commit time to UAT reviews, discovery sessions, or data validation because they're too busy running the business, the project stalls. This is a resource allocation problem, not a technical one.
Rushing implementation to meet an arbitrary deadline — a fiscal year cutover, an investor presentation, a regulatory deadline — is the single biggest cause of poor ERP outcomes. A pressured go-live with incomplete testing and undertrained users creates months of cleanup work afterward. It's almost always better to take the extra weeks.
CERIS builds realistic implementation plans from the start of every engagement, with clear milestones and honest timelines. See what we build or let's talk before you commit to a schedule.
