SAP implementation timeline: phase durations and 5 mistakes

An SAP implementation takes 6 to 9 months on GROW with SAP and 9 to 18 months on RISE with SAP, in my experience. Moving off SAP ECC takes 12 to 18 months for a brownfield conversion or a selective data transition, and 18 to 24 months for a greenfield implementation.

Short answer: lock the date at the end of Explore, not at kickoff, and add a 15 to 20 percent buffer beyond the vendor estimate. Start data work in Discover, because data migration takes 30 to 40 percent of the implementation effort. Each extra month of delay costs at least six figures in consulting fees alone.

This guide is for programme directors and sponsors building a plan or rescuing one. It covers how long, not how: for what each phase does and who does it, read my step-by-step guide to SAP implementation.

On a European manufacturing programme in 2024, I met a project manager whose SAP project was six months behind schedule. After resetting strictly on SAP Activate's phases, they finished the remaining work in four months.

His words: "Having clear phases with specific deliverables made all the difference. We always knew exactly what we needed to do next."

Deployment model changes the SAP implementation timeline more than any other choice. These are the ranges I plan from:

Starting point and target	Typical timeline	What sets the pace
GROW with SAP (SAP Cloud ERP, public edition)	6 to 9 months	Standard processes only; extensions on released APIs
RISE with SAP (SAP Cloud ERP Private)	9 to 18 months	Scope, number of extensions, data volume
ECC brownfield conversion	12 to 18 months	Custom code, simplification items, testing
Greenfield implementation from ECC	18 to 24 months	Process redesign, change load on users
Selective data transition	12 to 18 months	Data scoping and specialist tooling

For comparison, an SAP product expert who reviewed hundreds of public edition projects puts the typical go-live at five to seven months. SAP's GROW Fast offering, launched in early 2026, targets two to four months on a fixed scope. I plan GROW programmes at 6 to 9 months because data, decisions and training take the time the software does not.

On RISE, SAP runs the infrastructure, which removes some Prepare work. It does not remove data, testing or change effort. The ECC to S/4HANA migration guide explains how to choose between brownfield, greenfield and selective.

SAP Concur, the travel and expense product, is a separate cloud product with its own project. Plan it as its own workstream with its own integration to S/4HANA finance, not inside the S/4HANA phase plan.

Where budgets and dates break

The biggest mistake I see is not planning properly at the start. Dates and budgets overrun in Explore, when the list of workflows, reports, interfaces, conversions, enhancements and forms (WRICEF) grows and the vendor, not the client, controls scope.

My SAP implementation cost breakdown shows how that can turn into a 50 percent overrun. The timelines that hold share three things: realistic buffers, assumptions validated before lock-in and quality gates treated as hard stops.

Five mistakes account for most overruns. Each one is predictable, and each has a countermeasure.

Mistake 1: setting deadlines before scope is understood

On a GCC retail programme in 2023, the client promised its board a nine-month implementation with no buffer. When data migration took longer than expected, they missed the deadline by three months and the executives lost confidence in the team. I told them flat: that timeline was too aggressive.

The fix: lock the timeline after Explore, not at kickoff, and tell the board that upfront. Build in a 15 to 20 percent buffer beyond the vendor estimate.

Mistake 2: treating data migration as a workstream that starts late

Most teams appoint the data migration lead late and under-resource the work. Initial data assessments almost always understate the problem, and three months of cleanup under live-system pressure follows.

The fix: start data profiling in Discover, not Realize. Run a full mock migration in Realize before integration testing starts. My piece on why SAP data migration fails covers the mock cycle in detail.

Mistake 3: skipping quality gates under schedule pressure

The gate between Realize and Deploy is the one teams most often skip, because the pressure to "just go live" peaks there. Skipping quality gates to "stay on schedule" causes bigger delays later.

The fix: write measurable exit criteria into the project charter and let the steering committee enforce them. I use a three-day close rehearsal as the readiness gate on every programme. More on gate design in my SAP quality gates guide.

Mistake 4: training users two months before go-live

On a GCC retail programme in 2024, the client trained all its users two months before go-live. By launch day, most had forgotten how to use the system. We put job aids at every workstation and doubled floor support.

The fix: land training two to three weeks before go-live, and use power users as trainers because people learn from colleagues they trust. My SAP training strategies article has the full approach.

Mistake 5: scheduling go-live during peak business cycles

Hershey went live on its SAP R/3, Siebel and Manugistics system in July 1999, three months later than planned and straight into the Halloween order season. Its CEO told analysts the problems would stop Hershey delivering $100 million worth of Halloween orders.

The fix: map peak cycles for every business unit affected, including month-end and quarter-end close. Go live in a low-volume window even if it means a six-week shift. The shift is recoverable, but a failed go-live in peak season is not.

SAP Activate has six phases, and they are the skeleton for any S/4HANA plan, cloud or on-premise. The durations below are planning starting points for a single programme, not promises.

1. 1Discover2 to 4 weeks. Exit: signed scope and success criteria
2. 2Prepare3 to 6 weeks. Exit: charter approved, resources in writing
3. 3Explore4 to 8 weeks. Exit: gap decisions owned, timeline locked
4. 4Realize8 to 16 weeks. Exit: mock migration passed, integration tests closed
5. 5Deploy2 to 4 weeks. Exit: UAT sign-off, close rehearsal, go/no-go
6. 6Run4 to 8 weeks of hypercare. Exit: defects below threshold, support signed

This is the phase table I start every plan from:

Phase	Typical duration	What happens	Exit gate before moving on
Discover	2 to 4 weeks	Business case, scope, deployment choice (public cloud, private cloud or on-premise)	Signed scope and measurable success criteria
Prepare	3 to 6 weeks	Team onboarding, governance, system landscape, baseline plan, risk register	Charter approved, named decision-makers per module, written resource commitments
Explore	4 to 8 weeks	Fit-to-Standard workshops, gap log, WRICEF inventory	Gap decisions recorded with owners; timeline locked
Realize	8 to 16 weeks	Configuration, development, unit and integration testing, mock migrations	Mock migration passed; integration tests closed
Deploy	2 to 4 weeks	User acceptance testing, cutover rehearsal, end-user training, final load	UAT sign-off, close rehearsal passed, go/no-go
Run	4 to 8 weeks hypercare	Floor support, daily triage, handover to support	Open defects below agreed threshold; support transition signed

Where the time actually goes

Discover gets rushed. Teams set a deadline before they understand scope and skip measurable success criteria, such as "cut month-end close by three days".

Prepare is where technical delays start on-premise, because the client and partner build the infrastructure. Get resource commitments in writing. Verbal availability evaporates.

Explore is where record-keeping matters. Six months later nobody remembers why returns are handled a particular way unless the decision and its owner were written down.

Realize is the longest phase and where most overruns land, usually because Explore produced an optimistic gap list. Your first mock migration will fail, and you need it to fail in testing, not production.

Deploy needs a cutover plan with exact steps, times and owners. "Migrate data" is not a step.

On a US healthcare programme in 2023, the client was three months behind schedule and facing a $2 million budget overrun. We reset using SAP Activate's Fit-to-Standard workshops. The team found 28 processes they could run with zero customisation.

Their project manager's words: "We wasted months designing things SAP already had built." They were back on schedule within six weeks.

On a European retail programme in 2024, the client found that 70 percent of its needs were met by standard SAP processes. It had been planning extensive customisations until it saw the system in action.

Clean core sharpens this. On the public edition, standard processes are the only option and extensions sit on SAP BTP or released APIs. On the private edition and on-premise you can still modify, but when every gap needs an extension decision with a cost attached, the customisation conversation gets more honest.

Industry adds its own drag. These ranges cover a full multi-site S/4HANA enterprise programme, which is why they run longer than a single RISE deployment of 9 to 18 months:

Industry	Planning range	What pushes it out
Manufacturing	14 to 20 months	BOM and routing quality, MRP tuning, QM requirements
Retail and consumer goods	12 to 18 months	POS integration, master data volume, peak season windows
Pharmaceuticals	16 to 22 months	GxP validation, batch traceability, serialisation
Utilities	15 to 20 months	Device management, billing rate structures, GIS and SCADA integration
Public sector	18 to 24 months	Fund accounting, procurement regulation, approval overhead, data residency
Automotive	16 to 22 months	Just-in-time supply chain, engineering change control
Aerospace and defence	20 to 26 months	Government reporting, programme accounting, secure supply chains
Oil and gas	18 to 24 months	Joint venture accounting, asset-heavy operations
Financial services	14 to 20 months	Segregation of duties role design, regulatory validation

What AI tools change, and what they do not

SAP Joule for Consultants reached general availability in 2025. It answers configuration questions from SAP's own knowledge base, including SAP Notes, and explains ABAP code. SAP Build Code, generally available since March 2024, generates Java and JavaScript extension code on SAP BTP with Joule.

Both help individual consultants and developers. Neither changes how long workshops, decisions, data cleansing or user acceptance take. Plan with them, but do not take weeks out of the plan until your own team has measured the effect.

These are the risks I put on the weekly programme agenda. Each one moves dates if it is left for the monthly steering committee.

1. Late scope changes. Lock scope at the end of Explore. After that, a change control board approves every change with its timeline and budget impact attached.
2. Data quality. Most companies skip a data assessment during planning. Poor data is the most consistent cause of failed mock migrations.
3. Resource bottlenecks. Get written commitments from department heads for named people and dates. Train a backup for every critical role.
4. Decision delays. Escalate scope disagreements within 48 hours. Do not let decisions queue for monthly reviews.
5. Late change management. Start talking to end users in Prepare, not two weeks before go-live.

On tooling, SAP Cloud ALM is SAP's platform for implementation management. SAP Solution Manager 7.2 mainstream maintenance ends at the end of 2027, with extended maintenance for selected functions to 2030. SAP Best Practices Explorer was retired in 2023, and its process content now lives in SAP Signavio Process Navigator.

How long does an SAP S/4HANA implementation take?

In my experience 6 to 9 months on GROW with SAP (public edition) and 9 to 18 months on RISE with SAP (private edition). From ECC, a brownfield conversion or selective data transition takes 12 to 18 months and a greenfield implementation 18 to 24 months.

How long does each SAP Activate phase take?

As a planning start: Discover 2 to 4 weeks, Prepare 3 to 6 weeks, Explore 4 to 8 weeks, Realize 8 to 16 weeks, Deploy 2 to 4 weeks and Run 4 to 8 weeks of hypercare. Realize stretches most on larger programmes.

How does RISE with SAP affect the timeline?

RISE moves infrastructure responsibility to SAP, which removes some Prepare-phase work. It does not shorten data migration, testing, training or decision-making, which is where most of the time goes. Clean core discipline can shorten Realize if it stops custom development before it starts.

How much buffer should an SAP implementation timeline include?

Build in a 15 to 20 percent buffer beyond the vendor estimate. Lock the date at the end of Explore, when scope and gaps are known, and tell the board that before kickoff.

How can I shorten an SAP implementation timeline?

Run Fit-to-Standard rigorously, because every customisation you avoid saves weeks. Start data cleansing in Discover and dedicate business resources full time instead of borrowing them part time. Prepare the cutover plan during Realize rather than after it.

Should I choose a big bang or phased SAP rollout?

Big bang puts everything live at once. It is faster overall and riskier, and suits smaller scope or organisations with strong change management. Phased rollout goes by module, site or business unit, is lower risk and longer, and suits large multi-entity groups.

What are the most common causes of SAP project delays?

Uncontrolled change requests, data quality surprises, late change management, third-party integration failures, losing key people mid-project and slow steering committee decisions. The one that surprises most teams is data quality. Everyone assumes legacy data is clean, and it almost never is.

How long is hypercare after SAP go-live?

Plan four to eight weeks of hypercare: floor support, daily issue triage and performance monitoring. After that, the system moves to an application support team or an internal centre of excellence.