A different class of decision
Most technology selections can be corrected within a budget cycle. An ERP replacement cannot: the system carries the transactional record of the business, the migration consumes finance and operations capacity for a year or more, and the switching costs after go-live are high enough that the organisation lives with the outcome for a decade. That asymmetry changes how the decision should be run. The questions that sink ERP programmes are rarely about software capability. They are about how much of the business is willing to standardise, who owns the data being moved, and how dependent the organisation becomes on the integrator that holds the configuration knowledge. This playbook works through those questions in the order they need answering. It sits alongside the Before Changing ERP guide, which frames the risks to test before commitment; here the focus is running the decision end to end. Expect the full selection to take four to six months, and treat pressure to compress it as a signal worth examining, because ERP urgency usually has a sponsor and the sponsor usually has a reason.
Step 1: Prove the case for change against the cost of staying
Start with the alternative nobody prices: keeping the current system. Get a written five-year estimate of what staying costs, including extended support on a legacy version, the workarounds finance runs at every close, the integrations held together by one person's knowledge, and what the business cannot do commercially because the system cannot support it. Then write the case for change as specific operational failures, not adjectives. "The system is old" justifies nothing; "we cannot close the month in under twelve working days and cannot give auditors a clean intercompany reconciliation" justifies a programme. List which failures a new ERP actually fixes and which are process problems that will migrate with you, because process failures reimplemented in new software cost millions and change nothing. That distinction is the cheapest insight available at this stage. The output is a one-page case for change with the cost of staying beside it, signed by the CFO, that survives being read aloud to a sceptical board.
Step 2: Decide how much of the business standardises
The most consequential ERP decision has nothing to do with vendors: it is whether the organisation adopts the software's standard processes or pays to recreate its own. Every customisation is a permanent tax, paid again at every upgrade, every integration and every integrator handover. Run the decision process by process. For commodity processes (purchase-to-pay, record-to-report, standard order flows) the default answer is to adopt the standard, and any exception needs a named executive willing to own its lifetime cost. For the handful of processes where the organisation genuinely wins business differently from its competitors, customisation may be justified, but that list is short and should be argued in front of the CFO. Document the stance before the shortlist exists, because vendors and integrators will happily configure whatever they are asked to, and each accommodation looks small at the time. Organisations that skip this step buy a new system and keep their old company.
Step 3: Settle the architecture before the shortlist
Decide whether you are buying a single integrated suite or a core ERP surrounded by best-of-breed satellites for functions such as planning, warehouse management or CRM. The ERP Suite vs Best-of-Breed comparison sets out the trade-offs in full; the short version is that suites concentrate risk and simplify accountability, while best-of-breed architectures fit each function better and multiply integration surfaces. The point here is to decide deliberately, at architecture level, before vendor shortlisting, because a suite vendor will argue everything belongs in the suite and each satellite vendor will argue the opposite. Write down which capabilities must live inside the core (anything transactionally entangled with finance is the usual test) and where the organisation will tolerate an integration boundary, with a named owner for each boundary. This document keeps the shortlist honest, prevents the architecture being decided by whichever salesperson argued last, and gives the eventual integrator a stable target to build against.
Step 4: Choose the integrator with more care than the software
After signature, the integrator matters more day to day than the vendor. Its configuration choices become your operating constraints, and its staff carry the knowledge your business will depend on, which is why integrator dependency needs managing from the first meeting rather than discovering at the first crisis. Run a genuine competition: at least two integrators per shortlisted platform, evaluated on the named delivery team rather than the partner fronting the bid. Ask what those named people are delivering today and when they free up. Ask for change-order history on the last three comparable programmes. Ask how much delivery is onshore and senior versus offshore and junior, and how that mix shifts after month three. The ERP Consulting Firms landscape describes how that market is structured and where the delivery models differ. Contract for named key people with replacement approval rights, a knowledge-transfer obligation with acceptance criteria, and documentation of configuration decisions as a deliverable rather than a courtesy. The test of the step is simple: could a second firm take over the build in month nine without starting again?
Step 5: Rehearse the data migration until the numbers reconcile
Treat migration as a programme within the programme, with its own owner, plan and rehearsal calendar. One trial load proves almost nothing; the discipline is repeated full-volume rehearsals, each with exit criteria that someone accountable signs.
| Rehearsal |
What it proves |
Exit criteria |
| First trial load |
Field mapping and record completeness |
Load failures understood and assigned; no unexplained record loss |
| Second trial load |
Transformation rules and open items |
Trial balance and open orders reconcile to source; exceptions listed and owned |
| Dress rehearsal |
Timing and sequence inside the cutover window |
Full load, reconciliation and sign-off completed within the planned window |
| Cutover |
Nothing new |
Go or no-go decided against criteria agreed weeks earlier |
Step 6: Design the cutover and cost the parallel run honestly
Decide between big bang, phased by site or module, and parallel running, and cost the choice rather than choosing by comfort. Parallel running is the reassuring option that organisations under-cost: every transaction entered twice, a reconciliation team comparing outputs, and staff working two systems while doing their day jobs. If you choose it, define exactly which processes run in parallel, for how many period-end cycles, who reconciles differences and what discrepancy level triggers what response, and put an end date in the plan that requires an explicit decision to extend rather than a drift. Phased cutovers reduce risk per event but stretch the period in which the business runs two systems and the integration team maintains temporary bridges, and those bridges have a way of becoming permanent. Big bang is cheapest and fastest when the rehearsals have earned it, and reckless when they have not. Whatever the choice, the rollback plan must be tested, with a named person empowered to invoke it and criteria agreed in daylight, not at two in the morning on the cutover weekend. Note also that reconciliation sign-off belongs to process owners in finance and operations, who confirm the migrated numbers are theirs; completed load scripts prove nothing by themselves, so book those owners' calendar time months ahead.
Step 7: Build a business case that survives contact
ERP benefit cases inherit whatever optimism the sponsor brought, so stress them deliberately before they reach the board. Run the case through the Business Case Stress Test, paying particular attention to benefits that depend on behaviour change rather than system capability, because those are the lines that erode first. Use the Transformation Business Case Checklist to confirm the costs this category routinely omits: backfilling the finance and operations people seconded to the programme, the migration rehearsals from Step 5, temporary integrations during a phased cutover, integrator travel and change allowance, and post-go-live stabilisation support running well past the hypercare period in the proposal. Hold contingency at steering-committee level rather than inside the programme budget, so releasing it is a visible decision rather than an accounting entry. Present the board a range with the assumptions that drive the spread, not a point estimate, and record which benefits the CFO is prepared to take out of budgets, because a benefit nobody will bank is a hope.
Step 8: Govern with the authority to stop
ERP programmes fail slowly and in public, which makes governance design part of the decision itself. Set stage gates at which continuing is a genuine decision, with the case for change re-read and the delivery evidence examined, not a ceremony with slides. Before each deployment wave, run the Change Readiness Score for the receiving business unit; a warehouse or finance team that scores poorly two weeks before its cutover is a fact the plan must absorb, not a communications problem. Track leading indicators the integrator does not control the narrative on: defect discovery by severity, migration reconciliation gaps, and training completion among the people actually rostered for cutover weekend. Give one steering committee member the explicit job of arguing for delay at every gate, so the option is voiced by design rather than by a brave volunteer. Programmes with a real stop option stop less often, because problems surface while they are still cheap to fix.
When outside challenge is worth buying
An ERP decision concentrates three kinds of blindness at once: the sponsor's commitment to the case for change, the vendor's and integrator's commercial interest in scale, and the organisation's reluctance to reopen a decision this exhausting. Independent challenge pays at the points where those interests align against scrutiny: when the standardisation stance from Step 2 is being eroded accommodation by accommodation, when the integrator's plan assumes rehearsals the timeline cannot hold, and when go-live pressure starts rewriting the go or no-go criteria. Selected senior operators from the Global Board who have owned ERP outcomes as CFOs, COOs and programme sponsors can read a cutover plan and a benefits case and say which parts they have personally watched fail. Against a programme measured in years and millions, that challenge costs almost nothing, and it is one of the few inputs in the entire process with no stake in proceeding.
