A practical guide to SAP S/4HANA transformation, covering migration approaches, business processes, data, custom code, integrations, Clean Core, implementation roadmap, costs, and partner selection.
SAP S/4HANA transformation is more than replacing an ERP system. It can involve business-process redesign, data migration, custom-code remediation, integration modernisation, architecture changes, user adoption, and organisational change.
For organisations running SAP ECC or another legacy SAP ERP environment, the transformation is an opportunity to address technical debt and redesign the digital core around more standardised processes, cleaner data, modern integrations, and a sustainable extension strategy.
SAP supports several transformation paths, including new implementation, system conversion, and selective data transition. The appropriate approach depends on the condition of the current landscape, the desired level of business-process change, data requirements, and the organisation's transformation objectives.
A typical transformation can move from:
Legacy ERP + Custom Code + Fragmented Data + Complex Integrations
to:
SAP S/4HANA + Standardised Processes + Clean Core + Connected Data + Modern Integrations
This guide explains how to approach SAP S/4HANA transformation, how to choose between Greenfield, Brownfield, and Selective Data Transition, what happens to processes, data, custom code, and integrations, and how to build a transformation roadmap that supports long-term business goals.
SAP S/4HANA transformation is a business and technology programme, not simply a system upgrade. LeverX supports organisations from landscape assessment and transformation strategy through migration, process redesign, data, integration, Clean Core, testing, go-live, and optimisation. Talk to our SAP S/4HANA experts
SAP S/4HANA transformation is the process of moving an organisation to SAP S/4HANA while modernising the processes, data, applications, integrations, and technology architecture around the ERP core.
The transformation may start from:
The key distinction is between migration and transformation.
Migration focuses on the technical question:
How do we move our existing ERP environment to SAP S/4HANA?
Transformation takes a broader business perspective:
What should our processes, data, applications, integrations, and operating model look like after the move?
This distinction has practical consequences. A technical migration can preserve proven processes and reduce disruption, but it may also carry forward unnecessary customisations, fragmented integrations, outdated data structures, and inefficient ways of working.
An S/4HANA transformation creates an opportunity to rethink the ERP landscape rather than simply reproduce it on a new platform. Organisations can evaluate which capabilities should be preserved, standardised, redesigned, replaced, or removed.
A useful way to frame this decision is:
Retain → Standardise → Redesign → Replace → Retire
The goal is not to change everything. It is to create a simpler, more integrated, and future-ready enterprise architecture that supports business priorities while making better use of SAP S/4HANA capabilities.
Organisations rarely transform to SAP S/4HANA for a single reason. In most cases, the decision is driven by a combination of technology constraints, operational challenges, business priorities, and the need to create a foundation for future growth.
Common transformation drivers include:
For existing SAP customers, the lifecycle of the current ERP environment is an important strategic consideration. However, S/4HANA transformation should not be treated simply as a technical replacement project.
SAP S/4HANA can provide a foundation for modern capabilities across cloud ERP, Clean Core, embedded analytics, automation, and AI. The real opportunity is to use the transition to simplify the landscape, standardise processes, improve data quality, and enable new ways of working.
The business case should therefore go beyond:
“We need to replace ECC.”
Instead, it should answer:
“What measurable business value will the transformation create?”
That value may include lower operating costs, faster processes, better data visibility, reduced technical complexity, improved scalability, and greater ability to adopt new digital capabilities.
A successful transformation connects the S/4HANA programme to clear business outcomes rather than treating ERP modernisation as an IT initiative alone.
Before selecting a transformation or migration approach, organisations should establish why the investment makes business sense. A strong business case connects current pain points with measurable improvements and the long-term value of a modern ERP landscape.
Assess the cost and risk of maintaining the current landscape:
Identify where the current ERP environment limits efficiency:
Evaluate the quality and accessibility of business data:
Consider opportunities to improve financial operations and visibility:
Assess how effectively the organisation manages its supply chain:
Consider whether the current landscape can support future business requirements:
The business case can be structured as a simple value chain:
Current Pain Points → Transformation Opportunities → Expected Benefits → Required Investment → Business Case
Where possible, expected benefits should be translated into measurable KPIs—for example, shorter financial close times, lower inventory levels, reduced manual effort, fewer customisations, faster order processing, or lower IT operating costs.
The strongest S/4HANA business cases combine technical necessity with measurable business outcomes. The goal is not simply to justify an ERP migration, but to demonstrate how transformation can improve the organisation's performance, resilience, and ability to support future growth.
An S/4HANA transformation can affect nearly every layer of the enterprise, from business processes and data to applications, technology, people, and governance.
Core processes across Finance, Procurement, Manufacturing, Sales, Supply Chain, and Asset Management may be standardised, simplified, or redesigned around SAP S/4HANA capabilities and SAP best practices.
The objective is not to replicate every legacy process, but to determine where the organisation can adopt standard functionality, eliminate unnecessary complexity, or redesign processes to deliver better business outcomes.
Legacy master and transactional data must be assessed, cleansed, mapped, transformed, migrated, and validated.
Transformation is an opportunity to address duplicate records, obsolete data, inconsistent structures, and weak governance before they become part of the new S/4HANA environment.
ABAP developments, modifications, enhancements, reports, and interfaces need to be reviewed for technical compatibility, business relevance, and long-term value.
Organisations may decide to retain, remediate, replace, or retire custom developments as part of a broader Clean Core strategy.
Existing interfaces and integrations need to be assessed individually. They may be retained, redesigned, replaced, consolidated, or retired depending on the target architecture and business requirements.
This can include integrations between S/4HANA, SAP applications, third-party systems, data platforms, and external services.
The target landscape may extend well beyond the S/4HANA core. It can include SAP BTP, SAP applications, third-party platforms, integration services, analytics, automation, and AI capabilities.
The transformation therefore requires a clear target architecture that balances standardisation, flexibility, scalability, security, and integration.
Transformation changes how employees interact with business systems and processes. Users may need new roles, responsibilities, workflows, SAP Fiori applications, training, and ongoing support.
Change management and adoption are therefore critical to turning technical implementation into actual business value.
Transformation also introduces new requirements for decision-making, architecture governance, data ownership, security, compliance, and ongoing ERP management.
Without clear governance, organisations can gradually rebuild the complexity that the transformation was intended to remove.
The transformation can therefore be viewed as a coordinated change across:
Processes + Data + Applications + Technology + People + Governance
The goal is to align these elements around a simpler, integrated, and future-ready enterprise operating model.
The three major approaches are Greenfield, Brownfield, and Selective Data Transition.
Greenfield creates a new S/4HANA environment and designs the target solution around the future operating model.
It can be appropriate when the organisation wants to:
The advantage is maximum freedom to redesign.
The trade-off is greater effort in process design, data preparation, integration, testing, and change management.
Brownfield converts an existing SAP environment to S/4HANA while retaining a significant amount of existing configuration, processes, and data.
It can be appropriate when:
The main risk is carrying unnecessary complexity forward.
A Brownfield transformation should therefore not become:
ECC Customisation → S/4HANA Customisation
Instead:
Existing Process → Business Value → Standard SAP → Keep / Change / Retire
Selective Data Transition can provide a middle ground when the organisation wants to reuse parts of its existing environment while redesigning or restructuring other areas.
It may be useful for:
The exact scenario depends on the landscape and transition objectives.
| Dimension | Greenfield | Brownfield | Selective Data Transition |
| Process redesign | High | Lower | Selective |
| Legacy reuse | Limited | High | Partial |
| Customisation reduction | Strong opportunity | Requires deliberate remediation | Selective |
| Data reuse | Selective | High | Selective |
| Business disruption | Potentially higher | Generally lower | Managed selectively |
| Best suited to | Major business transformation | Stable existing SAP environments | Complex or multi-system landscapes |
There is no universally best approach.
The correct choice depends on:
Business Change + Technical Debt + Data + Integrations + Organisational Readiness
Selecting a transformation approach should be based on a structured assessment of the current landscape and the desired future state, rather than on a preference for a particular migration method.
Key factors to evaluate include:
A practical decision sequence is:
Assess Current State → Define Target State → Evaluate Transformation Options → Compare Cost / Risk / Value → Select Approach
The assessment should also consider what the organisation wants to change. If the primary objective is to preserve effective processes while modernising the ERP platform, a system conversion may be appropriate. If the organisation wants to fundamentally redesign processes and simplify the landscape, a new implementation may provide greater value. More complex environments may benefit from a selective transition.
Practical recommendation: Do not choose Greenfield or Brownfield simply because one appears “faster” or less disruptive. Compare each option against business value, technical debt, data complexity, implementation risk, business disruption, and the degree of transformation the organisation actually wants to achieve.
The right approach is ultimately the one that best aligns the starting point, target operating model, investment capacity, and transformation ambition.
An S/4HANA transformation does not mean that everything in the existing SAP ERP environment is simply moved to the new system. Depending on the transformation approach, business processes, data, custom code, and integrations may be retained, redesigned, replaced, or retired.
A practical transformation model is:
Existing SAP ERP → Assess → Decide → Transform → Target S/4HANA
The assessment should consider four main areas:
| Existing ERP Element | Potential Transformation Decision |
|---|---|
| Business Processes | Keep → Standardise → Redesign |
| Custom Code | Retain → Remediate → Replace → Retire |
| Data | Migrate → Transform → Archive → Retire |
| Integrations | Keep → Redesign → Consolidate → Retire |
For example, a business process that works well and already aligns with the target S/4HANA model may be retained. A heavily customised process with multiple local variants may be redesigned around standard SAP functionality.
The same principle applies to data. Not every historical customer, material, transaction, or legacy record needs to be transferred to the new environment. Some data may be cleansed and migrated, while other information may be archived or retired.
Custom code also needs to be assessed individually. The objective is not to eliminate all custom development, but to determine whether each development still provides business value and whether it fits the target Clean Core strategy.
Legacy integrations should be reviewed in the same way. Some interfaces may remain essential, while others can be consolidated, replaced with standard APIs, or retired altogether.
This creates an important distinction:
Migration = Moving What Exists
Transformation = Deciding What Should Exist
Practical recommendation: Perform this assessment early and document the decision for every major process, data object, custom development, and integration. It provides a clear basis for scope, effort, cost, and transformation risk before implementation begins.
Transformation also requires a decision about the target deployment model.
Depending on the organisation's needs, the target landscape may include:
The deployment choice affects:
A cloud decision should therefore be made alongside the operating model and architecture, not as a separate infrastructure exercise.
Clean Core is an increasingly important part of S/4HANA transformation.
The goal is to keep the ERP core standard, stable, and easier to evolve, while using appropriate technologies for differentiated requirements.
A simplified architecture is:
S/4HANA Core → Standard Business Processes
SAP BTP / Released APIs → Extensions + Integration
Instead of modifying the ERP core whenever a business-specific requirement appears, organisations should first evaluate:
Standard SAP → Configuration → Released Extension → Side-by-Side Extension → Custom Core Development
This can reduce technical debt and make future upgrades and innovation easier.
Practical recommendation: Make every customisation justify itself against business value, maintenance effort, upgrade impact, and available standard SAP capabilities.
S/4HANA transformation should not be designed module by module.
Instead, organisations should look at end-to-end processes such as:
Procure-to-Pay
Order-to-Cash
Record-to-Report
Plan-to-Produce
Warehouse-to-Delivery
Asset-to-Maintenance
For each process, assess:
Current Process → Pain Point → SAP Standard → Gap → Target Process → Business Outcome
SAP transformation can be an opportunity to reduce the number of process variants across countries and business units.
Practical recommendation: Standardise where process differentiation does not create competitive advantage. Reserve customisation and extensions for requirements that genuinely matter to the business.
Data migration is often one of the most underestimated workstreams in an S/4HANA programme.
Potential migration areas include:
A practical data lifecycle is:
Discover → Profile → Cleanse → Map → Transform → Load → Validate → Reconcile
The goal is not to move everything.
Instead:
Migrate What the Business Needs + Retire What It Does Not
Migration can be used to address:
For organisations moving from ECC to S/4HANA, this is particularly important for customer and vendor data that must align with the Business Partner model.
LeverX supports SAP migration and data-transformation programmes involving assessment, extraction, transformation, validation, and migration.
Long-running SAP environments can contain significant ABAP customisation.
Each custom development should be assessed as:
Retain → Remediate → Replace → Retire
Consider:
The aim is not to eliminate all custom code.
The aim is to eliminate unnecessary custom code and move justified differentiation to the most sustainable architecture.
Legacy SAP landscapes often contain many point-to-point interfaces.
A typical enterprise architecture may include:
S/4HANA ↔ SAP Ariba
S/4HANA ↔ SAP SuccessFactors
S/4HANA ↔ SAP Commerce
S/4HANA ↔ CRM
S/4HANA ↔ Banks
S/4HANA ↔ WMS / TMS
S/4HANA ↔ Third-Party Applications
Each interface should be classified:
Keep → Redesign → Consolidate → Replace → Retire
SAP BTP and modern integration capabilities can help create clearer boundaries between the ERP core and surrounding applications.
Practical recommendation: Do not automatically rebuild every existing interface. Start by understanding what business process the interface supports and whether it is still required.
A modern S/4HANA landscape can be structured around:
Users + Business Processes
↓
SAP S/4HANA Digital Core
↓
SAP BTP / Integration / Extensions
↓
SAP Applications + Third-Party Systems
with:
Data + Analytics + AI
supporting the wider architecture.
The exact model depends on the deployment approach, business requirements, integration landscape, and existing applications.
A good target architecture should make it clear:
Large S/4HANA programmes benefit from a clear view of both business capabilities and technology dependencies.
Before committing to a migration path, organisations should understand:
Business Capabilities → Applications → Data → Integrations → Technology
This can help identify:
The goal is to avoid optimising one SAP system while leaving the wider enterprise architecture fragmented.
A practical roadmap can be structured as:
Assess → Strategise → Design → Prepare → Build → Migrate → Test → Deploy → Stabilise → Optimise
Analyse:
SAP Readiness Check can help identify areas relevant to S/4HANA transformation, including simplification items, custom-code considerations, and compatibility dependencies.
Define:
Define:
Prepare:
Configure, extend, integrate, and develop the target solution.
Run data-extraction, transformation, loading, validation, and reconciliation cycles.
Test:
Unit → Integration → End-to-End → User Acceptance → Cutover
Execute final migration, cutover, user readiness, and go-live.
Run hypercare, monitor processes, resolve issues, and stabilise the operating model.
Continue improving:
SAP Activate provides a structured methodology for SAP implementation and transformation projects.
A typical implementation structure follows:
Discover → Prepare → Explore → Realize → Deploy → Run
The exact application of the methodology depends on the deployment model and project scope.
The important point is that methodology should support business outcomes rather than become a project-management exercise.
Practical recommendation: Combine SAP methodology with clear business-process ownership. Every major workstream should have a business owner responsible for deciding what the future process should be.
Large S/4HANA programmes need strong governance.
A transformation governance model may include:
Some organisations also establish an SAP Center of Excellence (CoE) to maintain architecture, governance, standards, and continuous improvement after go-live.
The CoE can own:
Architecture + Standards + SAP Roadmap + Governance + Continuous Improvement
Technology does not create value unless users adopt the new processes.
Change management may include:
A transformation can fail even when the system works technically if users continue relying on:
The target should be:
System Adoption → Process Adoption → Business Value
Testing should cover the end-to-end business process, not only individual SAP modules.
For example:
Purchase Requisition → Purchase Order → Goods Receipt → Invoice → Payment
or:
Sales Order → Delivery → Billing → Accounts Receivable
or:
Production Requirement → Material Availability → Production → Inventory → Finance
Testing should include:
Practical recommendation: Test business exceptions as aggressively as standard scenarios. Failed approvals, incomplete data, blocked invoices, interface failures, and unexpected transaction volumes often expose the most important risks.
A successful cutover requires more than switching systems on.
Typical activities include:
A practical model is:
Cutover Rehearsal → Final Migration → Validation → Go-Live → Hypercare
The number and complexity of cutover rehearsals should reflect the risk of the transformation.
S/4HANA transformation projects can face challenges across technology, data, processes, governance, testing, and organisational change. Identifying these risks early helps organisations make better decisions about scope, architecture, and the target operating model.
Years of custom development can increase migration complexity, create technical dependencies, and make future maintenance more expensive.
Each custom development should therefore be assessed for its business value, technical relevance, and alignment with the target architecture.
Duplicate, incomplete, or inconsistent master data can create downstream problems across finance, procurement, sales, supply chain, and reporting.
Data cleansing and governance should begin well before migration and continue after go-live.
Legacy point-to-point interfaces can be difficult to maintain and may not align with the target architecture.
Organisations should assess which integrations should be retained, redesigned, consolidated, replaced, or retired.
Different countries, subsidiaries, or business units may use different versions of the same process.
Transformation provides an opportunity to identify where processes can be standardised globally while allowing justified local requirements.
ERP transformation is not solely an IT initiative. Decisions about processes, data, controls, and business requirements require active ownership from the relevant business functions.
Projects can become difficult to control when every local requirement is treated as mandatory.
A clear governance model should distinguish between critical requirements, regulatory needs, valuable differentiators, and preferences that can be addressed through standard functionality.
Testing individual applications or technical components in isolation can miss failures across end-to-end business processes.
Testing should cover integrated scenarios, data flows, interfaces, roles, controls, and critical business processes.
Even a technically successful go-live can fail to deliver value if users continue relying on spreadsheets, manual workarounds, or legacy processes.
Training, change management, process ownership, and post-go-live support are essential for sustainable adoption.
For each significant business or technical gap, organisations should apply a consistent decision framework:
Standardise → Configure → Extend → Integrate → Change the Business Process
The preferred option should generally be the one that minimises unnecessary complexity while meeting the underlying business requirement. This approach supports a cleaner core, reduces technical debt, and helps prevent legacy complexity from being recreated in the new S/4HANA environment.
A successful S/4HANA transformation requires more than a technically sound migration. Organisations should establish clear principles for process design, data, architecture, governance, delivery, and change management from the beginning.
Start with business outcomes rather than software features. Define what the transformation should improve, such as cost efficiency, process standardisation, faster reporting, supply chain visibility, or scalability, and use these outcomes to guide technology decisions.
Adopt SAP standard functionality where it provides sufficient business value. Avoid recreating legacy processes through unnecessary customisation when a standard capability can meet the requirement.
Data should not be treated as a final migration task. Start data assessment, cleansing, ownership, governance, and validation early and make data quality a shared business responsibility.
Clean Core should be considered from the beginning of the transformation. Define clear principles for customisation, extensions, integrations, and modifications before new development starts.
Do not automatically rebuild every legacy interface. Assess each integration for its business value and target-state relevance, then retain, redesign, consolidate, replace, or retire it as appropriate.
Business process owners should actively define and approve the future operating model. IT can provide technical expertise, but business functions should own decisions about how critical processes should work.
Large transformation programmes are easier to govern when divided into meaningful releases, business capabilities, or workstreams. Each increment should have clear scope, ownership, dependencies, and measurable outcomes.
Go-live is not the end of transformation. Track whether users have adopted the new processes and whether the expected business benefits are being realised.
Useful measures can include process cycle times, automation rates, data quality, transaction volumes, system usage, manual workarounds, and business-process KPIs.
The overarching principle is simple:
Standardise Where Possible → Simplify Where Necessary → Extend Where Valuable → Measure the Outcome
There is no universal timeline for an SAP S/4HANA transformation. The duration depends on the complexity of the existing landscape, the desired target state, the transformation approach, and the organisation's readiness.
Key factors include:
As broad planning ranges:
| Programme type | Indicative duration |
|---|---|
| Focused technical conversion | 6–10 months |
| Mid-sized transformation | 9–15 months |
| Complex enterprise transformation | 12–24+ months |
These figures should be treated as planning ranges, not fixed delivery commitments. A focused technical conversion may require significantly less transformation effort than a programme that includes process redesign, data remediation, integration rationalisation, and organisational change.
For larger programmes, activities such as data preparation, process design, integration development, testing, and change management may overlap rather than occur sequentially.
The most reliable timeline can be established after a landscape and readiness assessment that evaluates the current environment, transformation scope, dependencies, risks, and target architecture.
A useful principle is:
More Transformation Scope + More Complexity + More Change = Longer Timeline
The objective should not be to minimise the calendar time at any cost, but to establish a realistic timeline that balances speed, business continuity, risk, and transformation value.
There is no standard price for an SAP S/4HANA transformation. Total investment varies significantly depending on the organisation's size, existing ERP landscape, transformation scope, deployment model, and level of business change.
As broad planning ranges for UK organisations:
| Programme type | Indicative transformation cost |
|---|---|
| Focused S/4HANA conversion | £500k–£1.5m |
| Mid-sized transformation | £1.5m–£4m |
| Large / complex enterprise transformation | £4m–£10m+ |
| Global multi-country transformation | £10m–£30m+ |
These figures are indicative planning ranges, not fixed implementation prices. Actual costs can be significantly higher or lower depending on the specific landscape, scope, and transformation objectives.
Key cost drivers include:
A realistic business case should consider the full transformation cost, including:
Software + Infrastructure + Consulting + Data + Integration + Testing + Change Management + Support
The balance between these components can vary considerably. A focused technical conversion may require relatively limited process redesign, while a broader transformation can require significant investment in data quality, custom-code remediation, integration rationalisation, process redesign, and organisational change.
Organisations should also distinguish between one-time transformation costs and ongoing operating costs. This provides a clearer view of total cost of ownership and helps evaluate the expected return on investment.
Practical recommendation: Use these ranges for initial planning only. Build the final estimate around the complete transformation scope and target operating model, rather than software licensing alone. A detailed landscape and readiness assessment is the best basis for a reliable cost estimate.
The right partner should combine:
Ask:
The strongest partner should be able to explain how the transformation will improve the organisation, not simply how the ERP system will be migrated.
LeverX supports organisations across the full SAP S/4HANA transformation lifecycle - from initial assessment and strategy through migration, implementation, integration, go-live, and ongoing optimisation.
Our capabilities include:
LeverX brings together SAP consulting, data, integration, engineering, and industry expertise to address the technical and business challenges of complex S/4HANA transformation programmes.
This allows organisations to approach transformation as a coordinated programme rather than a series of disconnected technology projects - from defining the target state and selecting the right transformation approach to migrating data, modernising integrations, supporting users through go-live, and optimising the new environment.
Our UK delivery model combines local client and stakeholder engagement with global SAP and engineering expertise. This provides access to specialised resources while maintaining local programme coordination and communication.
Whether an organisation is planning a new S/4HANA implementation, converting an existing SAP ECC environment, or undertaking a broader enterprise transformation, LeverX can help define the strategy, roadmap, architecture, and delivery model around its specific business objectives.
Talk to our SAP S/4HANA experts
SAP S/4HANA transformation is an opportunity to modernise the enterprise rather than simply replace an ERP system.
The strongest programmes connect:
Business Strategy + Processes + Data + Architecture + Technology + People
The transformation journey can be summarised as:
Assess → Strategise → Design → Prepare → Build → Migrate → Test → Deploy → Stabilise → Optimise
The key decision is not simply whether to move to S/4HANA. It is how the organisation wants to operate after the transformation and how much of the existing landscape should be retained, redesigned, replaced, or retired.
A successful transformation should create:
Standardised Processes + Clean Data + Clean Core + Modern Integration + Scalable Digital Core
That foundation can make future SAP innovation, automation, analytics, and AI adoption easier while reducing the burden of legacy technology.
SAP S/4HANA transformation is the process of moving an organisation to SAP S/4HANA while modernising its business processes, data, applications, integrations, technology architecture, and operating model.
Migration focuses primarily on moving an existing ERP environment to S/4HANA. Transformation has a broader scope and can include process redesign, data cleansing, application rationalisation, integration modernisation, Clean Core adoption, and organisational change.
Common drivers include ERP lifecycle considerations, technical debt, excessive customisation, fragmented processes, poor data quality, complex integrations, cloud adoption, automation, analytics, and the need for a modern digital core.
The three main approaches are Greenfield, Brownfield, and Selective Data Transition. The appropriate approach depends on the existing ERP landscape, business-process maturity, data requirements, customisation, integrations, and desired level of transformation.
A Greenfield implementation creates a new S/4HANA environment and allows the organisation to redesign processes, adopt standard SAP functionality, simplify the landscape, and reduce legacy customisation.
Brownfield, or system conversion, transforms an existing SAP ERP environment into S/4HANA while retaining a significant portion of its configuration, processes, and data. It can reduce disruption but may also carry legacy complexity into the new environment.
Selective Data Transition provides a middle path between Greenfield and Brownfield. It allows organisations to retain selected processes or data while redesigning or restructuring other parts of the landscape.
Evaluate technical debt, process quality, customisation, data, integrations, historical-data requirements, business disruption, and desired business change. The decision should balance short-term risk with long-term business value and maintainability.
Clean Core is an approach to keeping the S/4HANA core as standard and maintainable as possible, while using appropriate extensions, integrations, and SAP technologies for requirements that should not be implemented through core modifications.
Custom code should be assessed based on its business value, technical relevance, and compatibility with the target architecture. Depending on the assessment, it may be retained, remediated, replaced with standard functionality, redesigned as an extension, or retired.
Data migration is a critical transformation workstream. Business Partner, customer, supplier, material, financial, asset, and transactional data can affect multiple processes, so data should be profiled, cleansed, mapped, migrated, validated, and reconciled.
Yes. Identifying and addressing duplicate, obsolete, incomplete, and inconsistent data before migration can reduce operational problems and improve reporting and process quality after go-live.
Each interface should be assessed individually and retained, redesigned, consolidated, replaced, or retired based on its business value and relevance to the target architecture.
Not every transformation requires the same SAP BTP scope. SAP BTP can support integration, extensions, automation, application development, and Clean Core strategies, depending on the organisation's target architecture and requirements.
There is no standard timeline. A focused technical conversion may take several months, while a complex multi-country transformation can take 12–24 months or longer. Duration depends on scope, data, customisation, integrations, countries, testing, and organisational change.
There is no standard transformation price. As broad UK planning ranges, a focused conversion may cost around £500,000–£1.5 million, a mid-sized transformation £1.5–£4 million, and a large or complex enterprise programme £4–£10 million+. Global multi-country programmes can exceed £10 million significantly.
These are indicative ranges rather than fixed prices. Actual costs depend on the landscape, scope, users, countries, data, integrations, custom code, deployment model, and change requirements.
Common risks include poor data quality, excessive customisation, complex integrations, unclear scope, weak business ownership, insufficient testing, inadequate change management, and low user adoption.
Start with a detailed landscape and readiness assessment, define the target state early, select the transformation approach based on evidence, clean data before migration, rationalise custom code and integrations, involve business process owners, and conduct multiple migration and testing cycles.
SAP Readiness Check is an SAP assessment capability that helps organisations identify areas relevant to an S/4HANA transition, including simplification items, custom-code considerations, integration dependencies, and other aspects of the existing SAP landscape.
Change management helps employees transition from legacy processes and systems to the target operating model. It typically includes stakeholder communication, training, role preparation, user testing, go-live support, and adoption measurement.
Consider S/4HANA transformation experience, SAP and industry expertise, business-process knowledge, data and integration capabilities, Clean Core expertise, architecture skills, delivery capacity, local stakeholder engagement, and post-go-live support.
Disclaimer: The information in this article is provided for general informational purposes only and does not constitute legal, financial, tax, regulatory, or professional advice. SAP products, capabilities, deployment options, licensing models, and implementation requirements can change over time. Organisations should assess their individual SAP landscape and confirm current SAP capabilities, commercial terms, and applicable local requirements before making transformation decisions.