How to choose an S/4HANA migration partner

To choose an SAP ECC to S/4HANA migration partner, use SAP's partner designations to build a long list, then decide on two things: references from migrations like yours and the partner's high-level design for your business. Walk away from any partner whose answers are generic, and keep control of the scope yourself.

Short answer: the badge gets a partner onto your list. The references and the design get them the contract.

This article is one part of my ECC to S/4HANA migration guide, which covers the paths, timelines and deadlines. Here I only cover the partner decision. It is the decision that shapes most of what follows, because the partner you pick will propose the path, the plan and the scope.

A migration partner is not the same purchase as an implementation partner. On a brownfield conversion you are buying technical conversion skill, custom code remediation, data preparation and a cutover that works first time. On a greenfield you are buying process design as well.

Most selection processes miss this. They compare day rates and methodology slides, when the real work sits in a few places that the slides rarely show:

1. Custom code. In my experience it is the migration phase that overruns most often, and the hidden cost companies forget most.
2. Data. Data migration takes 30 to 40 percent of the effort on the programmes I have seen.
3. Cutover. On a brownfield I plan three mock conversions before the real one, and the downtime I have seen ranges from a weekend to a week.
4. Design. The design decisions the partner proposes in the first months decide your cost for years afterwards.

So the question is not "which partner is best". It is which partner can show you, with evidence, how they will handle those four areas for your system.

SAP runs its partner programme, SAP PartnerEdge, on a competency framework. When SAP introduced it in 2022, it set seven competencies with three tiers each, essential, advanced and expert, with specialisations at product or process level inside each competency. Partners earn them on expert knowledge, customer success and proficiency.

Those designations show up in SAP Partner Finder, where you can search and filter partners. In its January 2025 update to PartnerEdge, SAP said expertise now plays an even stronger role in determining partner levels.

For RISE with SAP there is a separate recognition. The RISE with SAP Validated Partner recognition, introduced in June 2024, requires the expert level of several competencies. They include RISE with SAP S/4HANA Cloud Private Edition, SAP Business Technology Platform and SAP Business Process Transformation.

SAP's July 2025 description of the recognition adds the delivery side. It asks for the RISE with SAP Methodology across delivery teams, certified people in key roles, and clean core quality gates documented in SAP Cloud ALM.

This is what each signal does and does not tell you:

Signal	What it confirms	What it does not confirm
Competency tier (essential, advanced, expert)	The firm has the knowledge, delivered projects and customer results SAP measures in that area	That the people proposed for your programme did that work
Specialisation	Accomplishment in a specific SAP product or process	Depth in your industry or your kind of migration
RISE with SAP Validated Partner	Expert competencies, the RISE methodology and clean core gates in SAP Cloud ALM	That the partner understands your custom code, your data or your finance close
Listing in SAP Partner Finder	The firm is a registered SAP partner with visible designations	Anything about fit

Use the badges as a filter. A partner with no relevant competency should not be on a list for a large migration. A partner with every badge still has to pass the two tests below.

How I would run the partner decision

1. 01

   Assess

   Run the SAP Readiness Check and size custom code and data before you go to market.

2. 02

   Own the scope

   Write the scope and the decisions you want made, so partners respond to your facts.

3. 03

   Long list

   Use SAP designations and Partner Finder to find firms with relevant competencies.

4. 04

   Test

   Check references and ask each shortlisted partner for a high-level design.

5. 05

   Contract

   Tie payment and scope changes to the design you tested.

When I advise on a partner decision, two things decide it for me: references and the partner's high-level design. Everything else in the proposal is supporting material.

References from migrations like yours

A reference is only useful if it matches your situation. A reference from a greenfield in another industry tells a brownfield manufacturer very little.

Ask for references that match on three things, then call them yourself:

1. The path. Brownfield, greenfield or selective, the same as yours.
2. The scale. A similar number of entities, countries and custom objects.
3. The people. Ask the reference who led the work, then check whether those people are in your proposal.

On the call, ask what the custom code count was at the start and at the end, how many mock conversions ran and what went wrong at cutover. A reference who cannot answer those questions was not close enough to the work.

Their high-level design for your business

The second test is to ask each shortlisted partner for a high-level design of your target S/4HANA system before you sign. Give them your Readiness Check results and the scope you have written, then ask how they would handle your processes, your custom code and your data.

A good high-level design names your entities, your critical processes and the custom objects that matter. It says what they would retire, what they would keep and why. It shows how they would structure the data loads and the cutover.

This is also where you see whether the partner can keep a clean core. Customisations should be kept to a minimum and governed well. If the design tries to make SAP work like your old system, that is the habit that drives cost up for every future upgrade.

The red flag that makes me walk away is generic information. A pitch, or answers to your questions, that are not specific to your business.

You will recognise it. The proposal describes the methodology in detail and your company in one paragraph. Questions about your custom code get an answer about "accelerators".

The plan has the same phases and durations you saw in another firm's deck last month.

Generic answers mean one of two things. The partner has not done the work to understand you, or it does not intend to until after you sign. Either way, the real design will be done on your budget during Explore.

The test is simple. Take each answer and replace your company's name with a competitor's. If it still reads correctly, it was not written for you.

The root cause I see behind most migration budget problems is letting vendors control the scope. Budgets get hit in the Explore phase, as WRICEF objects (workflows, reports, interfaces, conversions, enhancements and forms) grow. The partner that writes the scope also writes the change requests.

This is not about bad intent. A partner's commercial incentive is to start, and to add work when it finds it. Your incentive is to finish within the number you gave the board.

Those are different jobs, and the scope belongs with the side that pays.

In practice, keep scope ownership on your side in four ways:

1. Write the scope before you go to market. Base it on your Readiness Check and your own custom code analysis, not on the partner's discovery workshop.
2. Set up a design authority. Business and IT together, with the right to approve or reject every new WRICEF object.
3. Baseline the WRICEF list. Count the objects at contract signature and report the count at every steering committee.
4. Tie the contract to the design you tested. Changes against that design go through change control, with a reason and a cost.

Plan for overruns anyway. I would hold a contingency of 10 to 20 percent, and remember that services are 35 to 50 percent of total programme cost. My guide to S/4HANA migration cost shows what drives the number by path, and my notes on ERP contract negotiation cover the commercial terms.

My answer to this one is short: it depends on references.

A global SI with no comparable brownfield reference in your industry is a weaker choice than a boutique that has done three. A boutique with no reference at your scale is a weaker choice than an SI that has. Firm size tells you about bench depth and reach, and the references tell you whether the people can do your migration.

I have written separately about SAP implementation partners in the USA by tier, with what each tier is good at and where it tends to fail. I will not repeat the lists here, and I do not rank partners. Use that article to understand the trade-offs, then run the two tests above on whoever is on your shortlist.

One more point on size. Many large programmes use more than one partner, for example a prime for the core migration and a specialist for selective data transition or custom code. That works when you own the scope and one partner is accountable for integration.

Before you send a single request for proposal, run the assessment. An SAP Readiness Check and migration assessment gives you the custom code, data and simplification facts that partners should respond to. Without it, every partner fills the gap with its own assumptions, and you cannot compare the answers.

If you have already signed and the programme is slipping, the questions are different. My guide to SAP programme recovery covers what to check first.

Across the 21 SAP programmes I have led or rescued, the biggest mistake I see is not planning properly at the start. Partner selection is where that planning starts. If you want an independent view on a shortlist or a proposal, I help organisations with this, and you can contact me here.

How do I choose an SAP S/4HANA migration partner?

Use SAP's competencies and Partner Finder to build a long list of partners with relevant expertise. Then decide on references from migrations like yours and on each partner's high-level design for your business. Walk away from partners whose answers are generic, and keep ownership of the scope.

What is a RISE with SAP Validated Partner?

It is a recognition SAP introduced in 2024 for partners that deliver large and complex cloud ERP projects. Validated partners hold the expert level of several SAP competencies, including RISE with SAP S/4HANA Cloud Private Edition. SAP also expects the RISE with SAP Methodology, certified people in key roles and clean core quality gates documented in SAP Cloud ALM.

Should I use a big SI or a boutique for an S/4HANA migration?

It depends on references. Choose the firm whose people have done a migration like yours, on the same path, at a similar scale and in a similar industry. Firm size tells you about bench depth and reach, not about whether the team can do your migration.

What questions should I ask an SAP partner before signing?

Ask for references from comparable migrations and call them yourself. Ask for a high-level design of your target system, based on your Readiness Check results and your scope. Ask how they will size and reduce custom code, how many mock conversions they plan and who exactly will be on your programme.

What are the red flags when selecting an SAP implementation partner?

The main one is generic information: a pitch or answers that could apply to any company. Others are a plan that looks like every other plan, vague answers on custom code and data, and a partner that wants to define the scope in its own discovery workshop after you sign.

Does an SAP expert partner badge guarantee a successful migration?

No. SAP's competency tiers confirm knowledge, delivered projects and customer results at firm level. They do not confirm that the people proposed for your programme did that work, or that the partner understands your custom code and data.

Use badges to filter, then test references and design.