Every ERP project we run follows the same six phases. The scope changes — a single-showroom rollout takes four weeks, a 200-outlet chain takes ten — but the sequence does not. Discovery, Design, Build, Migrate, Go-live, Hypercare. We tune to size; we never reinvent.
This is the playbook in long form, with the things that consistently go wrong and the small choices that prevent them.
Phase 1: Discovery
The objective of Discovery is to write a Statement of Work that the customer signs and we can deliver. The activities are listening and asking.
- Site visit, mandatory — manufacturing floor, hotel front desk, jewellery counter, classroom. Whatever the product is for, we go see the place.
- Stakeholder interviews — the operator, the finance lead, the IT lead, the end-user. Separately, two hours each.
- Current system audit — what's running, what's breaking, what gets reconciled in Excel at month-end.
- Constraints and red lines — what cannot change, what must change, what the regulator requires.
Output: a written SOW with deliverables, timeline, fixed price, exclusions. Both sides sign at the end of Phase 1 or the project doesn't start.
What goes wrong: the customer doesn't realise this is a billable engagement. We've shifted to charging a discovery fee credited against the implementation if the customer proceeds. This has aligned incentives — only customers serious about a project pay for Discovery, and customers serious about a project are the ones we want to work with.
Phase 2: Design
Design is schema-first. We write the future-state data model in plain English (covered in detail in a separate post), then design the API surface, then sketch the UI. The customer signs off the schema before any code is written.
- Entities and attributes — what nouns exist and what each one has
- Cardinalities and constraints — how they connect
- Business rules — what's mandatory, what triggers what, what's audit-logged
- Tax configuration — GST scenarios, e-invoice triggers, e-way bill thresholds
- Integrations — which external systems, which fields cross the boundary
- Custom extensions — where we'll write code beyond the base product
- UI sketches — wireframes per role (operator, manager, end-user)
Output: a design document, signed by named people on the customer side. The most senior person should review and sign. Design changes after this point are change-requests; we'll quote them.
What goes wrong: scope creep during Build because Design wasn't tight enough. We've learnt to push back hard at Design time and capture every assumption in writing.
Phase 3: Build
Build is the engineering phase. The base product is configured, AL extensions or custom modules are written, integrations are wired, master data templates are prepared. We run a mid-build demo at the half-way point — the customer sees a working slice, gives feedback, we adjust.
- Configuration first — base product set up per Design
- Custom extensions next — AL or product-specific code
- Integrations — external system connectors, tested in sandbox
- Master data templates — Excel files or import scripts the customer fills in
- Mid-build demo — 60% complete, what works, what's coming
- End-of-build demo — full workflow demonstrated with dummy data
- Internal QA — our team tests every workflow before customer-side UAT
What goes wrong: integrations turn out to be harder than estimated because the external system's API documentation was wrong or out of date. We've learnt to spike every integration in Discovery, before Design freezes, so we know what we're committing to.
Phase 4: Migrate
Migration is the riskiest hour of any project. The customer's data moves from the old system to the new. The new system becomes the source of truth.
- Data extraction from source — scripts written in Phase 3, exercised in Phase 4
- Mapping and transformation — old fields to new schema
- De-duplication — customer master, vendor master, item master usually need clean-up
- Test load — full dataset into test tenant; customer-side validation
- Reconciliation — trial balance, item-quantity totals, open transaction counts match between systems
- Dry-run cutover — practice the production cutover on a weekend
- Production cutover — same playbook as dry-run, with the real switch
The reconciliation step is the one teams skip. The CA or finance lead must see that totals match between old and new before sign-off. If they don't match, we find the difference. If we can't find it in the cutover window, we delay the cutover. We've delayed three projects by 48 hours. We've never gone live on a mismatched trial balance.
Phase 5: Go-live
Go-live is the cutover and the first 72 hours of operation. Our consultant is on-site.
- Day 0 (cutover) — usually a weekend; old system locked Friday, new system live Monday
- Day 1 (Monday) — full operation in new system; consultant walks the floor, sits with users, answers questions
- Day 2-3 — issue triage; small fixes deployed; users gain confidence
- Daily standup — operator, our consultant, the IT lead; what worked, what didn't
The 72-hour on-site is non-negotiable. Remote support during go-live is dramatically worse than physical presence. Many of our customers were burned by previous vendors going live remotely; the on-site commitment is what closes most of our late-stage sales.
What goes wrong: a user finds something we missed in UAT. This happens on every go-live. Our consultant fixes it that day or escalates to engineering for an overnight deploy. The customer's tolerance for small issues is high if we're visibly working the problem.
Phase 6: Hypercare
Hypercare is the first four weeks after go-live. We're available daily; the customer's team builds confidence.
- Daily standup (week 1) — quick syncs, issue triage, configuration tweaks
- Weekly standup (weeks 2-4) — fewer touchpoints as the team settles
- Issue log — every issue tracked, every fix dated, every closure signed off
- Month-end check — first month-end in the new system is the make-or-break moment
At end of Hypercare we hand over to the managed-support team. Hypercare is included in the implementation cost; managed support is a separate contract.
What goes wrong: month-end produces a report the customer relied on that the new system doesn't yet generate. We've learnt to extract every report the customer runs in the old system during Discovery and explicitly scope its reproduction in Build.
What the playbook costs
For an Indian SMB doing a Business Central implementation — 50 users, mid-complexity — the typical engagement is 10-14 weeks and ₹18-30 lakh in SourceForge fees. For a Gold ERP rollout to a 5-branch chain, similar range. For a single-outlet Restaurant POS, 2-3 weeks and significantly less.
We quote fixed-price. We absorb scope risk that turns out to be in our estimate. Customer-side scope changes are quoted as change-requests.
Why this playbook works
It works because it's been calibrated across roughly fifty projects. Every painful lesson — the missed report, the failed reconciliation, the absent CA, the off-by-one tax rate — is encoded somewhere in this sequence. New consultants don't have to learn each of these the hard way; the playbook teaches them.
It also works because we won't run a project without it. If a customer asks us to skip Discovery and start building, we say no. If they ask us to go live without reconciliation, we say no. The playbook is non-negotiable. Customers who push back at the start are doing us a favour — we can disengage gracefully before either of us has invested too much.