Even a well-configured system can fail on launch day. Users do not know how to handle exceptions, master data is incomplete, an integration repeats events and management asks for the old spreadsheet to remain “just in case”. Within a week, the two records disagree.
Phased implementation reduces the number of unknowns at each step rather than reducing the final ambition. The team validates a limited end-to-end process, removes causes and only then expands use.
Core implementation stages
| Stage | Output | Exit condition |
|---|---|---|
| Discovery | Objectives, scope, processes, roles and risks | Business owner confirms priorities |
| Design | Scenarios, data, integrations and acceptance tests | Key exceptions are covered |
| Configuration and prototype | Working flow with test data | End-to-end scenarios pass |
| Pilot | One team uses real operations | Critical defects closed and measures stable |
| Cut-over | Verified data and one operational system of record | Control totals and owners confirmed |
| Stabilisation | Issue queue, support and actual KPIs | Process works without duplicate records |
Choose a representative pilot
A pilot should not be an artificial easy example. Select a real process with visible value, controlled volume and a team willing to provide evidence. It should contain normal exceptions without making one error capable of stopping the company.
For example, start with one sales team and warehouse but run the entire chain from enquiry to payment and shipment.
Do not launch isolated module islands
“Customer cards now, warehouse later” can create a polished CRM that cannot answer stock or delivery questions. A stage should be small but end-to-end: one completed business outcome rather than unrelated screens.
| Weak stage | Controlled stage |
|---|---|
| Import all customers and demonstrate cards | Receive an enquiry, check duplicates, assign an owner and create the next action |
| Enable warehouse master data | Show availability, reserve stock and complete shipment |
| Build dozens of reports | Deliver one decision measure with drill-down to source operations |
| Connect an API | Handle success, duplicates, failure and recovery |
Train by role and scenario
A two-hour general presentation does not prepare anyone for work. A salesperson should practise customer creation, duplicate handling, reservation, cancellation and overdue payment. Warehouse staff should practise receipt, picking, shortages and returns.
Instructions should centre on action and exception. After training, each user completes a controlled task in the test environment rather than merely confirming attendance.
Parallel operation needs an end date
Short parallel reconciliation can help finance or critical stock. Indefinite double entry creates two versions of truth and exhausts the team.
Define what is reconciled, who compares totals, which system is primary and when the legacy environment becomes read-only.
Plan the cut-over day
| Control point | What must be defined |
|---|---|
| Cut-off time | Last old-system operation and first new-system operation |
| Migration | Sequence, duration, totals and owner |
| Integrations | Queues, retries, undelivered events and recovery |
| Support | One channel, priority rules and response time |
| Rollback | Specific decision conditions, not a panic return |
| Communication | Who updates users on status and changes |
Manage post-launch issues
Not every question is a critical defect. Use a clear classification:
- P1 — a key operation is stopped or data integrity is at risk;
- P2 — an important scenario has a controlled workaround;
- P3 — inconvenience, report or improvement without operational stop;
- Training — the system follows the agreed rule, but the user does not know the action.
For every issue keep an example transaction, time, role, expected and actual result. “Nothing works” cannot support fast diagnosis.
Stabilisation measures
- share of operations completed without legacy spreadsheets;
- critical-defect volume and closure time;
- records with complete mandatory data;
- differences in control balances and totals;
- time to complete the key scenario;
- manual corrections and their causes.
Do not measure only user logins. A person can sign in daily while performing the entire process elsewhere.
Conclusion
A controlled rollout combines clear requirements, a prototype, representative pilot, verified migration, role-based training, cut-over plan and stabilisation period. Every stage has an output and an exit condition.
Go-live is complete not when the system is available, but when key operations run reliably inside it without double entry. Explore the Business Reactor core.
