How we work
The Cutover Method
Five phases. Each produces something written, each has a test that decides whether it is finished, and each ends at a gate you can stop at.
Start with discovery
30 minutes, no pitch. We reply within one working day.
The five phases
The exit test matters more than the deliverable. A phase is not finished when we say it is; it is finished when the test passes.
| Phase | What you get | How we know it is done |
|---|---|---|
| 01 Discovery | Written scope, platform recommendation with reasoning, data condition assessment | You can hand the scope to another firm and they could quote from it |
| 02 Data preparation | Cleaned, deduplicated master data. Opening balances reconciled to your ledger | Finance signs off that the opening balances are correct |
| 03 Configuration | System built to the agreed scope, loaded with your real data | Every process in the scope can be run end to end |
| 04 Training and testing | Your team running their own processes in a test environment | Users complete their own tasks unaided, and the issue log is closed |
| 05 Cutover and hypercare | Live system, plus support through the first full reporting cycle | You close a period in the new system without our help |
What a gate actually is
Between each phase there is a decision point. We present what the phase produced against the exit test, and you decide whether to proceed. Three things follow from that, and they are the substance of the method rather than the framing around it.
You can stop, and keep what you have
If you stop after discovery you keep the scope document, the platform recommendation and the data assessment. They are written to be useful to whoever does the work, including a different firm. We would rather lose the remainder of a project than hold a client through inertia.
The next phase is priced before you commit to it
Each phase is quoted at the gate before it, when we know enough to quote it accurately. Discovery is quoted up front because it is bounded. Data preparation cannot honestly be priced until discovery has established what condition the data is in — which is why firms that quote the whole project in the first meeting end up issuing change requests later.
A failed exit test does not silently become the next phase's problem
If testing does not pass, we do not proceed to cutover with a list of open issues and a promise to fix them afterwards. That is the single most common way go-lives become incidents. The phase repeats, and if the cause was our error we carry the cost of the repeat.
Two things we ask of you
The method depends on the client side as much as ours. These are the two requirements we will not proceed without, because projects lacking them fail regardless of how well the software is configured.
A named internal owner
One person, named, who decides when two departments disagree and who maintains the system after we leave. Not a sponsor who approves budget — an owner who makes calls. They get separate, deeper training from everyone else, because their job continues after ours ends.
Access to whoever actually does the work
Discovery conducted only with managers produces a scope describing how work is supposed to happen. We need time with the people doing it, because the difference between those two descriptions is where implementations break.
Why it is structured this way
Most ERP work is billed time-and-materials against an estimate. That arrangement pays the implementer more when the project takes longer, and gives them no incentive to talk a client out of a customisation. It is not dishonesty — it is just what the structure rewards.
Fixed price per phase moves the risk of poor scoping to us, where it belongs. It also means that when we tell you a customisation is not worth the upgrade debt it creates, you can trust that we are not simply protecting a margin.