Ask three firms for an SAP project timeline and you will get answers from four months to three years, each delivered with total confidence. None of them are lying. They are timing different races, and nobody on the sales side is in a hurry to explain which race you are actually in.
This post reconciles the numbers. The short quotes describe small, single-entity rollouts or purely technical conversions. The long ones describe full transformation programs across multiple countries and legacy systems. Both are real. What matters is knowing which clock your project runs on before you build a business case around the wrong one.
The question has a deadline attached. SAP ends mainstream maintenance for ECC (ERP Central Component, the legacy suite most SAP customers still run) in 2027, which means every ECC shop is now doing this math. If you are still sorting out what S/4HANA actually is, start with the plain-English primer and come back. The numbers below will still be here.
Why SAP Project Timeline Answers Range From 4 Months to 3 Years
Pull up any page of search results on this topic and the contradiction is immediate. One agency guide promises 3 to 6 months for small and mid-sized projects. Another puts small businesses at 6 to 12 months and large enterprises at 12 to 18 or more. Analyst-flavored guides put a full ECC-to-S/4HANA move at 18 to 36 months for a large enterprise. SAP itself has previously estimated a reimplementation at 12 to 18 months minimum.
The spread looks like disagreement. It is mostly a scoping trick: each number starts and stops the clock in a different place. Our S/4HANA migration guide walks the whole decision tree; here is the timeline piece of it.
| Quoted Range | Who Quotes It | What the Clock Actually Includes |
|---|---|---|
| 3-6 months | Implementation agencies pitching small and mid-sized work | A single entity, near-vanilla scope, and usually just the build phases. Preparation, data cleanup, and post-go-live support sit outside the quote. |
| 6-12 months | Vendor guides for small companies; brownfield conversion estimates | A technical system conversion or a small-company rollout, kickoff to go-live. Your processes come along unchanged. |
| 12-18 months | SAP’s own historical estimate for a reimplementation; mid-market program guides | A real mid-market program end to end: preparation, fit-to-standard work, build, testing, cutover, and early support. |
| 18-36 months | Enterprise analyst guides and academic studies | A multi-entity, multi-country ECC transformation with process redesign, heavy data work, and phased go-lives. |
Bottom line: when a partner quotes a timeline, ask two questions. What starts the clock, and what stops it? A “9-month migration” that excludes data remediation and hypercare is a 15-month project wearing a 9-month badge.
The On-Time Numbers Partners Don’t Put in the Deck
Every proposal has a timeline. Almost none of them cite the on-time statistics for this class of project, and once you see those numbers you understand why.
A 2025 study by the consultancy Horvath found that only 8 percent of S/4HANA projects finished on schedule, with the average initiative running about 30 percent longer than planned. The phases that get underestimated are always the same two: testing and data migration. ISG, an IT research firm, surveyed 200 senior decision-makers at large global companies in early 2026 and found nearly 60 percent of SAP migration projects delayed and over budget.
“A lot of the delays are caused by people, not necessarily the technology,” is how ISG principal analyst Michael Dornan put it. Slow decisions, scope changes, and fear of touching over-customized legacy processes stretch more schedules than any technical failure does.
The cloud benchmarks tell the same story from a different angle. An AWS analysis of SAP migrations puts planning at 8.8 months on average and execution at 17.4 months, with the average cost of business disruption around $1.5 million on top of a similar consulting bill. Planning alone, in other words, often takes longer than some agencies claim the entire project will.
Named cases land in the same range. Rizing’s published case study of a retail grocery migration to S/4HANA clocks roughly 18 months from the first sandbox migration attempt to production, and that span held three integration test cycles, user acceptance testing (UAT, the phase where the business signs off), three go-live dress rehearsals, and what the consultant on record calls “a lot of code remediation.” That is what a competently run brownfield project looks like. Nobody sprinted.
Here is the sentence a partner cannot put in a proposal: the timeline on the cover page is a sales document. If only 8 percent of these projects finish on schedule, the honest plan takes the estimate, adds 30 percent, and names the two phases where the overrun will hide. Your partner has seen the same studies. The deck stays optimistic anyway, because the deck that says 20 months loses to the deck that says 14.
And the clock is not generous. Gartner data reported in early 2026 showed 39 percent of SAP’s roughly 35,000 ECC customers had still not migrated as of late 2024, and 8 percent plan to ride ECC straight past the 2027 support deadline. The longer the holdouts wait, the more they compete for the same delivery teams.
Greenfield, Brownfield, Bluefield: Which Path Takes How Long
Your migration approach moves the timeline more than any other single decision, so define the terms first.
- Greenfield: a fresh S/4HANA implementation. You rebuild processes from standard and migrate only the data you choose. It is a reimplementation, not an upgrade.
- Brownfield: a system conversion. Your existing ECC system, processes and customizations included, is converted to S/4HANA in place.
- Bluefield (selective data transition): the hybrid. A new system, but with selected data, history, and configuration carried over. Roughly half of migrating companies now land somewhere in this middle, per ISG, while 34 percent choose brownfield and 18 percent go greenfield.
Now the part the search results get wrong. At least one widely read guide claims greenfield is the fast path at 6 to 12 months, with brownfield the slow one. For full transformations, the evidence runs the other way. A 2025 peer-reviewed comparison puts greenfield at 18 to 24 months, brownfield at 15 to 19, and hybrid approaches at 20 to 28. Deloitte’s practice says the same in fewer numbers: greenfield programs “tend to be longer,” while brownfield conversions deliver faster with less initial business benefit. The confusion comes from comparing a small greenfield rollout against an enterprise brownfield program. Like for like, the reimplementation is the long road.
The same academic comparison prices the paths at $5 million to $6 million for brownfield against $7 million to $9 million for greenfield at companies with $1 billion to $5 billion in revenue, which is why timeline and budget conversations are really one conversation. The cost breakdown is its own post.
Brownfield’s speed is real, and the concession deserves a full sentence: for a company with clean data and light customization, a 6-to-12-month brownfield conversion is often the right call, 2027 being what it is. Just be clear about what the speed buys. Greenfield strips out around 85 percent of custom code volume; brownfield removes 10 to 15 percent. The fast path carries your old problems into the new system at highway speed.
Scope in months is one worry. Downtime is another, and it has better answers than most buyers expect. For conversions where the business cannot stop, SAP’s Selective Data Transition engagement offers a near-zero-downtime approach that squeezes technical downtime into a matter of hours, with single or phased go-lives. The disruption window is negotiable. The project duration mostly is not.
The Phase-by-Phase SAP Project Timeline
SAP’s current delivery methodology is SAP Activate, which replaced the old ASAP framework. It runs six phases: Discover, Prepare, Explore, Realize, Deploy, and Run. The table below maps practitioner duration ranges onto those phases for two common scenarios. These are working ranges from delivery practitioners, not official SAP guidance, and the right-hand column stretches fast as entity count and process redesign grow.
| Phase | What Happens | Mid-Market Brownfield Conversion | Full Transformation Program |
|---|---|---|---|
| Data remediation (pre-project) | Cleaning legacy master data before anyone bills you | Starts weeks to months before kickoff; almost never in the proposal | Same, at larger scale; the most commonly skipped phase |
| Discover | Business case, scoping, approach decision | 2-4 weeks | 4-8 weeks |
| Prepare | Team, governance, project plan, environments | 3-6 weeks | 4-8 weeks |
| Explore | Fit-to-standard workshops, requirements confirmation | 4-8 weeks | 8-12 weeks |
| Realize | Configuration, custom development, integration, testing cycles | 8-16 weeks | 12-20 weeks, plus 8-12 weeks of dedicated test and training effort |
| Deploy | Cutover rehearsals, final migration, go-live | 4-6 weeks | 4-6 weeks per go-live wave |
| Run (hypercare) | Stabilization, defect burn-down, handover to support | 6-12 weeks | 6-12 weeks per wave |
| Total | Roughly 6-12 months | Roughly 12-18 months; 18-36 for multi-entity global programs |
Two things about that table are worth saying plainly. Realize is the long pole, and it is also where Horvath found the underestimation lives: testing gets budgeted as a formality and behaves like a phase. And the first row is the one that decides whether the rest of the table holds. Data work that starts at kickoff is data work that is already late.
What Actually Moves the Date
Every factor list in every vendor guide says the same things: company size, module count, customization, resources. True, and not useful. Here is the version with numbers attached.
- Data quality. The single most common slip. Testing and data migration are the two phases Horvath flags as chronically underestimated, and integration white papers make the same point about payroll testing specifically: underestimate it and go-live moves. Your legacy data is messier than you think. It always is.
- Data volume. Salling Group, the Danish retail giant, cut its database from 60 TB to 32 TB before migrating, using SNP’s bluefield tooling. Half the data is half the cutover problem.
- Custom code. Practitioner estimates put fit-to-standard discipline at a 30 to 50 percent cut in custom development and a 15 to 25 percent cut in overall timeline. Every bespoke process you insist on keeping is a line item and a test cycle.
- Module scope. Financial modules alone run 6 to 12 months in the standard vendor estimate; logistics and HCM (human capital management) 12 to 18; supply chain management 18 to 24. Scope is the throttle.
- Decision speed. ISG’s finding again: people cause the delays. A steering committee that takes three weeks to approve a design decision has added three weeks, times every decision.
- The old advice that still holds. Start adoption work on day one, integrate the data migration strategy into the plan rather than bolting it on, write the test strategy early, and decide up front how much of the program your SI (systems integrator, the implementation partner) actually owns.
Can the Timeline Be Compressed Honestly?
Somewhat, and the levers are known. Cloud deployments run shorter than on-premise builds, 6 to 12 months against a typical 12 to 18, partly because SAP’s migration cockpit and standardized templates take real weeks out of the data migration work. Running workstreams in parallel instead of in sequence shortens the calendar without shrinking the work. Phased go-lives trade one big cutover for several small ones, which compresses risk more than duration. And fit-to-standard remains the biggest lever of all, per the numbers above.
What does not compress: testing, dress rehearsals, and hypercare. Those are the phases that catch the problems before your customers do. A partner offering to shorten the timeline by trimming test cycles is not compressing the project. They are moving the delay to the other side of go-live, where it costs more and has your name on it.
There is one variable that table cannot show you: whether the team your SI proposes has done your scope, at your size, in your industry. The logo on the proposal does not answer that. The staffing plan does. That matching problem is exactly what our engine exists for: describe your project and watch it rank vendors against it, free, no signup.
Frequently Asked Questions
What are the 7 stages of a SAP implementation project?
There is no single official seven. SAP Activate defines six phases: Discover, Prepare, Explore, Realize, Deploy, and Run. Count hypercare (the stabilization period after go-live) as its own stage and you get seven. Any partner using different labels should be able to map theirs to these.
What are the 5 phases of SAP implementation?
The five-phase model comes from ASAP, SAP’s older methodology: project preparation, business blueprint, realization, final preparation, and go-live with support. SAP Activate replaced ASAP, but plenty of consultants and templates still speak five-phase ASAP. The work is the same; the boundaries moved.
What are the 7 stages of a project?
Generic project management usually lists initiation, planning, execution, monitoring, and closure, stretched to seven by splitting planning and adding a review stage. SAP delivery frameworks are those same ideas specialized: Explore is planning with the software switched on, and hypercare is closure with consequences.
What is the difference between timeline and WBS?
A WBS (work breakdown structure) decomposes the project’s scope into deliverables and work packages: the what. A timeline places that work on a calendar with dependencies and dates: the when. In practice the WBS comes first, because a schedule built before the scope is decomposed is a guess with a font.
Sources
- AWS Partner Network blog on SAP S/4HANA migration: the 8.8-month planning, 17.4-month execution, and $1.5 million disruption benchmarks.
- The Register on ISG’s migration research (February 2026): the 60 percent delayed-and-over-budget finding, approach shares, the Dornan quote, and the Gartner ECC adoption figures.
- Thinklytics on S/4HANA migration duration: the Horvath 2025 on-time and overrun findings.
- World Journal of Advanced Engineering Technology and Sciences, 2025: the greenfield, brownfield, and hybrid timeline, cost, and custom-code comparisons.
- Rizing retail grocery S/4HANA case study: the 18-month sandbox-to-production example.
- Deloitte on S/4HANA selective transformation: relative duration of the migration paths.
- SAP Selective Data Transition engagement: the near-zero-downtime approach.
The honest answer to “how long” exists. It is just conditional: 6 to 12 months for a disciplined brownfield conversion, 12 to 18 for a real mid-market program, twice that for a global transformation, and 30 percent more than whatever the proposal says if you staff it thin and skip the data work. The deadline is fixed; your position in the delivery-team queue is not. Browse vendors by module and industry and start the clock on purpose.
