ERP Implementation Timeline: What UK Businesses Should Realistically Expect

Ask a vendor how long an ERP implementation takes and you will get a number that assumes everything goes well. Ask a business that has completed one and you will get a longer number and a slightly weary expression.

The gap between those two answers is not dishonesty. It is that the vendor is estimating the work they control, and the business experienced the work nobody costed — cleaning fifteen years of data, discovering that three departments record the same thing differently, and persuading people to abandon a spreadsheet they have relied on since 2014.

This guide covers the realistic version.

Why ERP Implementations Take Longer Than Expected

Data migration complexity

Consistently the most underestimated part of any ERP project, and the one most likely to delay go-live.

The problem is rarely moving the data. It is discovering what state the data is in. Duplicate customer records created by three people entering the same account differently. Products with inconsistent units of measure. Historic transactions referencing suppliers that no longer exist. Fields used for something other than their label because somebody needed somewhere to put a note in 2019.

None of this is visible until someone attempts to map it into a structured system, at which point it becomes a business decision rather than a technical one — and business decisions need people who are busy.

Budget four to eight weeks for migration on a mid-sized project, and expect the cleansing work to reach into the operational team rather than staying with the implementer.

Business process mapping and documentation

Most businesses do not know how they work. They know how they think they work, which is a different document.

Mapping reveals the exceptions: the customer who gets invoiced differently, the product line with its own approval route, the manual step somebody added to catch a recurring error. Every exception is a decision — encode it, standardise it away, or handle it outside the system — and every decision needs someone with the authority to make it.

This phase is where projects either establish a solid foundation or quietly accumulate the ambiguity that surfaces six months later as scope change.

Change management and user adoption

The part that is genuinely nobody's job unless it is explicitly made someone's.

Staff who have used the old process for a decade are fast at it, and the new system will make them slower for a while. That is not resistance, it is arithmetic, and treating it as resistance makes it worse.

Implementations that allocate no time to training, no allowance for the productivity dip, and no mechanism for capturing complaints during the first weeks tend to produce a system people work around rather than with — which is the most expensive possible outcome.

Integration with existing systems

Every integration is a dependency on somebody else's timeline, documentation and goodwill.

Modern systems with documented APIs and sandboxes are straightforward. Legacy systems requiring file exchange, direct database access or vendor cooperation are not, and the vendor's availability is outside your control. Warehouse hardware, EDI connections with large customers, and carrier integrations all carry their own approval and testing cycles.

Count them honestly at the outset. Each meaningful integration adds one to three weeks, and the difficult ones add considerably more.

Typical ERP Implementation Phases

The durations below assume a mid-sized UK project. Scale them down for a focused small-business build and up substantially for enterprise.

Phase 1 — Discovery and requirements (4–8 weeks)

Process mapping, requirements gathering, integration audit, data assessment and prioritisation. Workshops with each functional area, followed by written specification.

The temptation is to compress this phase because nothing visible is being built. Resist it. Discovery is where cost and timeline are actually determined, and every week saved here typically costs three later.

The deliverable should be a specification you own and understand — not a vendor document written in vendor language.

Phase 2 — System design and architecture (4–6 weeks)

Data model, system architecture, integration design, permissions model, interface design and technical planning. For packaged implementations this is configuration design rather than build design, but the work is comparable.

This phase should end with agreement on what the first release contains and what it deliberately does not.

Phase 3 — Development and build (8–24 weeks)

The widest range, because it scales directly with scope. A two-module system sits at the bottom; a comprehensive multi-site build sits well above the top.

Delivered properly, this phase is iterative rather than monolithic: modules arrive in reviewable increments, the business sees working software every few weeks, and the direction can be corrected while correction is still cheap.

A build phase with no visible output until the end is a warning sign rather than a methodology.

Phase 4 — Data migration and testing (4–8 weeks)

Migration scripts, trial runs, reconciliation, and then several rounds of testing — functional, integration, and user acceptance testing with real people doing real tasks.

Trial migrations should run at least twice before the real one. The first reveals the data problems, the second confirms they were fixed, and the third — on the weekend of go-live — should hold no surprises.

UAT is where most timeline slippage becomes visible, because it is the first point at which the people who actually do the work see the system. Plan for a round of fixes afterwards rather than treating UAT as a formality.

Phase 5 — Training and change management (4–6 weeks)

Role-based training rather than a single session for everyone, documentation, quick-reference material, and identified superusers in each team who can help colleagues without escalating everything.

Run this close to go-live. Training delivered three months early is forgotten by the time it matters.

Phase 6 — Go-live and hypercare (ongoing)

Cutover, then an intensive support period of typically four to eight weeks during which issues are triaged and fixed quickly.

Expect a productivity dip. Plan for it operationally — avoid going live during your busiest month, avoid year-end, and make sure the finance team is not attempting a period close in week one.

Realistic Timelines by ERP Type

Small business custom ERP: 4–6 months

Two or three modules, limited integrations, modest data volumes, under twenty-five users. First module frequently in production within three months, with the rest following.

Mid-size business ERP: 6–12 months

Four to seven modules, several real integrations, meaningful data migration, twenty-five to a hundred users. Staged delivery means the business is getting value from month four onward rather than waiting for the end.

Enterprise ERP: 12–36 months

Multi-site or multi-entity, comprehensive functional coverage, extensive integration, phased rollout by site or region. Programmes at this scale are managed as portfolios of releases, and the outer end of that range is not unusual for genuinely large organisations.

Our custom ERP development work is deliberately staged across all three bands, so the highest-value module reaches production first rather than everything arriving at once.

How to Accelerate Your ERP Timeline

Stage the delivery. The single most effective accelerant. Identify the module that solves the most painful problem, build it, put it live, and continue. The business gets value in month three instead of month twelve, and the remaining scope benefits from what you learn.

Clean your data before you start. This work has to happen regardless, and it can happen in parallel with discovery rather than blocking migration. Starting it early routinely saves a month.

Appoint an internal owner with authority. Projects stall waiting for decisions. Someone needs to be able to say "we will standardise on this process" without convening a committee, and they need enough time allocated to do it.

Reduce the first release rather than the phases. Compressing discovery or testing to hit a date does not save time, it defers cost. Cutting scope does save time.

Decide integrations early. Third-party dependencies have their own lead times, and discovering in month five that a vendor needs eight weeks to provision API access is a common and avoidable delay.

Do not go live in your busy season. Obvious, routinely ignored, and the cause of a great deal of avoidable pain.

Common Causes of ERP Delays (And How to Avoid Them)

Scope creep. The most common. Every "while we're at it" adds time. Maintain a list of things that are explicitly in release two, and put requests on it rather than arguing about them.

Decisions waiting on unavailable people. Book the decision-makers into the project calendar at the outset. A three-day delay repeated twenty times is a two-month overrun.

Discovering data problems late. Assess data quality in week one, not week twenty.

Underestimating testing. UAT with real users doing real tasks always produces findings. Plan a fix cycle rather than hoping it does not.

Treating training as optional. A technically successful implementation that people do not use has failed.

Choosing the wrong partner. Partner quality varies more than product quality and matters more to the outcome. Ask for references from projects of similar size that went badly, and how they were handled.

No allowance for the productivity dip. It will happen. Businesses that plan for it recover in weeks; businesses that do not spend that time in crisis meetings.

The customer-facing side follows the same pattern and the same phasing — our custom CRM development projects are scoped and staged identically, and are frequently delivered alongside.

FAQ

How long does an ERP implementation take in the UK?

Four to six months for a focused small-business system, six to twelve for a mid-sized business with several modules and integrations, and twelve to thirty-six months for enterprise programmes with multi-site rollout. Staged delivery puts the first module live considerably sooner in all three cases.

What are the phases of an ERP implementation?

Discovery and requirements, system design, development or configuration, data migration and testing, training and change management, then go-live and hypercare. Discovery and testing are the phases most often compressed and the ones where compression costs most.

Why do ERP implementations fail?

Rarely for technical reasons. The usual causes are scope creep, data problems discovered too late, decisions stalled waiting on unavailable people, inadequate training, and no allowance for the productivity dip after go-live.

How can we speed up an ERP implementation?

Stage the delivery so the highest-value module goes live first, begin data cleansing immediately, appoint an internal owner with real decision-making authority, resolve third-party integration dependencies early, and reduce the first release rather than compressing discovery or testing.

How long does ERP data migration take?

Typically four to eight weeks on a mid-sized project, though the driver is data quality rather than volume. Run at least two trial migrations before the real one, and start assessing data condition in the first week of the project.

When should we not go live?

During your busiest trading period, at year-end, during a period close, or when key staff are on leave. The productivity dip in the first weeks is real, and the operational timing of go-live affects how painful it is more than almost any technical decision.