ERP Implementation: A Practical Guide for the Business Side

The phases, and where the time really goes

Discovery and fit-gap design establish how your processes will work in the new system. This phase usually takes longer than people expect and is worth every week, because every unresolved design question becomes a change request later at several times the cost.

Configuration and build is the part everyone pictures when they think of implementation, and it is rarely the longest. Migration, testing and training run alongside it and often outlast it.

Cutover is a weekend or a month-end, depending on strategy. Hypercare follows go-live and runs until the business has been through a complete reporting cycle without the supplier in the room.

A planning heuristic that holds up: whatever you have allowed for migration and testing, the first serious attempt at either will tell you it was not enough. Build that discovery into the schedule early rather than finding it in the final month.

Implementations fail on data and people, not software

Modern ERP products work. When a project goes badly, the post-mortem rarely finds that the software could not do the job. It finds that the data loaded into it was wrong, or that the people expected to use it were trained the week before go-live and went back to their spreadsheets.

Both failures have the same root: they are business responsibilities that look like IT responsibilities. A supplier can build the migration tooling, but only your team can decide what an ambiguous historical record should become. A supplier can deliver training, but only your managers can make using the system the way work is done.

The practical consequence is that an implementation needs named business owners with real time allocated — not a steering committee that meets monthly, but people whose day job includes this for the duration.

Data cleansing: the work nobody budgets for

Every long-running business accumulates duplicate customers, suppliers with three spellings, products that were discontinued but never deactivated, and stock figures that have quietly diverged from reality. None of this is visible until you try to move it.

Cleansing is not a technical task. Deciding which of four similar customer records is the real one, what to do with an open purchase order from a supplier who no longer exists, or whether a negative stock balance should be written off is business judgement, applied thousands of times.

Start it early and run it in parallel with design. The most useful first step is a profiling pass over the existing data that counts the problems — duplicates, missing mandatory fields, orphaned references — so the scale is a number rather than a worry.

Decide explicitly how much history moves. Full transactional history is expensive to migrate and reconcile; open items plus balances, with the old system kept available read-only for reference, is often the better trade.

Parallel running and cutover

Parallel running means operating both systems over the same period and comparing results. It is the most thorough way to build confidence and it roughly doubles the workload for the teams doing it, which is why it is usually limited to the highest-risk areas rather than applied across the board.

A phased cutover brings modules or sites live in sequence, which reduces the blast radius of any single problem but requires temporary integration between old and new while both are running. A big-bang cutover avoids that complexity and concentrates all the risk into one weekend.

Whichever you choose, the decisions that matter are the unglamorous ones: the cut-off time after which no transactions go into the old system, who signs off that the opening balances reconcile, and what specifically would trigger a rollback. Write the rollback criteria before the weekend, not during it.

What hypercare should cover

Hypercare is elevated support immediately after go-live, with faster response times and people who know your configuration available directly rather than through a general queue. Its purpose is to stop small problems becoming workarounds that calcify into permanent habits.

The right duration is defined by cycles, not by weeks. It should cover at least the first full month-end close, and for most businesses the first quarter-end and the first statutory filing produced from the new system. Those are the moments when gaps in the configuration surface.

Agree what happens at the end of it. Hypercare that simply stops leaves the business without a route for the issues that have not surfaced yet; a defined transition into ongoing support, with the open items listed, avoids that cliff.

Early warning signs

Projects give plenty of notice before they fail. The signals are visible months earlier than the crisis, and almost all of them are schedule or ownership problems rather than technical ones.

• Design decisions are still open while build has started. Every one of them is a change request waiting to happen.
• No one is named as the owner of data migration, or the named owner has no time allocated.
• User acceptance testing is being done by the supplier or by IT rather than by the people who do the work.
• Training is scheduled for the fortnight before go-live, which means it is really scheduled after go-live.
• Questions from the supplier are going unanswered for weeks, and the project plan has not moved to reflect it.
• The phrase 'we will configure that later' has appeared more than twice in the same area.