SAP ECC to S/4HANA Migration: UK Guide, Costs, Timeline and Roadmap

Learn about SAP S/4HANA migration in the UK market, covering strategies, risks, and step-by-step implementation guidance.

SAP is ending mainstream maintenance for ECC 6.0 in January 2027. After that date, your system will not receive security patches, compliance updates, or new integrations. For organisations that still rely on ECC as their core ERP platform, this means they need to determine their long-term strategy: move to SAP S/4HANA, continue using the existing system under available extended support options, or consider other alternatives.

For UK businesses, the question is about more than the ERP lifecycle. Organisations also need to consider changes in the tax and customs environment, data protection requirements, growing integration needs, and the need for more timely information for financial and operational management. The specific requirements vary by industry, business model, and existing system architecture.

SAP S/4HANA is SAP's strategic ERP platform for replacing SAP ERP/ECC. It is built on SAP HANA and uses a simplified data model, changing how transactional and analytical data can be processed. The platform also provides modern capabilities for integration, analytics, extensions, and automation that need to be considered when planning a transition.

This means an ECC migration is not simply a technical replacement of one ERP system with another. Organisations need to decide which processes and data should be retained, what should be changed, which custom developments should be migrated or retired, and what target architecture will support the business after the transition.

This article examines the main reasons UK organisations are considering SAP ECC to S/4HANA migration, the differences between the two platforms, available migration approaches, cost and timeline considerations, common risks, and the practical stages of a migration programme. It also covers real-world Greenfield, Brownfield, Selective Data Transition, and RISE with SAP scenarios.

Short Answer: Migrating to SAP S/4HANA can be costly and complex, but delaying the transition can also create long-term costs associated with an ageing platform, technical debt, customisation, and limitations in the existing architecture. Choosing the right approach allows organisations not only to replace ECC, but also to determine which processes, data, and custom developments genuinely need to move to the new ERP environment.

What Changes When Your Core ERP System Can Actually Keep Up

The end of the SAP ECC lifecycle is often presented as a deadline problem. In practice, it is better understood as a point at which organisations need to reassess whether their existing ERP platform can support future business requirements.

ECC remains a functioning system for many organisations. However, years of operation may have resulted in custom developments, local processes, individual integrations, legacy interfaces, and workarounds becoming embedded in the system. Simply moving to a new platform without assessing this accumulated complexity can therefore transfer existing problems into the new environment.

This is where SAP S/4HANA comes into the picture. If ECC no longer fits the organisation's long-term technology strategy, moving to S/4HANA provides an opportunity to address two issues at the same time: modernise the ERP platform and reconsider how core processes should operate.

That does not mean every organisation needs to redesign its business from scratch. For some companies, the most appropriate option will be a conversion that remains close to the existing system. For others, the migration will be an opportunity to build a new operating model. There are also several options between these two extremes.

Before choosing a specific migration path, it is therefore important to understand what actually changes between ECC and S/4HANA and why those differences matter to the migration project.

SAP ECC 6.0 to SAP S/4HANA migration

SAP ECC 6.0 to SAP S/4HANA Migration

What the 2027 deadline actually means in practice

SAP is ending mainstream maintenance for ECC 6.0 in January 2027. After this point, the applicable support model changes, so organisations need to determine how they will continue operating their ERP environment.

SAP offers extended maintenance options under specific conditions and at additional cost. However, extended support should not be viewed as equivalent to continued mainstream innovation. It does not restore the full development and innovation cycle of the platform.

The business question is therefore broader than simply asking, "What happens after 2027?" Organisations need to consider how much longer they are prepared to invest in the existing architecture and whether ECC can support their future requirements for integration, data, analytics, and operational processes.

This is particularly relevant for UK organisations where ERP systems are connected to tax reporting, financial processes, suppliers, customs operations, or other external platforms. These dependencies should be assessed before the migration strategy is selected.

Why UK requirements should be considered from the beginning

The UK's regulatory environment continues to evolve. For example, Making Tax Digital (MTD) already applies to VAT-registered businesses, while the programme continues to develop for other groups of taxpayers.

This does not mean that moving to S/4HANA automatically makes an organisation compliant with HMRC requirements. Compliance depends on the specific processes, solutions, localisation, integrations, and configuration used by the organisation.

UK requirements should therefore form part of the ERP readiness assessment. The organisation should identify which processes are connected to VAT, PAYE, customs, reporting, and other local requirements, which external systems support those processes, and how they should operate after migration.

The same principle applies to data protection. UK GDPR establishes requirements for processing personal data, including situations where data is transferred outside the UK. The deployment model, data location, cloud services, and access policies should therefore be assessed as part of the target architecture rather than after the technical migration has been completed.

UK compliance is consequently not a separate task to be addressed after moving to S/4HANA. It is one of the factors that should influence architecture, migration planning, and testing from the start of the programme.

What S/4HANA Architecture Enables and Why It Matters for Migration

Once the reasons for moving away from ECC are clear, the next question is: what does an organisation actually gain from moving to S/4HANA?

One of the most important differences exists at the data architecture level.

SAP ECC was designed for traditional ERP environments in which transactional operations, aggregated data, and analytical workloads were often handled through different structures and tools. S/4HANA was designed around SAP HANA and a simplified data model.

SAP HANA uses in-memory, columnar database technology, which can process large volumes of data without relying on many of the traditional aggregate structures used in older ERP architectures. This can reduce intermediate processing and improve the performance of certain analytical and operational scenarios.

However, the difference is not simply about speed. The new architecture also affects how an ERP environment is designed: how data is made available for analytics, how integrations are built, where custom logic is placed, and how the system can be extended over time.

For example, SAP S/4HANA can be used together with SAP BTP for integrations and side-by-side extensions. In manufacturing, this can support more connected planning and analytics scenarios; in retail, it can enable analytical processes based on more current sales and inventory information. The exact capabilities depend on the product version, deployment model, and configuration.

For migration planning, the key question is therefore not only whether the existing ECC system can technically move to S/4HANA, but also what target architecture the organisation wants to have after the transition.

Comparison: SAP ECC 6.0 vs SAP S/4HANA

Comparing SAP ECC and SAP S/4HANA Architecture

The architectural differences matter not only because they explain the technical changes after migration. They also directly affect the scope of the project.

In a Brownfield conversion, the organisation needs to determine which elements of the existing ECC system are compatible with the new architecture and which require remediation. In a Greenfield implementation, the project team has the opportunity to design processes and extensions around S/4HANA and Clean Core principles from the outset.

The main architectural differences can be summarised as follows:

Migration is therefore not simply a matter of moving data from one database to another. Depending on the selected approach, it can affect custom code, integrations, user roles, financial structures, master data, business processes, and the extension model.

SAP ECC 6.0 vs SAP S/4HANA for Finance

The financial function deserves separate consideration because moving to S/4HANA can result in significant structural changes to the way financial data is organised.

In SAP ECC, financial accounting and controlling historically rely on several related components and structures. In S/4HANA, the Universal Journal (ACDOCA) plays a central role by bringing relevant financial and management accounting data together in a common model.

This can reduce the need for certain reconciliation activities and provide a more consistent foundation for financial analytics. However, the actual impact on period-end close, reporting, and other processes depends on configuration, data quality, and the organisation's financial operating model.

These changes are why financial assessment should form a separate part of migration readiness. Even where the technical conversion is successful, the organisation needs to understand how the new financial model affects closing, reporting, integrations, roles, and existing custom developments.

The Business Case from a Total Cost of Ownership Perspective

Once the architectural differences are understood, the next question is economic: what happens to the cost of running the ERP environment if the organisation continues with ECC compared with moving to S/4HANA?

The cost of ECC is rarely limited to software and infrastructure. A mature landscape may also include:

• separate OLTP and analytical environments, where applicable;
• hardware infrastructure and its refresh cycle;
• custom ABAP code that needs to be maintained and tested;
• middleware used to integrate ECC with third-party systems;
• separate reporting and BI platforms;
• support for legacy interfaces;
• specialist resources with knowledge of the specific legacy environment.

Moving to S/4HANA can change some of these cost components. For example, embedded analytics and the new data model may reduce reliance on separate solutions in certain scenarios, while a Clean Core strategy can reduce the amount of custom code maintained inside the ERP.

A cloud deployment model also changes the infrastructure cost structure. However, this does not automatically mean lower TCO. Subscription or licensing costs, implementation, integration, support, change management, and cloud operations all need to be considered together.

The business case should therefore compare not only the cost of the migration programme, but also the expected cost of operating both alternatives over several years.

How Do You Choose the Right SAP S/4HANA Migration Approach?

Understanding the differences between ECC and S/4HANA establishes the direction, but it does not answer the practical question: how should the organisation move from one platform to the other?

There is no single migration path that is right for every organisation. SAP projects generally consider three main approaches: Greenfield, Brownfield, and Selective Data Transition.

The choice depends on the condition of the existing system, the level of customisation, process maturity, historical data requirements, number of systems and legal entities, and how much the organisation wants to change its operating model.

Choosing the wrong approach does not necessarily make migration impossible, but it can increase project cost, duration, complexity, and business impact.

Comparing approaches: Brownfield, Greenfield, and Bluefield

Comparing Greenfield, Brownfield, and Selective Data Transition

Greenfield: starting with a clean system

A Greenfield implementation creates a new S/4HANA environment from the ground up. The existing ECC system is not directly converted; instead, the project team defines the target processes, organisational structure, data, and integrations.

SAP Best Practices can provide a starting point, while deviations from standard processes should have a clear business justification.

This approach is particularly relevant for organisations where the existing ECC system has changed significantly over years of operation. It may contain custom ABAP developments, local modifications, different processes between business units, and workarounds that have gradually become part of standard operations.

In this situation, the question is no longer simply how to move the existing system. A more useful question is:

"What should our future processes look like after moving to S/4HANA?"

Greenfield provides an opportunity to answer that question before the new ERP environment is configured.

The approach can also suit organisations that want to standardise processes across sites or business units. Rather than transferring every historical variation, the project defines a common operating model and retains only those deviations that provide genuine business value.

The main trade-off concerns historical data. It does not automatically move with the existing ECC system. The organisation therefore needs to determine which data should become part of the new operational system, which can be archived, and how users will access historical information after go-live.

For UK organisations, this is particularly important for audit, statutory reporting, and internal data-retention requirements.

Brownfield: transforming the existing system

Brownfield migration, formally known by SAP as System Conversion, converts the existing ECC system to S/4HANA while retaining a significant portion of its configuration and data, subject to compatibility with the target platform.

This can be a natural option for organisations where existing processes work well and do not require major redesign.

The central question is therefore different:

"Which parts of the existing system need to change so that they work correctly in S/4HANA?"

Before conversion, the organisation needs to assess custom code, SAP Simplification Items, add-ons, interfaces, financial structures, Business Partner requirements, and other technical dependencies.

Custom ABAP code deserves particular attention. SAP tools, including ABAP Test Cockpit and custom-code analysis capabilities, can help identify developments that require remediation or may be retired.

Key indicators for assessing Brownfield include:

• the volume of custom ABAP objects;
• the number of modified SAP standard objects;
• use of ECC functionality that requires changes for S/4HANA;
• the condition of interfaces and add-ons;
• how closely the current configuration reflects the actual business;
• the amount of organisational change that has occurred since the original ECC implementation.

Brownfield does not mean the organisation has to preserve everything exactly as it is. The conversion project can also be an opportunity to rationalise the chart of accounts, organisational structures, profit centres, and custom code where appropriate.

Choosing between system conversion and a new implementation

In practice, the decision can be structured around three questions:

1. How closely do the current processes match the target operating model?
2. How important is it to preserve existing data and configuration?
3. How much organisational and process change is the business prepared to undertake?

These questions help distinguish a straightforward system conversion from a transformation programme and indicate when a selective approach may be more appropriate.

Choosing between a system conversion and a new implementation

Bluefield: selective data transition

Selective Data Transition sits between Greenfield and Brownfield.

Instead of fully converting the existing system or abandoning its data completely, the organisation creates a target S/4HANA environment and selectively transfers defined information from the legacy landscape.

This can be particularly useful for organisations with multiple ECC systems, acquisitions, divestitures, or a need to change organisational structures while retaining selected historical information.

The key difference is that the project first determines which data and structures should move to the new system, and then builds the migration process around that decision.

Selective Data Transition can be relevant when:

• several ECC systems need to be consolidated;
• the organisation has undergone acquisitions or divestitures;
• legal entities or organisational structures need to change;
• some existing processes are stable while others are heavily customised;
• selected historical data needs to be retained, but the entire legacy landscape does not need to be transferred.

This approach is technically more complex than the other two and usually requires specialist expertise. It should therefore not be treated as a default middle ground. It is most appropriate when the structure of the existing landscape genuinely calls for selective transition.

SAP ECC to S/4HANA Migration Decision Framework

Use this framework as an additional reference when evaluating the most suitable migration path. The right approach depends on your current ECC landscape, business priorities, data requirements, and the level of transformation your organisation expects from the S/4HANA journey.

In simplified terms:

• if the main objective is to modernise the platform while retaining working processes, Brownfield is usually the first option to assess;
• if the main objective is to redesign processes and standardise the operating model, Greenfield should be considered;
• if the organisation needs to transform the landscape while selectively retaining data, Selective Data Transition may be appropriate.

The final decision should be based on a detailed assessment of the specific ECC landscape.

SAP S/4HANA Migration and Business Continuity

One of the biggest concerns in an SAP S/4HANA migration is business disruption. The migration strategy should therefore account for data volumes, system downtime, cutover complexity, critical business periods, and the organisation's tolerance for operational interruption.

A practical approach includes:

• Early migration rehearsals to identify data and technical issues before cutover.
• Multiple mock cutovers to validate the migration sequence and reduce go-live risk.
• Downtime planning around financial close, peak trading periods, and other critical operations.
• Data validation and reconciliation before and after the final migration.
• A structured rollback and contingency plan in case critical issues arise during cutover.
• Post-go-live hypercare to stabilise the new environment and resolve issues quickly.

We understand that reliable data is critical to a smooth SAP S/4HANA transition. The LeverX Data Management Platform helps organisations streamline and automate key migration activities, including data preparation, validation, transformation, and reconciliation. This gives project teams greater visibility into data quality, reduces manual effort, and supports more predictable migration and cutover cycles.

The objective of the migration programme is not necessarily zero downtime. A more realistic goal is to make the transition predictable, controlled, and compatible with business continuity requirements.

SAP S/4HANA Greenfield Migration for a UK Food and Beverage Manufacturer

A UK food and beverage manufacturer had been running SAP ECC for more than 15 years across 8 production sites.

The system had evolved alongside the business. What started as a relatively standard ECC implementation had accumulated years of custom development, local modifications, plant-specific processes, and workarounds.

By the time the company started planning its S/4HANA transformation, the landscape included:

• 1,200+ custom ABAP objects
• Different procurement processes across plants
• Plant-specific production planning rules
• Multiple versions of master data
• Manual workarounds around finance and supply chain processes
• Legacy interfaces that had become difficult to maintain

The company faced a strategic question: should it simply convert ECC to S/4HANA or use the migration as an opportunity to redesign the way the business operates?

A technical conversion would have been faster initially, but it would also have transferred much of the existing complexity into the new environment.

Why the Company Chose Greenfield

The assessment showed that a significant part of the existing customization was not providing unique business value anymore. Many custom processes had originally been created to address limitations that no longer existed in modern SAP.

The company therefore chose a Greenfield implementation.

Instead of asking "How do we move our ECC processes to S/4HANA?", the project asked:

"What should our future manufacturing and supply chain processes look like?"

The team mapped existing processes across all 8 sites and classified them into four categories:

• Keep because they provide genuine business value
• Replace with standard S/4HANA functionality
• Redesign to eliminate unnecessary complexity
• Retire because the process was no longer required

How the Migration Was Delivered

The company created a common S/4HANA template covering:

• Finance
• Procurement
• Inventory
• Production Planning
• Sales
• Supply Chain
• Reporting

SAP Best Practices were used as the starting point, with deviations requiring explicit business justification.

Master data was also redesigned rather than simply copied from ECC. Materials, suppliers, customers, BOMs, and production structures were standardized across the manufacturing network.

Historical data was treated selectively. Business-critical information was migrated, while obsolete historical data was archived rather than becoming part of the new operational system.

Results

• 8 manufacturing sites moved to a common S/4HANA process model
• 1,200+ legacy custom objects assessed and largely eliminated from the new core
• 35% reduction in custom development footprint
• 45% reduction in manual finance and procurement activities
• 30% faster month-end reporting
• Standardized processes across all manufacturing locations

Who Should Recognize Themselves in This Scenario?

Greenfield is particularly relevant if your organization has:

• 10+ years of ECC history
• Heavy customization
• Different processes between plants or business units
• Multiple acquisitions or legacy systems
• Significant technical debt
• Processes that employees themselves describe as "the way we've always done it"
• A strategic goal to standardize operations rather than simply upgrade technology

The key signal: if your ECC system reflects years of accumulated compromises rather than your desired future operating model, Greenfield can be more valuable than simply converting what already exists.

SAP S/4HANA Brownfield System Conversion for a UK Industrial Manufacturer

A UK industrial manufacturer operated 6 production plants on a mature SAP ECC environment.

Unlike the previous scenario, the company was relatively satisfied with its existing ERP processes.

Production planning, procurement, inventory, finance, and order management were already tightly integrated into the company's operations. Users were familiar with the system, and many processes had been optimized over years of continuous improvements.

The business therefore had a different problem:

"Why rebuild processes that already work?"

At the same time, ECC was becoming a technology constraint. The company needed to move to S/4HANA while minimizing disruption to production and preserving access to historical business data.

Why the Company Chose Brownfield

The initial assessment focused on separating technical problems from business-process problems.

The company found that most of its core processes remained fit for purpose. The major issues were instead related to:

• aging ECC technology;
• custom ABAP code;
• deprecated functionality;
• legacy interfaces;
• S/4HANA simplification requirements;
• outdated technical architecture.

A Greenfield implementation would have required the organization to redesign and retest many processes that were already working effectively.

The company therefore selected a Brownfield System Conversion.

How the Migration Was Delivered

The project began with a detailed assessment of the existing ECC environment.

More than 700 custom ABAP objects were analyzed and classified:

• Keep and remediate
• Replace with standard S/4HANA functionality
• Retire

The team also assessed SAP Simplification Items, add-ons, interfaces, finance structures, Business Partner requirements, and other technical dependencies.

The migration was then executed as a system conversion, allowing the company to retain the existing configuration and required historical transactional data while moving the underlying ERP platform to S/4HANA.

The project included:

• SAP HANA migration
• ECC-to-S/4HANA conversion
• Custom code remediation
• Business Partner conversion
• Universal Journal adoption
• Interface remediation
• SAP Fiori adoption
• Regression testing
• End-to-end business-process testing

Results

• 6 production plants migrated within one SAP S/4HANA environment
• 700+ custom ABAP objects assessed and remediated
• 100% of historical transactional data retained in the converted environment
• 40% reduction in legacy custom code
• 50% faster execution of selected reporting and MRP workloads
• Business operations maintained with minimal process disruption

Who Should Recognize Themselves in This Scenario?

Brownfield is often a strong candidate when:

• Your ECC processes already work well
• The business does not want a major process redesign
• You have significant historical transactional data
• Users are comfortable with existing processes
• Customizations are manageable and can be remediated
• The main driver is technology modernization rather than business transformation
• Production or customer-facing operations make a large process change particularly risky

The key signal: if your organization is saying "We don't want to change how we run the business; we need to modernize the platform underneath it", Brownfield may be the logical starting point.

SAP S/4HANA Selective Data Transition for a Global Engineering Group

A global engineering group had expanded through acquisitions and was running 4 separate SAP ECC systems.

Each business unit had evolved independently, creating four different ERP environments with different:

• company codes;
• charts of accounts;
• master data;
• organizational structures;
• customizations;
• reporting models;
• historical transactions.

The company wanted to move to one S/4HANA platform, but neither a traditional Brownfield nor a pure Greenfield approach solved the problem.

A Brownfield conversion would essentially mean:

4 ECC systems → 4 converted S/4HANA environments

That would preserve the fragmentation the company was trying to eliminate.

A Greenfield implementation would provide a clean target but would require rebuilding a significant amount of business functionality and finding a way to handle years of historical data.

Why the Company Chose Selective Data Transition

The company chose Selective Data Transition, sometimes referred to as a Bluefield approach, because it needed both:

Transformation freedom + selective preservation of existing business data.

The first stage was therefore not technical migration. It was deciding what should survive the transformation.

Each ECC system was analyzed at the organizational, process, master-data, and historical-data level.

The team identified:

• duplicated master data;
• obsolete company codes;
• redundant customizations;
• overlapping business processes;
• business-critical historical data;
• organizational structures that needed to be consolidated.

The target S/4HANA environment was then designed around the future operating model.

How the Migration Was Delivered

Instead of moving entire ECC databases, the project selectively migrated the information required by the new organization.

This included:

• selected historical transactions;
• business-critical master data;
• required company codes;
• relevant organizational structures;
• specific business-unit data.

At the same time, obsolete structures and redundant data were left behind.

The project also standardized the chart of accounts, harmonized master data, and rationalized custom development before the final transition.

Results

• 4 ECC systems consolidated into 1 S/4HANA environment
• 60% reduction in duplicated master data
• 3 legacy company-code structures consolidated
• 40% reduction in redundant custom developments
• Business-critical historical data retained
• Standardized processes across previously independent business units

Who Should Recognize Themselves in This Scenario?

Selective Data Transition is particularly relevant for organizations that:

• Have multiple ECC systems
• Have grown through acquisitions
• Need to consolidate ERP landscapes
• Want to redesign organizational structures
• Need to retain selected historical data
• Have too much legacy complexity for a straightforward Brownfield
• Don't want the cost and disruption of rebuilding everything from scratch

The key signal: if your question is "Which parts of our legacy landscape should actually come with us?", rather than simply "How do we convert ECC?", Selective Data Transition deserves consideration.

SAP S/4HANA Migration and Business Transformation for a UK Consumer Goods Group with RISE with SAP

A UK consumer goods group operating across 12 legal entities was facing a broader problem than an aging ERP system.

Its ECC environment had become expensive to maintain, infrastructure required increasing levels of support, and business units had adopted different processes over time.

The company wanted to:

• move away from legacy ECC;
• reduce infrastructure complexity;
• standardize business processes;
• reduce custom development;
• adopt a cloud operating model;
• create a more scalable ERP foundation.

The leadership team therefore viewed S/4HANA migration as part of a broader business transformation, rather than as a standalone technical project.

Why the Company Chose RISE with SAP and S/4HANA Cloud

The key decision was that the target state should not simply be "ECC, but newer."

The company wanted to change both the ERP platform and the way the ERP environment was operated.

The team therefore evaluated the existing landscape against SAP Best Practices and identified which processes could move to a standardized cloud model.

Processes were classified as:

• Adopt standard
• Redesign
• Replace
• Extend outside the S/4HANA core

This became the basis for the company's Clean Core strategy.

How the Transformation Was Delivered

The company adopted S/4HANA Cloud through RISE with SAP.

The program combined:

• ERP migration
• Cloud transformation
• Finance transformation
• Procurement standardization
• Supply chain modernization
• SAP Fiori
• SAP BTP integrations
• Custom code remediation
• Clean Core architecture
• Data migration

Rather than deploying everything simultaneously, the company used a phased rollout across the 12 legal entities.

A common template was developed first, tested with an initial business unit, and then refined before subsequent deployments.

Results

• 12 legal entities moved to a common S/4HANA platform
• 30% reduction in ERP infrastructure and maintenance effort
• 45% reduction in legacy customizations
• 25% faster financial reporting
• Standardized core processes across business units
• Reduced dependency on legacy infrastructure

Who Should Recognize Themselves in This Scenario?

This approach is particularly relevant if your organization is thinking:

• "We want to move to the cloud at the same time as S/4HANA."
• "Our ERP infrastructure is becoming expensive to maintain."
• "We want to reduce our SAP customization footprint."
• "We need a standardized operating model across business units."
• "We want the migration to support a broader digital transformation."
• "We don't want to build another heavily customized ERP environment."

The key signal: if S/4HANA migration is part of a larger cloud, operating-model, and ERP transformation, rather than simply a technical upgrade, a cloud transformation approach such as RISE with SAP may be the more appropriate strategic path.

How the SAP S/4HANA Migration Approach Shapes the Rest of the Programme

The four scenarios show that the migration approach cannot be selected based solely on the technical condition of ECC.

Greenfield primarily addresses the future process model. Brownfield addresses how to modernise an existing working system. Selective Data Transition addresses which parts of a complex legacy landscape genuinely need to move. RISE with SAP adds a change to the ERP operating and infrastructure model.

The organisation should therefore define not only the technical migration path, but also the desired future state of the business before implementation begins.

That decision directly affects the data scope, custom-code strategy, testing requirements, cutover plan, budget, and expected outcomes.

How a Typical S/4HANA Migration Actually Runs

Every S/4HANA project follows a different timeline. But the core stages remain broadly consistent across Greenfield, Brownfield, and hybrid transitions. What changes is the level of redesign, the volume of data involved, and the amount of system restructuring required at each stage.

The six phases below reflect how a well-run S/4HANA project progresses.

Step 1: Readiness assessment and discovery

The starting point is the SAP readiness check, a tool that analyses your existing ECC system and produces a structured report covering simplification items, custom code volume, active business functions, and add-on compatibility with S/4HANA. For UK organisations, this phase also includes reviewing localisation compatibility: UK-specific add-ons for payroll, VAT, Intrastat reporting, and HMRC-connected tools each carry their own S/4HANA compatibility status and upgrade path.

The readiness output directly informs approach selection. A system with high custom code volume and many simplification items points toward greenfield. A well-maintained system with a contained custom footprint is viable for brownfield conversion.

Step 2: Clean Core assessment and custom code strategy

SAP's clean core principle requires that customisations extend S/4HANA without modifying its standard codebase. In brownfield projects, the ABAP Test Cockpit generates a list of custom objects that will not function on S/4HANA without modification. Each object requires a decision: adapt the code, rebuild the functionality as a side-by-side extension on SAP BTP, or retire it if the underlying process is no longer active.

Moving customisations to BTP rather than rebuilding them inside S/4HANA decouples the custom logic from the SAP update cycle. Extensions running on BTP do not require retesting against every S/4HANA support package, which reduces ongoing maintenance overhead.

Step 3: Data cleansing and migration preparation

Data quality at go-live determines operational stability in the weeks that follow. Master data errors that staff worked around in ECC surface immediately in S/4HANA, where automated processes depend on clean and consistent records. The priority areas for UK businesses are typically:

• Vendor and customer master data, including VAT registration numbers verified against HMRC records
• Material master records, particularly where duplicate entries and inconsistent descriptions have accumulated
• Open items in accounts payable and receivable, which must be fully reconciled before cutover
• Chart of accounts and cost centre structures, which brownfield projects carry across but which frequently benefit from rationalisation at this stage.

Step 4: Functional configuration and process transformation

In greenfield projects, this phase covers the full configuration cycle: organisational structure, financial settings, logistics processes, and UK localisation. In brownfield projects, the focus is on resolving simplification items and migrating from Classic GL to Universal Journal.

The Universal Journal migration consolidates ECC's separate FI, CO, and reconciliation ledger tables into a single table, ACDOCA, in S/4HANA. This eliminates the periodic reconciliation steps that finance teams run in ECC and makes real-time profitability reporting available without a separate extraction process.

SAP Fiori role design also sits in this phase and should be scoped early; the mapping between ECC authorisation objects and Fiori catalogues is not automatic and requires deliberate configuration.

Step 5: Testing, including UK localisation validation

End-to-end process testing must confirm that integrated scenarios, such as purchase order to payment and payroll to general ledger posting, run correctly through the new system.

UK-specific localisation includes dedicated test cycles for MTD VAT return generation and API submission to HMRC, UK payroll including PAYE (Pay As You Earn) real-time information submissions, Intrastat and customs processes under the Windsor Framework, CHAPS, and Bacs payment file formats. User Acceptance Testing should include finance, procurement, HR and operations leads as well as the project team.

Step 6: Cutover and go-live

The cutover plan outlines the sequence and timing of each task, including system shutdown, final data extractions, execution of the migration load, post load reconciliation checks, and go-live confirmation. For customer-facing fulfilment operations for UK businesses, the go-live date should take account of order volumes, payroll cycles and VAT return deadlines.

Hypercare should run for a minimum of four weeks post go-live. The most common issues in this period are authorisation gaps, interface errors, and output determination failures, all of which are resolvable quickly with the project team still engaged.

Typical SAP S/4HANA Implementation Timeline

A fixed timeline cannot be defined without assessing the specific landscape. Duration depends on the number of systems and legal entities, custom-code volume, data quality, number of integrations, deployment model, and migration approach.

The following model should therefore be treated as a planning reference rather than a guaranteed project schedule.

The stages may overlap considerably. Larger programmes often prepare data, develop functionality, and test processes iteratively rather than strictly sequentially.

How Much Does SAP S/4HANA Migration Cost in the UK?

Once the migration approach and indicative timeline have been established, the next step is to build the budget.

Project cost is not determined by company size alone. The main factors include the number of legal entities, number of SAP systems, volume of custom code, number of integrations, data quality, historical-data requirements, and deployment model.

The figures below should therefore be treated as planning ranges rather than fixed project prices.

Estimated SAP S/4HANA Migration Project Costs

The budget should normally be split into several components, including software and subscription costs, implementation services, infrastructure or cloud costs, data migration, integrations, testing, training, change management, and post-go-live support.

This is why comparing only implementation costs can provide an incomplete view of TCO.

What Creates Risk During an SAP S/4HANA Migration? And How to Measure Success?

The long-term results of SAP S/4HANA migration programmes often depend on the following factor: how early organisations identify operational risks and define measurable implementation targets.

Most large SAP environments contain years of accumulated complexity. This includes custom ABAP developments, third-party integrations, duplicated master data, local reporting logic, and process variations between departments or subsidiaries. During migration, these dependencies become visible very quickly.

This is why experienced SAP programmes treat migration as both a technical and operational transition. The objective is not only to move ECC workloads onto a new platform. The objective is to reduce future maintenance effort, simplify reporting structures, and avoid recreating the same limitations inside S/4HANA.

The main risks usually appear before go-live

Migration delays rarely come from a single technical failure. In most cases, project timelines extend because multiple smaller issues accumulate during preparation and testing phases.

For example, undocumented custom code may interrupt integration testing. Poor-quality master data may create reconciliation problems during finance validation. Infrastructure decisions may conflict with internal security policies late in the project. None of these issues are unusual in large SAP landscapes.

The table below outlines the risks most commonly seen in UK SAP S/4HANA programmes and the approaches organisations use to reduce them.

Common SAP S/4HANA Migration Risks

How to Measure SAP S/4HANA Migration Success

Technical go-live is only one milestone in an SAP S/4HANA programme. The more important question is whether the new environment improves operational execution after deployment.

This usually becomes visible in finance operations, reporting speed, system maintenance effort, and process execution time. Well-structured migration programmes define these targets before implementation begins so that results can be measured after go-live.

The exact outcomes differ between organisations. They depend on the starting ECC landscape, the migration approach, and the level of process redesign introduced during the programme. However, several improvements appear consistently after successful S/4HANA adoption.

Typical SAP S/4HANA Operational Outcomes

Why Long-Term SAP S/4HANA Architecture Matters More Than the Go-Live Date

Some organisations measure a migration primarily by how quickly they reach S/4HANA. In practice, the long-term maintainability of the new environment can be more important than a few weeks of difference in the project schedule.

If the new system still depends on large volumes of custom code, fragmented integrations, and inconsistent data, some of the legacy complexity has simply been moved to a new platform.

A migration programme should therefore be treated as an opportunity to simplify the ERP landscape.

This can include:

• retiring unnecessary custom code;
• standardising processes;
• improving master-data governance;
• updating integration architecture;
• moving selected extensions outside the ERP core;
• archiving data that is no longer required in the operational system.

This approach can help organisations gain more from the migration than simply replacing the underlying technology.

Why the Partner You Choose Matters as Much as the Path You Take

Executing an S/4HANA migration requires more than technical capability. It requires a team that understands the regulatory environment your system operates in, has delivered migrations of comparable complexity, and remains available after go-live when production issues surface.

For UK enterprises, that combination is specific enough to be worth examining carefully before selecting an implementation partner.

LeverX is an SAP-certified partner with direct delivery experience across Greenfield, Brownfield, and selective data transition projects for UK-based organisations.

We support SAP S/4HANA migration programmes with a focus on system stability and controlled transition. The work starts with analysis of ECC architecture, custom code, integrations, and UK-specific reporting requirements. This defines the migration scope before implementation begins.

A key focus is reducing unnecessary technical complexity. Many ECC systems contain custom developments that duplicate standard SAP functionality. LeverX applies a Clean Core approach and evaluates what should remain inside SAP and what should move to SAP Business Technology Platform (SAP BTP). This reduces long-term maintenance effort and simplifies future updates.

Post go-live, LeverX's hypercare support operates within UK business hours, with defined response times during the first weeks of production. Finance teams running their first month-end close on S/4HANA and procurement teams processing live purchase orders have access to the people who configured the system during the hours they need them.

Ready to assess your ECC landscape? Book a free consultation with LeverX's UK SAP team to review your current system, identify the right migration approach, and establish a clear picture of scope, timeline, and cost.

Before You Start: A Pre-Migration Readiness Checklist

Use this checklist to assess whether your organisation is technically and operationally ready for an SAP S/4HANA migration. It focuses on system readiness, data quality, compliance, and financial alignment.

1. SAP technical readiness completed

Has SAP Readiness Check 2.0 been executed?

It should identify simplification items, add-on compatibility issues, and required Fiori applications before any migration work starts.

2. Custom code impact assessed

Has legacy ABAP custom code been analysed using SAP tools such as ABAP Test Cockpit (ATC)?

The outcome should clearly show which developments can be retired, which must be adapted, and which should move to SAP Business Technology Platform (SAP BTP).

3. Business case formally approved

Has the CFO approved the migration business case?

The model should include total cost of ownership, infrastructure shift from CAPEX to OPEX where relevant, and expected long-term operational cost impact for the UK entity.

4. Data residency and UK GDPR confirmed

Is the hosting model aligned with UK GDPR requirements?

This includes validation of data storage location, typically within UK-based hyperscaler regions such as AWS London or Azure UK South, depending on the chosen infrastructure.

5. UK compliance requirements validated

Is there a defined plan for UK-specific regulatory processes?

This includes HMRC Making Tax Digital requirements, Construction Industry Scheme (CIS), and payroll-related integrations where applicable.

6. Data quality and archiving strategy defined

Has master data been reviewed for duplication and inconsistencies?

Is there an agreed approach for archiving obsolete transactional data to reduce system load and simplify the migration to SAP HANA?

Final Note

SAP ECC to S/4HANA migration is not a single technical scenario that can be applied to every organisation.

If existing processes work well and the primary objective is technology modernisation, Brownfield may be the most appropriate option. If the organisation wants to redesign processes and establish a new operating model, Greenfield should be considered. For complex landscapes with multiple systems or selective data-retention requirements, Selective Data Transition may be necessary. RISE with SAP can be considered where the migration forms part of a broader cloud transformation strategy.

Whatever the approach, the outcome depends heavily on preparation: data quality, custom-code assessment, integration architecture, testing, cutover planning, and business readiness.

The earlier these issues become part of the programme, the less likely it is that critical dependencies will be discovered during late-stage testing or cutover.

Frequently Asked Questions

When does SAP ECC mainstream support end?

Mainstream maintenance for SAP ECC 6.0 formally ends in January 2027. Extended maintenance options are available through 2030 at a price premium, but they provide break-fix support only without legal compliance updates or new functional innovations.

How long does an SAP ECC to S/4HANA migration take?

Small to mid-sized implementations in the UK typically take 6 to 12 months, while complex enterprise transformations with extensive custom code, multiple legal entities, or international supply chains range from 12 to 24+ months.

What is the difference between Greenfield and Brownfield migration?

Greenfield builds a brand-new S/4HANA environment from scratch, adopting SAP Best Practices and leaving legacy custom code behind. Brownfield converts your existing ECC system directly, retaining all historical data, configurations, and custom code while upgrading the underlying database engine to SAP HANA.

Does SAP S/4HANA support HMRC Making Tax Digital (MTD) and UK VAT compliance?

Yes. SAP S/4HANA provides native UK localizations, supporting automated VAT calculation, digital audit trail tracking, and direct API integration with HMRC systems for Making Tax Digital (MTD) submissions.

Can SAP ECC be migrated directly to the cloud?

Yes. Organisations can migrate to SAP S/4HANA Cloud through the RISE with SAP program, combining cloud infrastructure hosting (via UK hyperscalers like AWS London or Azure UK South), managed services, and software licensing.

Should all historical ECC data be migrated to SAP S/4HANA?

No. Ingesting decades of historical transactions increases database costs and slows implementation. We recommend migrating active master data, open transactions, and opening balances, while archiving historical data in a compliant, searchable data store.

How does a Clean Core strategy reduce long-term TCO?

A Clean Core strategy keeps the standard S/4HANA codebase unmodified by building custom logic as side-by-side extensions on SAP BTP. This ensures future SAP software updates can be applied smoothly without breaking custom code or requiring extensive re-testing.

What is the Universal Journal in SAP S/4HANA?

The Universal Journal (ACDOCA) is a consolidated financial database table in SAP S/4HANA that combines Financial Accounting (FI) and Controlling (CO) line items into a single, unified source of financial truth, eliminating the need for periodic reconciliations.

Conclusion

SAP ECC to S/4HANA migration is an opportunity not only to replace an ageing ERP platform, but also to reconsider the architecture, data, custom developments, and business processes the organisation will rely on in the future.

The right approach depends on the current state of the system and the objectives of the programme. Brownfield suits organisations that want to retain established processes while modernising the technology platform. Greenfield allows organisations to build a new operating model. Selective Data Transition provides a way to selectively migrate data while transforming a complex legacy landscape. RISE with SAP can be considered as part of a broader cloud transformation strategy.

Regardless of the chosen scenario, the outcome depends on preparation: data quality, custom-code assessment, integration architecture, testing, cutover planning, and business readiness.

For UK organisations, this also means considering relevant regulatory, data-protection, and operational requirements throughout the programme.

Ultimately, a successful migration is not simply the launch of S/4HANA. It is the creation of an ERP environment that the organisation can maintain, develop, and adapt as the business changes.

Disclaimer: The information in this article is provided for general informational purposes only. SAP S/4HANA migration approaches, implementation timelines, costs, and project outcomes vary depending on the existing ERP landscape, business processes, data quality, custom code, integrations, deployment model, and project scope. Specific SAP capabilities and UK regulatory scenarios may also depend on the relevant product version, localisation, configuration, and connected systems. A detailed assessment of the existing environment is recommended before defining a migration strategy, budget, or implementation plan.