Three proposals arrive. One quotes eight months, one quotes fourteen, and one quotes twenty-two. The price spread is wider than the timeline spread. Procurement wants to know why, and nobody in the room can give a clean answer.

The usual explanation is that vendors pad differently. Sometimes true, but it is rarely the main thing. More often the three proposals are answering different questions, because each one silently made two decisions on your behalf and only told you about one.

The two decisions

Deployment model answers where the system runs and who operates the infrastructure. Migration path answers what happens to your existing configuration, customizations, and data on the way across.

They are orthogonal. A greenfield build on GROW is a different program from a greenfield build on RISE, and both are different from a brownfield conversion to RISE. When a proposal says "S/4HANA in eight months," the useful follow-up is not "how" but "which two."

Keeping them separate does something practical: it lets you make the harder decision first. Migration path is driven by the state of your current estate, which is a fact you can establish. Deployment model is driven by what you need the system to do, which is a judgment. Establish the fact, then make the judgment.

Deployment: where it runs

GROW with SAP is public cloud with preconfigured best-practice content. Go-live in four to six months. It is the fast path for manufacturers ready to adopt standard processes with minimal customization, and its constraint is exactly its selling point: you get SAP's process model, and adapting it is limited by design.

That constraint deserves a straight answer rather than a euphemism. If your differentiation genuinely lives in a process, public cloud will fight you, and the fight is expensive because you will be working around the platform rather than with it. If your processes are ordinary and you have been treating that as a weakness, GROW converts it into a schedule advantage.

RISE with SAP is private cloud with full customization capability, managed by SAP. Six to twelve months. This is the right answer for complex discrete and process manufacturing, regulated industries, and anyone whose configuration depth is real rather than accumulated. You keep the ability to extend meaningfully while handing off infrastructure operations.

On-premise or private managed remains legitimate, and the reasons are narrower than they used to be but no less valid: specific data residency obligations, compliance regimes that require demonstrable physical control, or infrastructure investments with life left in them. If someone tells you on-premise is obsolete, they are describing a sales preference, not your regulatory position.

The honest split for a $100M to $1.2B manufacturer: GROW if your processes are standard and your appetite for change is high, RISE if your manufacturing complexity is real, on-premise if a regulator or a contract requires it. Most land on RISE.

Migration path: how you get there

Greenfield is a clean build on SAP best practices and preconfigured content. Thirty-two to fifty-two weeks. No legacy customization debt carries forward, the architecture is clean, and Joule and BTP capabilities are native from day one. Highest business disruption, planned and managed. It is the right answer when the processes themselves are the problem, and when the organization has the appetite to redesign rather than replicate.

Brownfield, or system conversion, converts your existing ECC system to S/4HANA while preserving configuration, customizations, and historical data. Twenty to thirty-two weeks, the lowest delivery risk, minimal business disruption, custom code preserved and refactored. Joule and BTP get activated after cutover rather than during. It suits established estates with processes that work and timelines that do not bend.

Brownfield carries a reputation for being the lazy option. That reputation is partly unearned. If your processes are genuinely fit and your customizations genuinely serve the business, converting them is not cowardice, it is proportion. The failure mode is not choosing brownfield; it is choosing brownfield without ever looking at what you are converting.

Selective data transition, also called hybrid or Bluefield, is the middle path: a clean S/4HANA foundation with selective migration of the historical data and proven configuration worth keeping. Twenty-six to forty weeks, moderate risk, cherry-picked custom code rebuild, Joule and BTP embedded into the rebuilt modules.

It is where most mid-market manufacturers end up after a real diagnostic, and the reason is unglamorous. Very few estates are uniformly good or uniformly bad. Finance has drifted and needs a rebuild while manufacturing works and should be preserved, or the reverse. Selective is what you choose when the honest answer to "is your current configuration worth keeping" is "some of it."

Brownfield Selective Greenfield
Best fit Stable processes, tight timeline Mixed maturity, M&A history Carve-outs, business-model change
Typical timeline 20–32 weeks 26–40 weeks 32–52 weeks
Delivery risk Low Moderate Higher, managed
Process redesign Optimize as-is Selective rebuild Full redesign
Custom code Preserved and refactored Cherry-pick rebuild Replaced, clean-core
Joule / BTP Activate post-cutover Embed in rebuilt modules Native day one
Business disruption Minimal Moderate Highest, planned
Investment $ $$ $$$

The question that actually decides it

Not "what is best practice." The question is: what proportion of your current configuration and custom code is worth carrying forward?

That is a measurable thing, and measuring it takes about two weeks. In most manufacturing estates, forty to sixty percent of custom code turns out to be unused or replaceable with standard S/4HANA functionality. Objects written for processes that changed a decade ago, reports nobody opens, enhancements duplicating something SAP now ships natively.

Run that analysis and the path chooses itself. A high proportion of genuinely valuable configuration points to brownfield. A low proportion points to greenfield. A wide spread across modules, which is the common case, points to selective.

Run it after selecting a partner and you have inverted the decision. You have picked the vendor, and the vendor's preferred path is now your path.

Why the proposals do not match

With both axes visible, the spread makes sense. Eight months is GROW plus greenfield on standard processes. Fourteen is RISE plus selective. Twenty-two is RISE plus greenfield with real redesign. Those are three different programs delivering three different outcomes, and comparing their prices is meaningless without saying so.

Two questions restore comparability. Ask each vendor which deployment model and which migration path they have assumed, in writing. Then ask what evidence they used to assume it.

If the answer to the second question is a discovery workshop that has not happened yet, the number in front of you is a placeholder with a decimal point.

When the framework does not apply

Three honest exceptions.

Carve-outs and divestitures skip the analysis. If you are standing up an entity that does not yet exist, greenfield is the only coherent option regardless of what the parent's estate looks like.

Regulatory validation changes the arithmetic. In life sciences and aerospace, validated system requirements mean the cost of change is weighted differently. A process that would obviously be redesigned in general manufacturing may be worth preserving purely because revalidation is expensive and slow. The path decision has to account for validation burden, not just configuration quality.

And there is a case for deliberately choosing the harder path. Selective is usually right on the evidence, but if your organization has spent fifteen years accumulating workarounds because nobody would sponsor a redesign, greenfield's disruption is the point. Sometimes you are buying the forcing function, not the timeline. That is a legitimate reason to overrule the analysis, as long as it is stated out loud rather than smuggled in.

What a defensible answer looks like

Two weeks, not two quarters.

A fixed-fee diagnostic maps the as-is landscape, scores custom code complexity, assesses data quality and organizational readiness, and returns a recommended deployment model and migration path with the reasoning shown. It asks two calls of your team: a discovery session, then a solution report presentation. It ends with a board-ready plan on day fourteen, delivered by the principal architect who would run the program.

The industry default is a hundred and eighty days before anyone sees a working artifact. The gap between fourteen and a hundred and eighty is not a difference in thoroughness. It is a difference in whether the discovery phase is billable.

For what the resulting programs look like in practice: an aerospace manufacturer went live on greenfield S/4HANA Cloud in six months with better than ninety-nine percent master data accuracy, thirty percent improved inventory accuracy, and order-to-cash twenty percent faster. A high-tech manufacturer stood up finance, manufacturing, and procurement on RISE in the same six months. Both are delivered on SAP Activate with quality gates at every phase, and both were scoped against evidence rather than a template.

The decision under the decision

Deployment and path get all the attention because they are the questions on the RFP. But the question that predicts your outcome is neither of them. It is whether anyone measured your estate before quoting it.

A partner who tells you the path in week one, before touching your system, is not being decisive. They are telling you which path they staff.

The sequence matters more than the choice. Establish what proportion of your configuration is worth keeping, and both decisions become straightforward. Skip that step and you will spend the program relitigating a choice made from a slide.

Find Out Which Path Your Estate Actually Needs

A fixed-fee, two-week diagnostic for manufacturers choosing between RISE, GROW, and on-premise, and between greenfield, brownfield, and selective transition.

We'll establish your:

  • Custom code inventory and complexity score, so the path decision rests on measurement rather than preference.
  • Recommended deployment model and migration path, with the reasoning shown and the alternatives you rejected.
  • Projected timeline and investment range for the recommendation, against a realistic calendar.
  • Data quality and organizational readiness assessment, because both routinely move the date more than technology does.

Delivered by the principal architect who would run the program, contracted by name.

No sales drip. A board-ready plan in fourteen working days.

Schedule Executive Briefing