How to Choose an SAP S/4HANA Migration Partner in the USA: A Practical Guide

How do you choose the right SAP S/4HANA migration partner? In our guide, we explain how to compare migration expertise, architecture, data, delivery, costs, and support.

What happens when an SAP migration partner gets a critical decision wrong?

The consequences can extend far beyond the migration project. Poor data conversion can affect financial reporting. Weak integration design can disrupt connected applications. Excessive custom code can increase the effort required to maintain and upgrade S/4HANA. Gaps in post-go-live support can leave internal teams managing unresolved issues after the project team has moved on.

That is why partner selection should assess more than SAP credentials, company size, or the lowest implementation bid. The evaluation needs to cover migration experience, architecture, data migration, custom-code remediation, integrations, industry expertise, delivery resources, commercial terms, and post-go-live support.

It should also establish whether the people proposed during the selection process are the people who will actually deliver the migration.

In this guide, we explain how US enterprises can evaluate an SAP S/4HANA migration partner and compare providers against the risks and requirements of their specific environment.

Key takeaway: Choosing an SAP S/4HANA migration partner means evaluating more than SAP credentials or implementation cost - it means finding a partner with the right migration experience, technical expertise, delivery team, and post-go-live capabilities to reduce risk and support a successful transition.
Ready to evaluate your S/4HANA migration options?
→ Talk to our S/4HANA migration experts

What Should an SAP S/4HANA Migration Partner Bring to the Project?

An SAP S/4HANA migration partner can influence the target architecture, data strategy, custom-code scope, integration landscape, testing approach, cutover plan, and post-go-live operating model. These decisions affect both the migration itself and the effort required to maintain the S/4HANA environment afterward.

SAP's implementation guidance treats activities such as data migration, integration, testing, cutover, training, and operations as connected parts of the implementation lifecycle. Partner selection should therefore evaluate how a provider handles these areas together rather than treating them as separate workstreams.

A large consulting firm may have thousands of SAP consultants but still assign a team with limited experience in the specific migration path, industry processes, or technical landscape involved. A lower bid may also exclude work that later appears as change requests.

The evaluation should focus on evidence from comparable projects and the capabilities of the actual delivery team.

What Should the Evaluation Cover?

Relevant S/4HANA migration experience should carry more weight than the number of SAP credentials a company can present. Certifications demonstrate knowledge of specific SAP technologies and roles. They do not show how a team handled a complex system conversion, reconciled migrated data, remediated custom ABAP, stabilized integrations, or managed a production cutover.

The same principle applies to company size. Consultant numbers, customer logos, and years in the SAP market provide useful context, but they do not establish delivery capability for a specific migration.

A stronger evaluation asks for evidence from comparable projects and examines who would perform the work.

The technical assessment should also connect migration decisions with the future SAP operating model. If a partner recommends extensive custom development, for example, it should explain why standard S/4HANA functionality is insufficient and how the proposed extensions fit a Clean Core strategy.

Why the Delivery Team Matters

The proposed team deserves the same scrutiny as the consulting firm's credentials. A proposal may be developed by senior SAP architects while the actual project relies on a different group after the contract is signed.

Before selecting a partner, identify who will own:

• S/4HANA architecture
• data migration
• custom-code remediation
• integrations
• functional design
• testing
• cutover
• change management
• post-go-live stabilization

The team also needs sufficient knowledge of the customer's business processes to validate migration decisions with finance, supply chain, manufacturing, procurement, warehouse, logistics, and other affected functions.

The partner should explain its delivery model in concrete terms, including roles, locations, availability, escalation paths, knowledge transfer, subcontracting, and the people expected to remain involved after go-live.

What Should Separate Partners During Evaluation?

A useful evaluation focuses on evidence rather than headline credentials.

Relevant migration references, proposed architecture, data migration methods, custom-code assessment, integration experience, testing and cutover practices, team composition, commercial assumptions, and post-go-live support provide stronger signals than a large consultant pool alone.

The following sections break down these evaluation criteria.

1. Start With a Clear Migration Scope

A migration partner can only be evaluated against requirements that have been defined.

An ECC system with several years of custom development, multiple country deployments, high-volume interfaces, and many connected applications requires a different delivery model from a relatively standardized SAP landscape.

Before comparing partners, document the main characteristics of the current environment, including:

• SAP ECC release and modules
• number of SAP systems
• countries and legal entities
• custom code and modifications
• integrations and interfaces
• data volumes and data quality
• manufacturing and warehouse locations
• third-party applications
• cloud requirements
• target timeline
• internal resources and responsibilities

The business objective should also be explicit. An ECC-to-S/4HANA program may focus on technical system conversion, process redesign, ERP consolidation, cloud adoption, process standardization, or reduction of technical debt. These objectives can lead to different migration paths, architecture decisions, and partner requirements.

Define the Outcome Before Evaluating the Partner

The key question is not only which SAP system should replace ECC. It is also what the enterprise expects to change as a result of the migration.

For example, an enterprise planning a system conversion with minimal process change may prioritize conversion experience, custom-code remediation, data consistency, and cutover execution.

A company using the migration to standardize processes across several countries may need stronger capabilities in global template design, business-process harmonization, organizational change, and adoption.

Defining the outcome also makes proposals easier to compare. Each partner should respond to the same scope and business objectives, making differences in migration approach, staffing, timeline, and cost more visible.

→ If you’re still on ECC, here are 10 U.S. business drivers that explain why migration matters now.

2. Evaluate S/4HANA Migration Experience

The key question is not simply whether a partner has delivered SAP projects. It is whether the partner has delivered migrations with a similar starting landscape, target environment, migration path, and level of business change.

SAP defines three main transition paths from SAP ERP to S/4HANA:

• System conversion - the existing SAP ERP system is converted and becomes the basis for the S/4HANA environment.
• New implementation - a new S/4HANA system is established using fit-to-standard processes.
• Selective data transition - selected data, processes, and organizational structures are moved to the target environment.

How Much Comparable Experience Does the Partner Have?

A partner should be able to explain why a particular transition path fits the enterprise's current landscape and business objectives.

The recommendation should consider factors such as:

• process maturity
• data quality
• custom code
• organizational structures
• historical data requirements
• integration landscape
• desired level of process change

Ask for evidence from comparable projects:

• How many migrations used the proposed transition path?
• How similar were the source systems, business processes, data volumes, and integrations?
• Which parts of those projects were delivered by the team proposed for this engagement?
• What migration issues required changes to the original plan?
• How did the partner manage testing, cutover, and production stabilization?

Migration experience should cover more than technical conversion. For a system conversion, for example, the project may involve custom-code cleanup, data preparation, database migration, software updates, and data conversion.

A partner may have completed many S/4HANA projects while having limited experience with the specific transition path under consideration. That distinction should be established before the partner's approach becomes part of the project plan.

Get an S/4HANA migration strategy grounded in your data, custom code, integrations, and business processes.

→ Request a free consultation

3. Assess S/4HANA Architecture Expertise

A migration partner also needs to design the target SAP environment. A technical conversion can succeed while leaving the enterprise with unnecessary dependencies, custom development, or integration complexity.

The assessment should cover both the deployment model and the surrounding architecture.

Depending on the enterprise's requirements, the target environment may involve:

• SAP S/4HANA on-premise
• SAP Cloud ERP Private
• SAP Cloud ERP Public
• SAP BTP for extensions and surrounding services

RISE with SAP commonly includes SAP Cloud ERP Private Edition, while SAP BTP can provide extension and integration capabilities around the ERP core.

Can the Partner Explain Its Architecture Decisions?

A capable partner should explain the reasoning behind the proposed architecture in terms of actual business and technical requirements.

The discussion should cover:

• deployment model and infrastructure responsibilities
• integration architecture and external connectivity
• extension strategy and Clean Core principles
• SAP BTP use cases and boundaries
• security, identity, and data requirements
• release and upgrade considerations
• operating responsibilities after go-live

Examine the Clean Core Approach

The Clean Core discussion deserves particular attention.

SAP supports clean-core extensibility across SAP Cloud ERP Private Edition and on-premise environments, including ABAP Cloud alongside existing classic ABAP capabilities. The appropriate approach depends on the target environment and the customer's existing custom code.

The partner should be able to explain:

• which existing customizations should remain
• which can be retired
• which can be replaced by standard functionality
• which require remediation
• which should be redesigned as extensions
• where those extensions should run
• how the design affects future upgrades and maintenance

A useful test is straightforward: ask why the proposed deployment and architecture model fits the enterprise's requirements, and which alternatives were considered and rejected.

The quality of that reasoning can reveal more than a list of SAP certifications.

4. Evaluate Data Migration Capability

Data migration can affect financial reporting, inventory balances, customer and supplier records, open transactions, and other business processes immediately after go-live.

The partner should show how it will determine:

• which data belongs in S/4HANA
• what needs cleansing
• what needs transformation
• what historical data should be retained
• what can be archived
• what should be retired
• how migrated data will be validated

The assessment should cover data discovery, profiling, mapping, transformation, master data, transactional data, historical records, mock migrations, reconciliation, and cutover.

SAP S/4HANA provides tools such as the SAP S/4HANA Migration Cockpit, but knowledge of the tool does not by itself demonstrate the ability to manage complex migration requirements.

How Will the Partner Control the Data?

A strong migration plan should define the treatment of each major data category.

Some records may move directly into S/4HANA. Others may require transformation or cleansing. Historical information may remain in an archive or legacy system when it is not required in the operational environment. Obsolete data may have no place in the target system.

The partner should also explain how it will prove that migrated data remains accurate.

Mock migrations provide an opportunity to test extraction, transformation, loading, and reconciliation before the final cutover. Reconciliation should compare relevant source and target results, including financial balances and key master-data and transaction counts where appropriate.

Ask for examples of how the partner handled data-quality problems on comparable projects. Identifying poor data quality during early migration cycles rather than during late-stage testing can reduce rework and cutover risk.

5. Assess Custom-Code Remediation and Clean Core

An ECC migration can carry years of custom development into the S/4HANA environment. Some developments may no longer be required. Others may depend on functionality that has changed in S/4HANA or create unnecessary maintenance effort.

The partner should have a structured method for deciding what happens to each significant customization.

The assessment should include:

• custom ABAP programs
• Z-programs
• modifications
• custom tables
• interfaces
• other extensions
• developments affected by SAP simplification items

SAP provides tools such as the Custom Code Migration app to analyze custom code and identify developments affected by the move to S/4HANA.

What Should Happen to Existing Custom Code?

Typical outcomes include:

1. Retire custom code that no longer serves a business requirement.
2. Replace custom functionality with standard S/4HANA capabilities where they meet the requirement.
3. Remediate code that remains necessary and can run appropriately in the target environment.
4. Redesign selected extensions using supported extensibility approaches, including side-by-side extensions on SAP BTP where appropriate.

This assessment is also a practical test of the partner's Clean Core approach.

A proposal that assumes existing customizations will simply move into S/4HANA without structured assessment deserves further scrutiny.

The partner should be able to explain which developments will remain, why they remain necessary, where they will run, and how the approach affects future upgrades and maintenance.

What Is SAP Clean Core?
Learn about the key principles and benefits of SAP Clean Core, and how to apply them to your SAP landscape. → Read the guide

6. Evaluate Integration Expertise

An S/4HANA migration rarely affects SAP alone.

US enterprises may have manufacturing, warehouse, logistics, commerce, banking, tax, analytics, and other applications connected to the ERP system. The migration partner needs to understand those dependencies and determine how they should change in the target architecture.

The evaluation should cover SAP and non-SAP integrations, including:

• SAP EWM
• SAP TM
• MES
• PLM
• CRM
• ecommerce platforms
• WMS
• carrier systems
• banks
• tax applications
• legacy ERP systems
• data platforms

The partner should also have experience with APIs, EDI, middleware, SAP Integration Suite, and event-driven integration where those patterns fit the requirements.

SAP S/4HANA provides integration options including OData, SOAP, APIs, BAPIs, and IDocs, while SAP Integration Suite supports connectivity across diverse application landscapes.

What Should Change in the Target Integration Architecture?

Migration is an opportunity to:

• remove obsolete interfaces
• consolidate duplicated data flows
• replace tightly coupled connections where appropriate
• use supported integration patterns
• clarify ownership and monitoring
• improve error handling

SAP architecture guidance also describes event-driven integration through SAP Integration Suite and event services on SAP BTP for use cases that require asynchronous communication.

Ask the partner to map the major current interfaces to the target architecture and explain which will remain, change, or be retired.

The proposal should also identify ownership, monitoring, error handling, and support responsibilities after go-live.

A partner that can reproduce the existing interface landscape demonstrates technical execution. A partner that can explain why each connection belongs in the target landscape demonstrates architecture expertise.

7. Look for Relevant Industry Experience

S/4HANA migration decisions depend partly on how the business operates.

A discrete manufacturer, for example, may need to address production planning, bills of material, plant operations, inventory, quality, and supply chain dependencies.

A logistics company may have different requirements around transportation, warehousing, carrier integration, and shipment execution.

SAP provides industry-specific capabilities across areas such as automotive, aerospace and defense, life sciences, retail, industrial manufacturing, energy, and transportation and logistics.

Industry experience becomes particularly relevant when the migration involves process redesign or standardization. The partner needs to distinguish between a genuine business requirement and a process that exists primarily because of a legacy ECC configuration.

That distinction can determine whether a process:

• moves unchanged
• adopts standard S/4HANA functionality
• requires an extension
• is redesigned entirely

How Comparable Were the Partner's Previous Projects?

Look for similarities in more than the industry name. Relevant comparisons include:

• business processes
• number and location of facilities
• production or distribution complexity
• regulatory requirements
• supply chain model
• transaction volumes
• number of connected systems
• geographic footprint

A partner that has migrated an automotive manufacturer may still lack relevant experience for a highly decentralized aerospace operation or a pharmaceutical company with strict validation requirements.

The useful evidence comes from the similarity of the operating environment, not the industry label alone.

Ask which business and SAP roles were involved in comparable projects and whether those specialists are available for the proposed engagement.

8. Evaluate US Delivery Capability

A distributed delivery model can work well for a US S/4HANA program when it is designed around the project's working hours, decision points, and critical delivery phases.

The relevant question is not simply where the consultants are located. It is how quickly the team can make decisions and resolve issues when testing, cutover, or production operations require immediate action.

The partner should explain how its US, nearshore, and offshore resources will work together and who owns each major workstream.

The evaluation should cover:

• US-based leadership: Which senior roles work directly with US stakeholders, and when are they available?
• Time-zone coverage: Can the team support workshops, testing, cutover, and production incidents during required US business hours?
• On-site presence: Which activities require people at US locations, particularly during discovery, business validation, cutover, and stabilization?
• Global delivery: Which work will be performed nearshore or offshore, and who remains accountable?
• Escalation: Who makes technical or delivery decisions when an issue crosses locations or workstreams?
• US operating experience: Has the partner supported comparable US organizations with their business hours, compliance requirements, and operating structures?

A distributed model can be effective, but it requires clear handoffs, shared documentation, decision authority, and escalation procedures.

Ask the partner to show the actual communication and escalation model rather than simply describing the team as “global.”

9. Ask Who Will Actually Deliver the Migration

The people who sell an SAP migration may have very different roles from the people who execute it.

A proposal may feature senior architects and experienced SAP leaders while the delivery team contains different consultants with less relevant experience.

Before signing, identify the people who will own the major workstreams:

Also establish:

• how much of the proposed team will remain on the program
• which sales and solution-design resources will stay involved
• how senior specialists will be retained through critical phases
• which activities will be subcontracted
• how key-person replacements will be handled

A useful test is to give proposed leads several migration scenarios relevant to the enterprise.

The architecture lead should explain design trade-offs. The data lead should discuss reconciliation and data-quality controls. The cutover lead should explain dependencies, rollback considerations, and production-readiness criteria.

The contract should reflect the delivery structure presented during partner selection.

The question to resolve before signing is straightforward:

Which people will carry the migration through design, testing, cutover, and stabilization, and who has authority when a critical decision needs to be made?

10. Evaluate the Migration Methodology

A migration methodology should show how the partner will control the project from the initial assessment through production stabilization.

A list of phases such as assess, design, build, test, deploy provides limited value without defined outputs, decision points, owners, dependencies, and quality gates.

The partner should explain how its methodology manages the relationships between:

• architecture
• data
• custom code
• integrations
• testing
• business processes
• cutover

For example, custom-code remediation can affect integration testing. Data-quality findings can change migration scope. A delayed interface can affect end-to-end testing and cutover readiness.

How Will the Methodology Adapt to the SAP Landscape?

A partner should tailor its delivery approach to the actual migration scenario.

A system conversion involving several ECC systems, extensive custom ABAP, multiple countries, and hundreds of interfaces requires different planning from a smaller S/4HANA transition.

The evaluation should cover:

• Scope control: How are change requests assessed for cost, timeline, resources, and dependencies?
• Risk management: How are risks identified, assigned, and mitigated?
• Decision governance: Who approves business and technical decisions?
• Quality gates: What must each workstream complete before migration, integration testing, UAT, and cutover?
• Business participation: When do finance, supply chain, manufacturing, procurement, and other process owners validate results?
• Program controls: Which metrics show progress, unresolved defects, migration readiness, and critical dependencies?

Ask the partner to show how these controls worked on comparable S/4HANA programs, including situations where the original plan changed.

11. Evaluate Testing and Cutover Expertise

Testing should prove that the S/4HANA environment can execute critical business processes across SAP and connected applications.

Testing an individual transaction does not confirm that a complete business process will work across multiple systems, data objects, interfaces, and financial postings.

Depending on the migration, testing may include:

• functional testing
• integration testing
• regression testing
• end-to-end testing
• volume testing
• performance testing
• user acceptance testing

Test data should represent relevant production conditions, including high transaction volumes and complex business scenarios where these conditions affect system behavior.

How Will the Partner Prove Production Readiness?

Consider an order-to-cash process that moves from sales order creation through warehouse processing, transportation, delivery, billing, and financial posting.

Testing needs to verify the complete transaction flow as well as interface messages, master-data dependencies, authorization behavior, error handling, and resulting accounting documents.

Cutover requires the same level of detail.

The partner should define the sequence for:

• final data migration
• transaction freezes
• interface shutdown and restart
• reconciliation
• user-access checks
• production validation
• go/no-go decisions
• recovery procedures

The evaluation should cover:

• Cutover rehearsals: How many rehearsals will be performed, and what will each validate?
• Final data migration: How will final extraction, transformation, loading, and reconciliation be executed?
• Transaction freeze: Which activities must stop, when, and how will transactions be controlled?
• Interface management: Which interfaces require shutdown or restart, and how will message processing be verified?
• Go/no-go criteria: Which technical and business conditions must be met?
• Recovery planning: What happens if a critical validation fails?
• Post-cutover validation: Which processes, balances, interfaces, and user functions must pass before normal operations resume?

Ask the partner to walk through a previous cutover in operational detail, including the migration window, reconciliation points, decision authority, failed-step handling, and production validation.

12. Assess Change Management and User Adoption

An S/4HANA migration can change how employees create transactions, approve documents, manage master data, perform financial close, handle warehouse operations, and access reports.

These changes need to be addressed during the migration rather than after users start working in the new system.

Training should reflect the actual process changes and responsibilities of each user group.

Finance users may need training on changed closing or reporting processes. Warehouse teams may need new execution procedures. Procurement, manufacturing, logistics, and sales teams can face different changes within the same program.

The partner should answer:

• Which business roles will experience the largest process changes?
• How will the project identify gaps between current and future procedures?
• How will process documentation be created and maintained?
• How will training differ by role and process?
• How will super users participate during testing and post-go-live support?
• How will business users validate new processes?
• How will recurring user errors be identified?
• Which adoption and support metrics will be tracked?
• How will responsibility transfer to the internal SAP support team?

The first weeks after go-live can expose problems that testing does not fully reveal. Users may misunderstand a new procedure, apply an old workaround, enter data incorrectly, or rely on a report that has changed.

The support model should therefore provide a way to identify recurring issues, update training materials, and transfer knowledge to the internal team.

Useful measures can include training completion, user acceptance results, transaction error rates, recurring support tickets, and usage of newly introduced processes.

13. Evaluate the Business Case and Value Delivery

The business case should connect the S/4HANA migration to measurable changes in cost, process performance, risk, or operating capacity.

The relevant measures depend on the transformation objectives.

A finance-focused program may track month-end close duration or manual reconciliation. A manufacturer may measure inventory accuracy, production-planning effort, or order-processing time. An enterprise consolidating several ERP systems may focus on infrastructure costs, application count, and integration maintenance.

Potential measures include:

How Will the Partner Measure the Result?

The partner should distinguish between project completion metrics and business outcomes.

Technical go-live confirms that the system entered production. It does not prove that the enterprise reduced manual work, retired unnecessary custom code, shortened financial processes, or improved supply chain performance.

Ask the partner to define:

• baseline measurements
• target values
• data sources
• measurement periods
• accountable business owners

This also makes program trade-offs easier to evaluate. If a proposed customization adds cost and maintenance effort, its expected business value can be compared with the measurable outcome it is intended to produce.

14. Review References and Case Studies

Case studies can show that a partner has delivered SAP S/4HANA projects. Direct customer references provide stronger evidence of how the partner performed when the project encountered real delivery constraints.

Look for similarities in:

• ECC landscape
• S/4HANA transition path
• industry processes
• number of sites
• geographic footprint
• system integrations
• project scale
• data complexity

US and North American references can also provide evidence about local delivery, business hours, and operating requirements.

What Should You Ask Previous Customers?

Ask questions that reveal what happened after the original plan encountered real conditions:

• Did the final scope remain close to the agreed scope?
• Which costs changed, and why?
• How did the partner handle data-quality problems?
• Did the proposed senior team remain involved?
• How closely did the delivered architecture follow the original design?
• How did the partner manage testing and cutover?
• How did it respond to critical post-go-live issues?
• How quickly did responsibility move to the client's internal support team?
• Would the customer select the same partner again?

What Should a Reference Tell You?

Pay particular attention to answers about problems.

A reference that explains how a partner handled a failed migration rehearsal, unexpected data issues, delayed integrations, or scope changes can provide more useful evidence than a case study describing only the planned project.

Ask for references from projects using the same migration approach under consideration. A partner with extensive greenfield experience may have limited evidence for a complex system conversion. The same distinction applies to selective data transition, large integration programs, and migrations involving extensive custom code.

15. Evaluate Commercial and Contractual Terms

A migration proposal can appear inexpensive when significant activities sit outside the quoted scope.

Compare the work required to reach production and stabilize the new environment, together with the assumptions that determine when additional charges apply.

Review proposals at the workstream level, not only by total project price.

The commercial review should cover:

• assessment and discovery
• S/4HANA implementation or conversion
• data migration and remediation
• integration development
• testing and cutover
• training and change management
• hypercare and post-go-live support
• travel and on-site expenses
• cloud, infrastructure, and third-party costs
• change requests and rate structures

Which Assumptions Could Change the Final Cost?

Review:

• scope boundaries
• exclusions
• dependencies
• client responsibilities
• milestones
• payment terms
• service-level commitments
• liability provisions
• termination and transition conditions

Pay particular attention to assumptions about data quality, interface volumes, custom-code remediation, testing cycles, business availability, and internal resources.

For example, a proposal may assume that the client provides clean master data or completes part of the testing effort. Those assumptions can shift substantial work back to the enterprise.

Change-request provisions should define how additional work is assessed, estimated, approved, and documented.

For multi-year migrations, also address key-person changes, subcontracting, knowledge transfer, and the transition from implementation to support.

16. Evaluate Total Cost of Ownership

The implementation price covers only part of the financial impact of an S/4HANA migration.

Two proposals with similar implementation costs can produce different total costs when they require different levels of internal effort, custom development, integration support, or post-go-live resources.

The TCO assessment should include:

• implementation and partner fees
• internal business and IT resources
• data cleansing and remediation
• integration development and maintenance
• custom-code assessment and remediation
• testing and repeated migration cycles
• training and change management
• cutover and post-go-live support
• cloud, infrastructure, licenses, and third-party services where applicable

How Will the Proposed Architecture Affect Future Costs?

The partner should explain the operating costs associated with its recommended S/4HANA architecture.

Consider the number of:

• custom extensions
• integrations
• applications
• environments
• support responsibilities
• external dependencies

Custom development can create future testing and maintenance work. A large integration footprint can require additional monitoring and support. A complex architecture can increase the number of teams involved when an issue crosses system boundaries.

These costs can remain for years after the migration project ends.

Compare proposals against the expected operating model, not implementation fees alone. The analysis should show what the enterprise will need to spend to implement, operate, maintain, and change the proposed S/4HANA environment over the period used for the business case.

SAP S/4HANA Migration Partner Scorecard

A scorecard makes partner evaluations more consistent across technical, operational, and commercial criteria.

Each shortlisted provider should receive the same questions, evidence requirements, and scoring method.

The following weighting gives greater importance to capabilities that directly affect migration decisions and execution:

How Should the Weighting Change?

The weighting should reflect the migration's specific risk profile.

A highly customized manufacturing environment may assign more weight to architecture, custom-code remediation, data, and industry expertise.

A global company with hundreds of interfaces may increase the weight for integration capability.

A complex system conversion with a short production window may give additional weight to migration experience, testing, and cutover.

The scorecard can support different projects as long as the weighting reflects the risks most likely to affect the migration outcome.

Red Flags When Choosing an S/4HANA Migration Partner

Certain statements during partner evaluation can reveal gaps in the proposed approach. The statement itself does not prove that a provider lacks capability. Ask for evidence, assumptions, and project examples before accepting the partner's position.

“We already know which migration approach you need.”

The partner should reach a recommendation after examining the ECC landscape, custom code, data, business processes, organizational structure, integrations, and transformation objectives.

“We can migrate everything as it stands today.”

A migration can carry obsolete data, unused custom developments, inefficient processes, and legacy integrations into S/4HANA. The partner should explain what requires retention, remediation, replacement, archiving, or retirement.

“Your data can be loaded once we extract it.”

Data migration requires profiling, cleansing, mapping, transformation, validation, mock migrations, and reconciliation. Loading data alone does not address data quality or prove that target data supports business processes correctly.

“We will keep your existing customizations.”

Existing ECC custom code may depend on functionality that changed in S/4HANA. Some developments may no longer serve a current business requirement. The partner should assess each significant customization and explain whether it will be retired, replaced, remediated, or redesigned.

“Our standard methodology covers every S/4HANA project.”

The methodology should account for the actual system landscape, migration path, data volume, custom code, interfaces, business processes, and project constraints.

“We will introduce the delivery team after the contract is signed.”

The enterprise should know who will lead architecture, migration, data, integration, testing, cutover, and functional work before selecting the partner.

“We can deliver the migration for this price.”

A low headline price may result from assumptions that exclude significant work. Check whether the proposal covers data remediation, custom-code analysis, integrations, testing cycles, cutover, travel, third-party costs, and post-go-live support.

“We have a cutover plan. We can share the details later.”

Cutover planning should define final data migration, transaction freeze, interface handling, reconciliation, user access, validation, go/no-go criteria, and recovery procedures.

“Go-live completes the migration.”

Production deployment begins the operational phase. The partner should define stabilization, incident handling, knowledge transfer, performance monitoring, and transition to ongoing support before go-live.

Practical SAP Partner Selection Process

A structured selection process gives each candidate the same information, evaluation criteria, and opportunity to demonstrate its capabilities.

The process should move from defining requirements to testing each partner's proposed approach against the actual SAP landscape.

1. Define

Document the current ECC landscape, business objectives, constraints, migration requirements, and mandatory capabilities.

Include custom code, integrations, geographic scope, data volumes, internal resources, and required timeline.

2. Build a Longlist

Identify partners with relevant S/4HANA migration experience, US delivery capabilities, industry knowledge, and technical expertise.

Use comparable projects as a filter rather than relying on overall SAP market presence.

3. Qualify

Remove providers that fail mandatory requirements before investing time in detailed proposals.

Qualification criteria can include relevant migration references, required SAP capabilities, security requirements, delivery coverage, and experience with the target industry or migration scenario.

4. Shortlist

Invite qualified partners to submit detailed proposals.

Require each proposal to describe:

• migration approach
• target architecture
• scope and deliverables
• assumptions
• client responsibilities
• delivery team
• timeline
• testing and cutover strategy
• commercial model
• post-go-live support

5. Run Assessment Workshops

Give shortlisted partners enough information about the current landscape to discuss real migration decisions.

Ask them to challenge assumptions, identify dependencies, and explain how they would approach:

• architecture
• data
• custom code
• integrations
• testing
• cutover
• business-process changes

6. Validate

Test the claims made during the proposal process against independent evidence.

Check:

• customer references and comparable project outcomes
• proposed team members and their actual migration experience
• migration methodology and project controls
• architecture decisions and Clean Core approach
• data, custom-code, and integration assumptions
• commercial scope, exclusions, and change-request terms
• security responsibilities and delivery controls
• post-go-live support and knowledge-transfer arrangements

7. Select

Choose the partner whose evidence, proposed team, technical approach, delivery model, and commercial terms fit the enterprise's specific migration requirements.

The final decision should reflect the risks and objectives established at the beginning of the selection process, including the expected cost of operating the resulting S/4HANA environment.

Let’s Sum up, What Makes a Strong S/4HANA Migration Partner?

A strong S/4HANA migration partner needs capabilities across the full transformation lifecycle.

Technical expertise should cover S/4HANA migration, data, integrations, SAP BTP, Clean Core, testing, and cutover. The partner should also understand how these decisions affect business processes and the future SAP operating model.

Business expertise matters when the migration changes finance, procurement, manufacturing, warehouse, logistics, or other core processes. Relevant industry experience helps the partner account for the operational requirements behind those processes.

Change management and value measurement provide a way to prepare users and determine whether expected business outcomes materialize.

Delivery capability brings these areas together. Look for:

• proven migration methodology
• clear governance
• experienced specialists
• US delivery coverage
• transparent commercial terms
• defined post-go-live responsibilities

The relationship should extend beyond production deployment through hypercare, managed services, optimization, and support for future SAP changes.

The strongest candidates can connect these capabilities within one delivery model. That matters when a decision in one area affects another — for example, when an architecture choice changes integration requirements, custom-code remediation, testing scope, or long-term operating costs.

Why LeverX Is Your S/4HANA Migration Partner in the USA

For US enterprises, the right migration partner needs to combine SAP expertise with the ability to deliver in a complex enterprise environment. LeverX brings the experience, technical capabilities, and delivery model needed to support S/4HANA migration programs in the US market.

The result is a migration partnership that extends beyond the technical move to S/4HANA and supports the US enterprise's transition from migration planning to a sustainable SAP operating environment.

FAQ

Should I choose a large SAP system integrator or a specialist partner?

Company size should follow the program's delivery requirements. A large integrator may provide broader geographic coverage and resources, while a specialist may offer deeper expertise in a specific migration scenario. Compare the capabilities and experience of the actual delivery team.

How do I assess an SAP partner's migration methodology?

Ask the partner to map its methodology against the real landscape: assessment, design, data, custom code, testing, cutover, and stabilization. For each phase, look for defined decision points, dependencies, quality gates, deliverables, and ownership.

What should an SAP S/4HANA migration proposal include?

The proposal should cover the migration approach, target architecture, scope, deliverables, assumptions, client responsibilities, delivery team, timeline, testing and cutover strategy, commercial terms, and post-go-live model. Pay particular attention to exclusions and client-side responsibilities.

How do I compare SAP migration partner proposals?

Normalize proposals against the same scope and assumptions before comparing price. Score the technical approach, delivery evidence, team composition, risk allocation, excluded work, internal resource requirements, and expected future operating costs.

How important is data migration expertise?

Data migration can determine whether critical business processes work correctly after go-live. Evaluate the partner's ability to profile source data, define transformation rules, reconcile results, and run repeated migration cycles under production-like conditions.

How should I evaluate SAP Clean Core expertise?

Ask how the partner will decide between standard S/4HANA functionality, in-app extensibility, and side-by-side extensions on SAP BTP. Strong Clean Core expertise should include a method for identifying customizations that can be retired and controlling new extensions over time.

How do I assess the actual SAP migration delivery team?

Review the named people who will own architecture, migration, data, integration, testing, cutover, and functional work. Compare their experience with the proposed project against the credentials presented during the sales process, and clarify subcontracting and resource-replacement rules.

What should I look for in post-go-live S/4HANA support?

Look for defined incident priorities, escalation paths, response targets, knowledge transfer, monitoring responsibilities, and a clear transition from hypercare to ongoing support. The model should also explain how recurring issues lead to permanent fixes rather than repeated incident handling.

Disclaimer: The information in this article is provided for general informational purposes only and does not constitute professional, legal, financial, or technical advice. SAP products, services, features, and migration options may change over time. Specific migration requirements, timelines, costs, and recommended approaches depend on each organization’s SAP landscape, business processes, data, and technical environment. Consult qualified SAP professionals to assess your specific requirements before making migration or implementation decisions.