Choosing and implementing an ERP: from requirements and demos to go-live

Every ERP demo works. The consultant knows the system, the sample data is spotless and an order runs from quote to invoice in a few clicks. Your own orders are messier: half a delivery leaves from one warehouse and the rest next week from another, one customer has its own price list, a damaged pallet needs a credit note. Choosing an ERP comes down to testing the system against that reality before you sign, then implementing it without the project drifting.

This guide follows the route from the first warning signs to a calm go-live.

An order reserves stock straight away, creates a picking task for the warehouse and, after delivery, becomes an invoice and a ledger entry, without anyone retyping it. Accounting software records what happened; an ERP steers the work itself, and the books follow.

Accounting software with a few connected apps takes many businesses a long way (see choosing accounting software), until links and spreadsheets cost more time than the work they support:

• Double entry: orders, stock or invoices move between systems by hand or by export file.
• No current picture: stock or margin per order takes an afternoon of reconciling.
• Growth gets stuck: a second warehouse, entity or country does not fit the set-up.
• Knowledge in one head: one colleague knows how the spreadsheets hang together.
• Demands from outside: customers, a parent company or a lender want reports or traceability you cannot deliver.

If several apply, explore the options; sometimes an industry package or a better integration is enough.

Describe each end-to-end process: how it runs today, where it pinches and how it should run. For most businesses that means order to cashOrder to cashThe end-to-end process from a customer's order through delivery and invoicing to the payment received., procure to pay (from purchase order to paid supplier), plan to produce or project to invoice, and record to report (from entry to monthly close). Give every process two or three scenarios with your own data and exceptions, and mark each requirement must, should, could or not this time.

Microsoft's implementation guidance for its own business software agrees: judging the fit on business processes reduces the risk of missing requirements, and meeting needs through configuration, rather than writing detailed requirements based on the old system, reduces customisation (source: Microsoft, February 2026).

1. 1
   From long list to shortlistCut on the musts and on finding an implementation partner that knows your industry, then send three or four candidates your request for proposal with your processes and scenarios.
2. 2
   Scripted demosEvery vendor gets the same scenarios and your sample data in advance, and shows them live with your key usersKey userAn employee who knows a process inside out and represents their department in design, testing and training. in the room. What is told but not shown counts as missing.
3. 3
   Reference callsSpeak to customers of similar size, implemented by the team that would work for you, and ask what disappointed them.
4. 4
   Total costCompare the total cost of ownershipTotal cost of ownershipAll costs of a system over its life, from licences and implementation to support, upgrades and the hours of your own staff. over at least five years: licences or subscriptions, implementation, integrations, migration, training, support, upgrades and internal time. Get current prices from each vendor in one format.
5. 5
   Vendor and partnerSoftware maker and implementation partner are often different companies: judge both, and name the key consultants in the contract.

The largest cost never shown on a quote is internal time: key users design, test and train next to their day job, so arrange cover before the project starts. Choosing and managing the partner is covered in choosing an IT partner.

The cutover and the go/no-go decision

The cutoverCutoverThe planned switch from the old system to the new one, including the final data load. usually takes a weekend of less than 48 hours in which neither system can be used; rehearse it in a test environment with the same data, tools and people until it runs smoothly (source: Microsoft, February 2024). Decide beforehand who takes the go/no-go decision and on which criteria, such as the number of open issues you accept, and keep a rollback plan ready (source: Microsoft, February 2024). Avoid the year-end close and your peak season.

In research with the University of Oxford covering more than 5,400 IT projects, McKinsey found that large IT projects, those with an initial price tag above $15 million, ran on average 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted (source: McKinsey, October 2012). Software projects carried the highest risk of cost and schedule overruns (source: McKinsey, October 2012).

The study is older and many ERP projects are smaller, but the causes still apply. McKinsey groups them in four dimensions, and failing at the first two typically causes about half of all cost overruns (source: McKinsey, October 2012). In an ERP project they look like this:

Related guides are listed in the IT and data overview.