One real process live in the first fortnight.
Most implementations fail at the same point: eighteen months of configuration before anybody uses anything, and by the time it lands the business has moved. We run the opposite way round — one genuine process in production early, then the rest of the business added around something that already works.
Wave-based go-live·No big-bang cutover·Rollback at every wave
You are probably here because of one of these.
An implementation programme is the right shape when there is no incumbent system to unpick — you are running on spreadsheets, on something you have outgrown, or on nothing that talks to anything else.
The business runs on exports
Finance reconciles a spreadsheet against three systems every month, and the number everyone argues about is the one nobody can trace to a document.
Growth has outrun the tooling
The process that worked at thirty people is now the reason orders take four days, and every fix is another spreadsheet.
Nobody can answer simple questions
What did that job cost, what is actually in stock, who approved this — all answerable, but only by someone going and looking.
A deadline you did not choose
An audit, a funding round, a regulatory change, or a parent company asking for consolidated numbers by a date.
How an implementation actually runs.
Four phases. The first go-live is inside the first month, and every wave after it is a decision you take again with the previous one already in production.
- 01Weeks 1–2
Map
We take your chart of accounts, item master, and approval limits as they are rather than redesigning them. The output is a written scope with the first wave's process named, not a discovery document.
What exists at the end of it
- Chart of accounts and cost centre structure agreed
- Item, customer, and supplier masters profiled for quality
- Approval limits and segregation-of-duties rules written down
- Wave plan with the first process named and dated
- 02Weeks 2–4
Stand up
The environment is built, masters and open balances are loaded, and the first process is configured end to end. Your people work it on real data before anyone is asked to commit to anything.
What exists at the end of it
- Environment deployed on your chosen infrastructure
- Open balances, open orders, and master data migrated
- The first process configured and worked by your own team
- Permissions and workflow matching your written limits
- 03One period
Run parallel
One full period on both systems, reconciled daily rather than at the end. The reconciliation is the test, and the difference between the two is the thing we work down to zero.
What exists at the end of it
- Daily reconciliation between old and new for a full period
- Every variance explained and closed, not averaged away
- Reports checked against the numbers finance already trusts
- A rollback that has been tested rather than described
- 04Period boundary, then per wave
Cut over and widen
The switch happens at a period boundary with the old system still readable. Then the next wave starts against something that is already in production and already trusted.
What exists at the end of it
- Cutover at a period boundary, old system readable
- Handover documentation and named internal owners
- The next wave scoped with the first one live behind it
- Your team trained to configure, not just to operate
Which modules go live, and when.
This is the part most proposals leave vague. A wave is a set of modules that go into production together because they share a ledger and a set of documents — and each one is a decision you take again with the last already running.
The ledger, and one real process
Accounting first, because everything else posts into it, plus whichever single operational process is causing the most pain. That process is genuinely live — not a pilot in a sandbox.
1 module in this wave
The supply chain
Buying, stock, and selling together, because a three-way match and a valuation are the same mechanism. This is usually where the reconciliation work disappears.
Operations
Whichever of these the business actually runs on — the plant, the job, or the ticket. Costs land on the same ledger rather than in a separate operational system.
People, assets, and the front end
The ones that can safely wait, because they depend on a ledger and a stock position that already work. Payroll goes live at a period boundary, never mid-month.
What you are holding at the end.
Every item below is a thing you own and can use without us. That is the test we apply to the list, because an implementation you cannot run yourself is a subscription to a consultancy.
- A running system on your infrastructure
- Cloud, private cloud, or your own hardware — the deployment target is your decision, not a condition of the licence.
- Migrated data with a reconciliation behind it
- Open balances and open orders tied back to the source system, with the working papers kept rather than discarded.
- Written configuration
- Approval limits, workflow, permissions, and naming series documented as configuration rather than as tribal knowledge.
- Your own people trained to configure
- Not only to operate. The difference decides whether change requests come to us or get done on a Tuesday.
- A tested rollback
- Exercised during parallel running, so it is a procedure rather than a paragraph in a plan.
- The source code and the data
- Open source under the platform, and an export of everything, at any point — including the point at which you leave.
The terms this programme runs on
- First go-live
- One real process in production inside the first month
- Cutover
- At a period boundary, with the old system still readable
- Scope
- Fixed per wave, re-decided before the next one starts
- Rollback
- Tested during parallel running, available at each wave
- Deployment
- Your infrastructure, your region, your choice
- Exit
- Full data and configuration export, at any time
What this programme is usually pointed at first.
Next step