How to Choose an SAP S/4HANA Migration Partner in the UK
Moving from SAP ECC to SAP S/4HANA is not simply a technical upgrade. For most organisations, it affects business processes, data, integrations, custom developments, users, infrastructure, and the long-term operating model.
That makes the choice of an SAP S/4HANA migration partner one of the most important decisions in the programme.
The right partner should do more than configure SAP. It should be able to assess the existing landscape, recommend an appropriate transition strategy, manage data and integrations, control customisation, support business change, and take responsibility for a controlled go-live.
For UK organisations, there are additional considerations. Companies may need a delivery model that combines UK-based business engagement with distributed SAP expertise, while also accounting for UK localisation, regulatory requirements, existing supplier relationships, and the complexity of multinational operations.
This guide explains what to look for in an SAP migration partner, how to compare providers, what questions to ask, which red flags to watch for, and how to structure an SAP migration RFP.
Choosing an SAP Migration Partner: The 10 Things to Evaluate
Before comparing individual SAP consultancies or system integrators, establish the criteria that matter to your programme.
A strong evaluation should cover at least:
- SAP S/4HANA migration experience
- Migration methodology
- Business and industry expertise
- Data migration capability
- Integration expertise
- Clean Core and custom-code strategy
- Delivery model and UK presence
- Actual project team
- Commercial transparency
- Post-go-live support
No single criterion should determine the decision.
A partner with extensive SAP experience but limited understanding of your industry, integrations, or data landscape may create more risk than a provider with a smaller but more relevant track record.
1. Evaluate SAP S/4HANA Migration Experience
The first question should not be:
“Does this company work with SAP?”
It should be:
“Has this partner delivered migrations comparable to ours?”
SAP S/4HANA transformation can involve different approaches, including system conversion, new implementation, and selective data transition. Each has different technical, data, testing, and organisational implications.
Ask potential partners about their experience with:
- SAP ECC to SAP S/4HANA transformations;
- system conversions;
- new implementations;
- selective data transition;
- SAP S/4HANA Cloud Private Edition;
- SAP S/4HANA Cloud Public Edition where appropriate;
- complex integration landscapes;
- large data volumes;
- multi-country deployments;
- manufacturing and supply-chain processes;
- post-go-live stabilisation.
The quality of experience matters more than the number of projects claimed.
A partner should be able to explain what was difficult, what decisions were made, what risks were encountered, and how they were addressed.
2. Assess the Migration Methodology
There is no universal migration methodology that can simply be applied to every SAP customer.
The partner should first understand the starting environment and business objectives, then recommend an appropriate transition approach.
System Conversion
A system conversion can preserve much of the existing SAP environment while transitioning to S/4HANA.
It may be appropriate when:
- existing processes remain effective;
- the organisation wants to limit business disruption;
- substantial configuration needs to be retained;
- the business is not looking for a complete process redesign.
However, a conversion should not become an excuse to carry unnecessary technical debt into S/4HANA.
New Implementation
A new implementation establishes a new S/4HANA environment and redesigned business processes.
This can be appropriate where the ECC environment contains:
- extensive customisation;
- fragmented processes;
- obsolete functionality;
- poor master data;
- significant technical debt;
- inconsistent business processes.
Selective Data Transition
Selective transition can provide a middle ground where an organisation needs to preserve selected data or business structures while redesigning other parts of the landscape.
This may be relevant for complex organisations, including businesses with multiple entities, acquisitions, legacy data requirements, or consolidation objectives.
The important point is that the partner should recommend the migration approach based on evidence, rather than selling the methodology it happens to prefer.
3. Look for Business and Industry Expertise
SAP migration is a business transformation as much as a technology programme.
A partner should understand how your organisation actually operates.
For example, an automotive manufacturer may need to consider:
- production planning;
- BOMs and routings;
- supplier schedules;
- quality management;
- warehouse processes;
- plant maintenance;
- manufacturing execution;
- logistics;
- customer delivery requirements.
A financial services organisation will have a very different set of priorities.
For UK businesses, relevant experience may include:
- UK finance and tax processes;
- manufacturing;
- retail;
- logistics;
- supply chain;
- aerospace and defence;
- automotive;
- pharmaceuticals;
- energy;
- regulated industries.
Ask for references from organisations with similar business complexity, rather than simply accepting a list of SAP projects.
4. Evaluate Data Migration Capability
Data is one of the most underestimated parts of an SAP transformation.
A migration partner should be able to explain how it will address:
- master data;
- transactional data;
- historical data;
- open items;
- balances;
- organisational structures;
- customer and supplier data;
- material data;
- data quality;
- reconciliation;
- archiving;
- data validation.
The critical question is not:
“Can you migrate our data?”
It is:
“What data should be migrated, what should be transformed, what should be archived, and how will you prove that the target data is correct?”
A credible partner should have a defined data migration methodology, tooling, validation processes, and reconciliation approach.
Look Beyond Methodology: Ask About Migration Accelerators
Migration programmes can benefit from specialised tools that automate or standardise parts of data assessment, transformation, validation, and migration.
For example, LeverX has developed the LeverX Data Management Platform, which can support organisations in managing data-related activities during SAP transformation programmes.
The broader point is important when evaluating providers: ask whether the partner has proven accelerators, reusable assets, or proprietary tools that can reduce manual effort and improve migration control.
Tools should complement - not replace - a sound migration methodology.
5. Assess SAP Integration Expertise
Most SAP environments are connected to a wider enterprise architecture.
An SAP S/4HANA migration can affect integrations with:
- MES;
- PLM;
- WMS and SAP EWM;
- SAP TM;
- CRM;
- e-commerce;
- banking platforms;
- tax systems;
- supplier platforms;
- logistics providers;
- data warehouses;
- analytics platforms;
- cloud applications;
- automation and warehouse control systems.
A migration partner should create an integration inventory early in the programme.
This should identify:
- interfaces;
- APIs;
- middleware;
- message flows;
- ownership;
- dependencies;
- monitoring;
- error handling;
- security requirements.
The partner should also determine which integrations should be retained, redesigned, replaced, or retired.
A migration that focuses only on SAP configuration while leaving integrations until late in the project is a significant risk.
6. Check Clean Core and Custom-Code Expertise
One of the biggest mistakes in an S/4HANA transformation is treating existing ECC customisation as something that should automatically be carried forward.
A proper assessment should identify:
- custom ABAP;
- modifications;
- enhancements;
- user exits;
- custom transactions;
- reports;
- interfaces;
- workflows;
- forms;
- bespoke applications.
Each should be classified.
The business may decide to:
Retain → Redesign → Replace with standard functionality → Rebuild as an extension → Retire
This is where Clean Core principles become important.
The migration partner should be able to explain how custom developments will be assessed and how extensions will be managed in the target architecture.
A credible partner should also distinguish between:
- technical compatibility;
- business necessity;
- strategic value;
- clean-core compliance.
Simply making legacy custom code work on S/4HANA is not necessarily a successful transformation.
7. Evaluate the UK Delivery Model
For UK organisations, delivery capability matters.
A partner does not necessarily need every consultant to be permanently based in the UK. However, the delivery model should be clear.
Ask:
- Who will lead the programme?
- Where will key project resources be located?
- Who will work directly with UK business stakeholders?
- What work will be delivered offshore or nearshore?
- How will time zones be managed?
- How will escalation work?
- Who will be available during cutover?
- Can the partner support UK operations after go-live?
A hybrid model can combine local business engagement with broader SAP expertise.
The important issue is not geography alone. It is how accountability, communication, expertise, and decision-making are organised.
8. Find Out Who Will Actually Deliver the Project
One common problem with large consulting engagements is the difference between the team presented during the sales process and the team that eventually delivers the project.
Ask for the proposed delivery structure before signing.
Understand who will be responsible for:
- programme management;
- solution architecture;
- SAP functional design;
- technical architecture;
- data migration;
- integration;
- testing;
- change management;
- cutover;
- hypercare.
Ask which roles are:
- named;
- allocated;
- subcontracted;
- offshore;
- nearshore;
- shared across projects.
The partner should be able to demonstrate that the senior expertise presented during the selection process will remain involved throughout the programme.
9. Compare Commercial Models Carefully
The cheapest SAP migration proposal is not necessarily the lowest-cost project.
Compare proposals across the total programme scope, including:
- discovery;
- architecture;
- SAP configuration;
- development;
- data migration;
- integration;
- testing;
- change management;
- training;
- cutover;
- hypercare;
- project management;
- travel;
- third-party solutions;
- post-go-live support.
Look carefully at exclusions.
A proposal can appear inexpensive because important activities are treated as future change requests.
What Should an SAP Migration Proposal Clearly Define?
At minimum:
- scope;
- assumptions;
- deliverables;
- milestones;
- responsibilities;
- dependencies;
- resource model;
- pricing model;
- change-control process;
- travel assumptions;
- third-party costs;
- testing responsibilities;
- cutover scope;
- support period.
Commercial transparency is particularly important for large, multi-year SAP programmes.
10. Assess Post-Go-Live Support
Go-live is not the end of an SAP migration.
The organisation will need to manage:
- production incidents;
- performance;
- integrations;
- user adoption;
- data issues;
- process optimisation;
- enhancements;
- security;
- SAP releases;
- continuous improvement.
Ask whether the migration partner can provide:
- hypercare;
- application management services;
- SAP Basis support;
- functional support;
- integration support;
- monitoring;
- optimisation;
- future S/4HANA enhancements.
A partner that understands the post-go-live operating model can design the implementation with long-term supportability in mind.
How Much Does an SAP Migration Partner Cost in the UK?
There is no universal price for an SAP S/4HANA migration.
The total cost depends on factors such as:
- number of SAP users;
- company and plant structure;
- number of countries;
- migration approach;
- custom code;
- data volumes;
- integrations;
- SAP modules;
- manufacturing complexity;
- reporting requirements;
- cloud deployment;
- testing requirements;
- change management;
- project duration.
A useful way to think about the total cost is:
Assessment + Design + Build + Data + Integration + Testing + Change + Cutover + Hypercare + Ongoing Support
UK organisations should also distinguish between implementation costs and recurring costs associated with the future SAP operating model.
The evaluation should therefore focus on total cost of ownership, not simply the headline implementation fee.
SAP Migration Partner Evaluation Checklist
Use the following framework when comparing potential providers:
| Criteria | What to Ask | Evidence to Request |
| S/4HANA experience | How many comparable migrations have you delivered? | Case studies, references |
| Migration approach | How will you determine the right transition path? | Assessment methodology |
| Industry expertise | Have you migrated similar business processes? | Relevant references |
| Data migration | How will data be cleansed, transformed and reconciled? | Data methodology |
| Integration | How will existing interfaces be assessed? | Integration approach |
| Clean Core | How will custom code be evaluated? | Custom-code methodology |
| Delivery | Who will actually deliver the programme? | Named project team |
| UK capability | How will UK stakeholders be supported? | Delivery model |
| Tooling | What accelerators do you use? | Demonstrations / examples |
| Commercials | What is included and excluded? | Detailed SoW |
| Support | What happens after go-live? | AMS / hypercare model |
| References | Can we speak to comparable customers? | Customer references |
This helps move the selection process from “Which consultancy looks most impressive?” to “Which partner presents the lowest delivery risk for our specific transformation?”
How to Compare SAP Migration Partners
When several providers appear qualified, use a structured scoring model.
For example:
| Evaluation Area | Suggested Weight |
| Relevant S/4HANA experience | 20% |
| Migration methodology | 15% |
| Industry expertise | 10% |
| Data migration | 10% |
| Integration capability | 10% |
| Clean Core / custom code | 10% |
| UK delivery model | 5% |
| Project team | 5% |
| Commercial model | 10% |
| Post-go-live support | 5% |
The exact weighting should reflect the organisation's priorities.
For a manufacturing business, integration and industry expertise may deserve greater weight. For a highly customised ECC environment, data and custom-code capabilities may be more important.
The goal is to establish a transparent selection process that can be defended internally.
How to Build an SAP S/4HANA Migration RFP
A well-structured RFP helps organisations compare providers on the same basis.
An SAP migration RFP should typically include:
1. Company and Business Context
Describe:
- business structure;
- countries;
- sites;
- key processes;
- strategic objectives.
2. Current SAP Landscape
Document:
- SAP releases;
- modules;
- custom developments;
- integrations;
- databases;
- third-party applications;
- infrastructure.
3. Migration Scope
Define what is expected to change and what must remain.
4. Target Architecture
Where known, describe the preferred deployment model and architectural objectives.
5. Data Requirements
Specify:
- master data;
- historical data;
- open transactions;
- data quality;
- retention;
- reconciliation requirements.
6. Integration Requirements
List major internal and external systems and expected integration responsibilities.
7. Testing and Cutover
Ask providers to explain how they will manage:
- functional testing;
- integration testing;
- performance testing;
- user acceptance testing;
- cutover;
- rollback planning;
- hypercare.
8. Project Team
Require providers to identify key roles and responsibilities.
9. Commercial Response
Request a consistent pricing structure so proposals can be compared fairly.
10. References
Ask for customers with comparable:
- SAP landscape;
- industry;
- size;
- migration approach;
- geographic complexity.
A strong RFP should make it difficult for providers to hide important assumptions behind a low headline price.
10 Red Flags When Choosing an SAP Migration Partner
Certain answers should make a prospective customer pause.
“We can migrate you in six months.”
A timeline without a landscape assessment is not a credible migration plan.
“The migration is mostly technical.”
S/4HANA transformation can affect business processes, data, integrations, roles, reporting and operating models.
“Your custom code can simply be carried over.”
Custom code needs to be assessed against business value, compatibility and the target architecture.
“We will assess integrations later.”
Integration dependencies should be understood early.
“Data migration is straightforward.”
Data quality, historical information, open transactions and reconciliation can create significant complexity.
“Our offshore team will handle most of the project.”
An offshore delivery model can work well, but accountability, governance and stakeholder engagement need to be explicit.
“The senior architect will join when needed.”
Senior architecture should not disappear after the sales process.
“The estimate is based on similar projects.”
Your SAP landscape is not necessarily comparable to another customer's.
“Anything outside this scope will be a change request.”
A large number of exclusions can make an apparently attractive proposal expensive later.
“Go-live is the end of the project.”
The first weeks and months after go-live are critical to stabilising the new environment.
Questions to Ask an SAP Migration Partner
Before selecting a provider, ask:
- Which SAP S/4HANA migrations have you delivered that are comparable to ours?
- What migration approach would you recommend and why?
- What assumptions are you making about our current SAP landscape?
- How will you assess custom code?
- How will you approach data migration and reconciliation?
- How will you assess our integrations?
- Which migration accelerators or tools do you use?
- How will Clean Core principles be applied?
- Who will be our solution architect?
- Who will actually deliver the project?
- What work will be delivered from the UK, offshore or nearshore?
- How will you manage business change?
- What is included in the proposed price?
- What is explicitly excluded?
- What happens if the programme encounters unexpected complexity?
- How will testing be structured?
- What is your cutover methodology?
- How long is hypercare?
- What support model do you recommend after go-live?
- Can we speak to customers with similar SAP environments?
The quality of the answers is often more revealing than the presentation itself.
SAP Migration Partner vs SAP Consultant vs System Integrator
These terms are sometimes used interchangeably, but they can represent different capabilities.
An SAP consultant may provide specialist expertise in a particular module, process, or technical area.
An SAP system integrator may have the scale and resources to deliver a large transformation across multiple SAP and non-SAP systems.
An SAP migration partner should ideally combine:
Strategy + Architecture + SAP Expertise + Data + Integration + Delivery + Change + Support
For a complex S/4HANA programme, the ability to coordinate these areas can be more important than having the largest number of consultants.
SAP Migration Partner Selection for UK Manufacturers
Manufacturing organisations should place particular emphasis on operational integration.
The SAP landscape may connect:
Engineering → Planning → Procurement → Production → Quality → Warehouse → Logistics → Finance
A migration partner needs to understand the dependencies between these processes.
For example, changing material master data can affect procurement, production, inventory, warehouse operations, quality processes and financial postings.
Testing should therefore extend beyond SAP application screens and cover real end-to-end scenarios.
Relevant experience may include:
- discrete manufacturing;
- process manufacturing;
- automotive;
- aerospace;
- industrial manufacturing;
- engineering;
- supply chain;
- warehouse operations.
SAP Migration and the UK Regulatory Environment
A migration partner should also understand the organisation's regulatory and data requirements.
Depending on the business, this can include:
- UK tax and finance requirements;
- UK GDPR;
- data protection;
- audit requirements;
- cybersecurity;
- industry-specific regulation;
- segregation of duties;
- financial controls.
The partner should clearly define responsibilities between the customer, SAP, cloud provider, implementation team, and other third parties.
SAP S/4HANA Migration Tools and Accelerators
Migration programmes often involve large amounts of repetitive analysis and data work.
A capable partner should be able to explain where tools and accelerators can reduce manual effort.
Potential areas include:
- data profiling;
- data cleansing;
- mapping;
- transformation;
- validation;
- reconciliation;
- migration monitoring;
- custom-code analysis;
- testing;
- integration monitoring.
For example, LeverX Data Management Platform is designed to support data management activities within complex transformation programmes.
The important selection criterion is not simply whether a provider has a proprietary tool.
Ask:
Does the tool solve a real problem in our migration, and can the partner demonstrate how it improves control, quality, speed, or visibility?
SAP Migration Strategy Should Start Before the Implementation
A common mistake is to select an implementation partner before understanding the current landscape.
A better sequence is:
Assess → Define → Select → Design → Build → Migrate → Test → Cut Over → Stabilise
Assess
Establish the current SAP, data, integration and business-process baseline.
Define
Determine the target operating model and migration objectives.
Select
Evaluate SAP migration partners against transparent criteria.
Design
Define the target architecture, processes, data and integration model.
Build
Configure S/4HANA and develop the required extensions and integrations.
Migrate
Execute data preparation, transformation and migration.
Test
Validate business processes, integrations, data, performance and security.
Cut Over
Move to the target environment through a controlled transition.
Stabilise
Resolve production issues and establish the ongoing operating model.
This approach reduces the risk of choosing a partner based on sales messaging before the organisation understands what the programme actually requires.
Two Recommendations from LeverX
Recommendation 1: Do Not Choose a Migration Approach Before Assessing the Landscape
Terms such as brownfield, greenfield and selective transition are useful, but they should not become the starting point.
First establish:
- what works today;
- what does not;
- what should change;
- what data must remain;
- what integrations are critical;
- what customisations create value;
- what the future business model requires.
Then select the migration approach.
Recommendation 2: Evaluate the Partner's Ability to Reduce Complexity
A strong migration partner should not simply move complexity from ECC into S/4HANA.
During the selection process, ask prospective providers:
“What will you help us eliminate, simplify or standardise as part of the migration?”
The strongest answer will usually involve a combination of process simplification, data quality, integration rationalisation, custom-code reduction and Clean Core principles.
How LeverX Supports SAP S/4HANA Transformation
LeverX combines SAP consulting, implementation, integration, data management, and application services to support complex SAP transformation programmes.
Our capabilities can cover:
- SAP S/4HANA migration strategy;
- SAP readiness assessment;
- system conversion;
- new implementation;
- selective transition;
- SAP data migration;
- integration architecture;
- SAP BTP;
- Clean Core strategy;
- custom-code assessment;
- testing;
- cutover;
- hypercare;
- application management.
LeverX also brings proprietary and reusable technology assets to selected transformation scenarios, including the LeverX Data Management Platform for supporting data management and migration activities.
For UK organisations, the objective is not simply to move from ECC to S/4HANA.
It is to establish a more maintainable, integrated and future-ready SAP environment aligned with business priorities.
What Should the Right SAP Migration Partner Look Like?
The right partner should be able to demonstrate five things.
Relevant Experience
It has delivered migrations involving comparable SAP landscapes and business processes.
Technical Depth
It understands SAP architecture, data, integrations, extensions, security and infrastructure.
Business Understanding
It can translate technical decisions into operational and financial outcomes.
Delivery Accountability
It can clearly explain who will deliver the programme and how governance will work.
Long-Term Capability
It can support the organisation after go-live and help evolve the S/4HANA environment.
Ultimately, the best partner is not necessarily the largest SAP consultancy or the one offering the lowest price.
It is the provider that can demonstrate the lowest credible delivery risk for the specific transformation.
Frequently Asked Questions
How do I choose an SAP S/4HANA migration partner?
Start by assessing the provider's comparable S/4HANA migration experience, methodology, data and integration capabilities, industry expertise, delivery model, project team, commercial transparency, and post-go-live support.
What should I look for in an SAP migration partner in the UK?
Look for relevant S/4HANA experience, UK delivery capability, strong data and integration expertise, industry knowledge, transparent commercial terms, and a clearly defined project team.
What is the difference between greenfield and brownfield SAP migration?
A greenfield implementation creates a new S/4HANA environment and redesigns processes. A brownfield system conversion preserves more of the existing SAP environment while transitioning it to S/4HANA. Selective transition provides another option for organisations that need to selectively retain or transform parts of the existing landscape.
How much does SAP S/4HANA migration cost?
There is no standard price. Cost depends on the SAP landscape, migration approach, data, customisation, integrations, countries, users, testing, change management and target architecture.
How long does SAP S/4HANA migration take?
There is no universal timeline. A simple environment can differ significantly from a multinational SAP landscape with extensive custom code, integrations, data volumes and manufacturing operations. A credible timeline should follow an initial assessment.
Should I choose an SAP partner based on price?
Price should be one factor, not the primary selection criterion. Compare the complete scope, assumptions, delivery team, exclusions, methodology and expected total cost of ownership.
What should an SAP migration RFP include?
An SAP migration RFP should cover the current SAP landscape, business processes, migration scope, target architecture, data, integrations, testing, cutover, project team, commercial requirements, support and customer references.
Why is data migration important in an SAP transformation?
Data migration affects master data, transactional information, balances, open items, historical information and business processes. Poor data quality or incomplete reconciliation can create operational problems after go-live.
Should an SAP migration partner have proprietary tools?
Not necessarily, but proven accelerators can improve efficiency and control in areas such as data management, testing, assessment and migration. Organisations should evaluate the actual value of the tools rather than selecting a provider simply because it owns proprietary technology.
Can a migration partner support us after S/4HANA go-live?
Many SAP partners offer hypercare and ongoing application management. This should be explicitly defined in the contract, including scope, service levels, escalation and responsibilities.
Conclusion
Choosing an SAP S/4HANA migration partner in the UK is ultimately a risk-management decision.
The right provider should be able to connect strategy with execution:
Current SAP landscape → Migration strategy → Target architecture → Data → Integration → Business transformation → Go-live → Continuous improvement
Do not select a partner solely because it has SAP certifications, a large consultant pool, or an attractive initial price.
Instead, evaluate whether the provider can:
- demonstrate relevant S/4HANA migration experience;
- recommend the right transition approach;
- manage complex data migration;
- rationalise integrations;
- apply Clean Core principles;
- understand your industry;
- provide an effective UK delivery model;
- provide the actual team that will deliver the programme;
- offer transparent commercial terms;
- support the organisation after go-live.
For UK organisations preparing for an SAP ECC-to-S/4HANA transformation, a structured partner-selection process can significantly reduce delivery risk and improve the chances of achieving measurable business value from the programme.
Planning an SAP S/4HANA migration in the UK? Talk to LeverX about your current SAP landscape, migration options, data strategy, and target architecture.