The first question every retailer asks in a selection process is "how long will it take". It is also the question every vendor answers most creatively. The honest answer depends on three things you control and one thing you almost certainly have not measured. This article gives the ranges from recent UK engagements, what drives the differences, and how to plan a calendar that the business can actually keep.

The realistic ranges

From contract signature to go live, retail ERP implementations in my experience land in three bands:

  • 6 to 9 months: a small or mid sized retailer, a clean product master, a modest module scope, one or two channels connected, and a team freed from daily duties to run the project.
  • 9 to 14 months: the common case. Several channels, a warehouse to configure, some data cleaning, and the normal reality of a busy retail team doing the project alongside the day job. The question of whether you need a separate warehouse system is what moves projects between these bands.
  • 14 to 18 months plus: customisations, many integrations, a large product range, or a data migration discovered late. The custom build guide explains why customisation is the fastest route to this band.

The industry context matters too. The Internet Retailing insights coverage of UK retail technology programmes regularly reports projects running over their original dates, and the pattern is consistent: the overruns are rarely software problems, they are data and scope problems.

What the phases actually take

A typical timeline breaks down roughly like this:

  • Discovery and design, 6 to 10 weeks. Process workshops, requirements confirmation, solution design, integration design. This phase is where scope is decided, and cutting it saves two weeks and costs three months later.
  • Data preparation, 8 to 16 weeks. Extraction, cleaning, mapping and validation. This runs in parallel with configuration and is almost always the critical path.
  • Configuration and build, 8 to 14 weeks. The vendor configures the platform, builds integrations and sets up reporting.
  • Testing, 6 to 10 weeks. Integration testing, user acceptance testing, dress rehearsal and cutover rehearsal. Testing is the phase that reveals what the other phases actually produced.
  • Cutover and stabilisation, 2 to 4 weeks. Go live, hypercare, fixes and the first month end on the new system.

Note that data preparation and configuration run together, which is why a project can be on schedule until week twenty and then stop dead. The configuration finishes on time. The data does not.

The three drivers nobody controls

Three factors push every implementation toward the long end, and they are worth surfacing before the contract is signed:

  • Channel count and integration depth. Each channel is an integration project with its own testing cycle. The channel integration guide shows the five flows per marketplace; multiply by your channel count and you have the real integration timeline.
  • Customisation. Every customisation adds design, build and regression testing to every future upgrade. The cheapest implementations are the ones where the business accepted standard process.
  • Team availability. The retailer's own team does most of the data work and all of the acceptance testing. If key people are also running the business, the calendar stretches.

Data is the timeline

If there is one predictor of implementation duration, it is the state of the product master and stock history. The stock accuracy article describes how records drift in a running business, and the implementation inherits every year of that drift. Retailers who start data cleaning during selection, before the vendor is even chosen, routinely finish two to three months faster than those who discover the data problem after configuration starts.

There is a documented industry pattern here: research covered by Modern Retail shows how poor inventory data surfaces as out of stocks and lost sales in UK retail, and the same poor data surfaces as implementation delay before that. Clean the data first and both problems shrink.

Where programmes slip

The slippage points are predictable because they are process failures, not technical ones. Scope additions during configuration, the classic "while we are in here" request, add weeks each time. Acceptance testing scheduled for the Christmas season, which every retail calendar should forbid. A cutover date chosen for the quarter end instead of operational readiness. And the silent one: key users too busy to test, approving changes they never exercised. The implementation pitfalls guide covers these patterns in detail, and each one maps to a calendar impact you can quote in the project plan.

Planning the calendar honestly

Three planning habits keep timelines honest. First, add a buffer to the vendor's date before presenting it to the board; 15 to 20% is realistic, not pessimistic. Second, schedule the go live around the retail calendar, not the vendor's quarter; a go live in October for a seasonal business is a self inflicted wound, as the peak season article makes clear. Third, define what done means in writing: which channels, which modules, which reports, tested against which acceptance criteria. The vendor questions include the acceptance clause that makes that definition contractual.

The closing point from client work: the retailers who ask "how long" are asking the right question, and the honest answer is usually "longer than you want, shorter than a failed project". Plan for the longer end, protect the data work, and the timeline becomes something the business can rely on instead of something it survives. If you are still early in the journey, the readiness checklist will tell you whether this is the right moment to start.