Implementation journey
How implementation actually runs, phase by phase.
"We tried an ERP before and it failed" is a real, named objection — implementation risk, not product doubt. This is the honest, code-grounded version of what actually happens between signing and go-live.
- 01
Discovery
- 02
Solution Design
- 03
Configuration
- 04
Data Migration
- 05
Testing
- 06
Training
- 07
Launch
- 08
Post-Launch
What it is
Implementation is an 8-phase methodology — discovery, solution design, configuration, data migration, testing, training, launch, and post-launch — that maps your real processes to the product before go-live, not a generic onboarding checklist run the same way for every customer.
Scope before configuration
Decide operating scope, owners and constraints before changing the system.
Data before go-live
Migration, reconciliation and ownership are treated as implementation work, not an upload task.
Adoption after launch
Post-launch support and operating discipline are part of the methodology, not an afterthought.
The rollout
Eight gates from discovery to post-launch.
Each phase has a purpose, named activities and tangible outputs. The timeline is designed to make implementation legible before a project starts.
Discovery
Before any configuration happens, discovery maps your real processes — not a generic template. This is where a manufacturer's actual BOM complexity, a distributor's warehouse count, or a services firm's billing models get understood directly, matching the evaluation criteria a real buying committee actually checks.
Activities
- Document current systems and where data actually lives today (spreadsheets, Tally/QuickBooks/Zoho, a legacy or point tool)
- Map real business processes module by module — which of the 12 modules apply, and which capability groups within them matter most
- Identify the specific workflows that matter most (e.g. plan-to-production, procure-to-pay, hire-to-payroll)
- Surface honest scope questions early — what the product does and does not do today, referenced against real capability groups, not assumed
Typical outputs
- A documented current-state process map
- A confirmed module scope for the implementation
Solution Design
Discovery's findings become a concrete design: which modules, which workflows, and how the platform's shared structures — companies, branches, roles, numbering — map to your real organisation.
Activities
- Design the company/branch/department structure for multi-entity or multi-location organisations
- Design the role and permission model — which of the platform's seeded roles apply, and where scoped or time-bound assignments are needed
- Plan approval thresholds and governance rules (quotation approval limits, journal approval thresholds, matching tolerances) against real policy, not defaults left unexamined
- Confirm the numbering-series scheme for invoices, purchase orders, and other documents
Typical outputs
- A solution design document
- A confirmed role and approval-threshold plan
Configuration
Organisation bootstrap is a real, one-transaction operation that seeds roughly 12 system roles and 29 numbering series at signup — configuration builds on that seeded foundation rather than starting from nothing, adapting it to the solution design rather than leaving defaults in place.
Activities
- Configure companies, branches, and departments per the solution design
- Adjust roles, permission packages, and any custom roles the design called for
- Set approval thresholds, matching tolerances, and other governance rules module by module
- Configure the chart of accounts, tax rules, and localisation settings (India-default: en-IN, Asia/Kolkata, INR, April-start fiscal year, adjustable per organisation)
Typical outputs
- A configured, entitlement-gated workspace matching the solution design
Data Migration
Customers, items, suppliers, and open transactions are migrated and reconciled as part of implementation — a real service commitment, not an automated one-click import. This phase gets the expanded treatment because it's the step most implementation-risk objections are really about.
Activities
- Extract master data from current systems — items, parties (customers/suppliers), addresses, unit-of-measure, bills of material
- Cleanse and deduplicate before import — a spreadsheet's drift (duplicate customers, inconsistent item codes) doesn't get carried into the new system as-is
- Migrate open transactions (open sales orders, open purchase orders, outstanding invoices/bills) so operations don't have a gap at go-live
- Reconcile migrated data against source-system totals before sign-off — balances, quantities, and outstanding amounts are checked, not assumed correct
Typical outputs
- A reconciled master-data set
- A migrated, verified opening-balance position
What gets migrated
- Item master (codes, pricing, unit-of-measure, BOM structures where applicable)
- Customer and supplier master data, including addresses and payment terms
- Opening stock balances by warehouse
- Open sales orders, purchase orders, and outstanding receivables/payables
- Chart of accounts and opening trial balance
Testing
Configured workflows are validated against real scenarios drawn from discovery — not a generic test script — before anyone depends on the system for a live transaction.
Activities
- Run real workflow scenarios end to end (e.g. a real quotation through to invoice, a real purchase order through to matched vendor bill)
- Validate approval routing and self-approval blocking behave as designed
- User acceptance testing with the actual people who will use the system day to day, not just IT
Typical outputs
- A validated set of real-scenario test results
- Sign-off from the people who'll actually use the system
Training
Role-based training matches the real role and permission design from solution design — a warehouse clerk isn't trained on the same screens as a finance controller.
Activities
- Role-based training sessions matching each real permission package
- Hands-on practice in a real, isolated workspace before go-live
- Documentation and reference material specific to the configured workflows, not generic product documentation
Typical outputs
- Trained users per role
- Role-specific reference documentation
Launch
Go-live activates the subscription (through the platform's HMAC-verified, replay-protected billing webhook pipeline) and switches entitlement gates on for the configured module set.
Activities
- Final reconciliation check on migrated data
- Subscription activation and module entitlement confirmation
- Go-live cutover, with the prior system typically kept read-only for a reconciliation window rather than switched off immediately
Typical outputs
- A live, entitled workspace running real transactions
Post-Launch
Early usage surfaces configuration refinements discovery couldn't fully anticipate — approval thresholds that turn out too tight or too loose, a report a team actually needs that wasn't scoped, a role that needs narrower access than first designed.
Activities
- Hypercare support during the initial usage period
- Configuration refinement based on real usage patterns
- Adoption review against the reporting and dashboards each role actually uses
Typical outputs
- A refined, stable configuration reflecting real usage
Buyer questions
Implementation questions deserve operational answers.
The FAQ stays practical: scope, migration, rollout, adoption and the things teams need to know before committing.
How long does implementation actually take?
This varies by scope — module count, data volume, and process complexity all matter, and no two implementations look the same. Rather than quote a generic number, the discovery phase is specifically where a realistic scope and plan get set for your actual organisation.
What if our processes don't match a standard module exactly?
Configuration adapts numbering, roles, approval thresholds, and workflow governance to your real process — see the Configuration phase above for what's actually adjustable. Discovery and Solution Design exist specifically to catch process mismatches before configuration starts, not after.
Will we lose data or have a gap in operations during migration?
Open transactions — open sales orders, open purchase orders, outstanding receivables and payables — are migrated alongside master data, and migrated data is reconciled against source-system totals before sign-off. The typical pattern is keeping the prior system read-only for a reconciliation window rather than an abrupt cutover.
Do we need an in-house IT team to manage this?
An IT/Ops resource is useful for data extraction and integration questions during discovery and migration, but implementation doesn't require a dedicated in-house administrator to run day to day — the role and permission model is designed during solution design specifically so business owners of each module can operate it themselves.
Related operating documents