SAP S/4HANA migration cost: Key drivers you need to understand

SAP S/4HANA migration cost is not limited to software licensing. The actual cost comes from implementation effort, custom code, data migration, testing, downtime, and legacy system management. Here is an in-depth insight into the main cost drivers and how better data management can reduce the migration effort.

Introduction

Many organisations begin their SAP S/4HANA migration planning with one major question: how much will it cost? At first, the answer may appear to revolve around licensing, infrastructure, implementation partners, and project timelines. These are certainly important. However, the real cost of an S/4HANA migration usually goes much deeper.

The cost is shaped by the current SAP ECC landscape. Years of custom code, unused reports, inactive company codes, old transactional data, large tables, outdated interfaces, and unclear data ownership can all increase migration effort. In many cases, the migration project exposes complexity that has built up over several years.

This is why the S/4HANA migration efforts cannot be understood only as a software or technical conversion cost. It is also about data, business processes, compliance, and digital transformation.

The more complexity an organisation carries into the project, the more time and effort it takes to prepare, convert, test, and stabilise the new environment. A large database increases HANA memory needs. Custom code increases remediation effort. Poorly managed data increases testing and reconciliation. Legacy systems increase post-migration costs if they are not considered as part of the picture from the very beginning.

A practical migration plan, therefore, starts with one simple principle: reduce unnecessary complexity before it reaches SAP S/4HANA.

SAP S/4HANA migration cost is not just licensing

Licensing is usually the most visible cost in an S/4HANA migration. It is easy to identify, budget for, and discuss internally. However, it is only one part of the total cost.

The full cost includes the implementation project, technical conversion, consulting support, data preparation, custom code remediation, process redesign, testing, training, downtime planning, infrastructure, and post-go-live support. In addition, most organisations must continue operating SAP ECC legacy systems, test systems, sandbox environments, and legacy platforms during the transition.

Overall, this means the final budget can be much higher than expected if the project is planned too narrowly.

For example, a company may plan for the technical conversion but underestimate the impact of historical data. If old transactional data, obsolete master data, and inactive organisational units are carried forward, the database becomes larger than necessary. This can increase HANA memory requirements, backup effort, migration runtime, and ongoing operational expenditure.

Similarly, if custom code is not assessed early, teams may discover late in the project that key reports, integrations, or enhancements need to be adapted for S/4HANA. This can delay testing and create additional consulting effort.

The migration cost is therefore not only about moving to a new system. It is about preparing the old system well enough so that the new system does not inherit unnecessary costs.

Implementation and consulting fees

Implementation and consulting fees are often one of the largest parts of an S/4HANA migration budget. These fees cover functional workshops, technical conversion, project management, system configuration, data migration, testing, change management, and go-live support. The more complex the source system, the more consulting effort is required.

The migration approach also affects cost.

A brownfield migration, or system conversion, is often seen as the fastest route because it converts the existing ECC system into S/4HANA. However, it can also carry existing complexity into the new system if data, custom code, and processes are not reviewed before the project.

A greenfield migration gives organisations the chance to start fresh, but it usually requires more design, testing, and change management because the system is rebuilt from the ground up.

Selective Data Transition sits between these two approaches. It allows organisations to keep selected history, leave unnecessary data behind, and make targeted changes during migration. However, it also requires careful planning and specialist expertise.

This is why choosing the migration path too early can be risky. A data-led assessment before the project helps determine whether the business needs speed, transformation, data reduction, historical access, or a combination of these outcomes.

Custom code remediation

Most long-running SAP ECC environments contain custom code.

This may include Z reports, enhancements, workflows, interfaces, forms, custom tables, and bespoke business logic. Some of this custom code may still be critical. Some may be outdated. Some may no longer be used at all.

During S/4HANA migration, custom code must be assessed to determine whether it is compatible with the new environment. Code that depends on old data structures, obsolete transactions, or changed business processes may need to be adapted, replaced, or retired.

This remediation effort can become expensive for several reasons.

First, the organisation must identify what custom code exists. Second, it must determine which objects are still used. Third, technical teams must assess the impact of S/4HANA simplification items. Fourth, any changed or redeveloped code must be tested.

If this work starts late, it can delay the migration timeline.

Custom tables also add complexity. They may contain historical data, business-specific fields, or integrations with external systems. If the organisation does not understand which custom data is useful, redundant, or legally required, the migration scope becomes harder to control.

This is where early data discovery becomes important. Before the migration begins, organisations should assess not only standard SAP tables but also custom tables and custom developments. This helps reduce technical debt and prevents unnecessary objects from being carried forward.

Data migration complexity

Data is one of the biggest cost drivers in any S/4HANA migration.

Every organisation has to decide what data should move into the new system, what should be archived, what should be deleted, and what should remain accessible outside the operational S/4HANA environment.

The difficulty is that not all data has the same value.

Some data is needed for daily operations. Some is required for reporting. Some must be retained for legal, tax, or audit purposes. Some is no longer useful but still consumes database space. Some may need to be deleted to comply with data privacy requirements.

Without a clear data volume management strategy, companies may move too much data into S/4HANA. This increases database size, project effort, testing scope, and HANA memory needs.

TJC Group’s and Xmateria’s migration approach recommends looking at data through practical lenses: which processes are moving, how much historical data is needed, which organisational units are active, and which custom data should be carried forward. This helps organisations decide what is truly necessary for the new system. Watch the replay of the webinar “How to select the right path to S/4HANA for your business to learn more about Data Management for S/4HANA migration.

For example, a company may have many company codes in SAP ECC, but only some may still be active. Inactive company codes can become strong candidates for archiving instead of being migrated into the operational S/4HANA system.

This is why SAP data archiving is not just a housekeeping exercise. It is a migration cost-control measure.

Dual SAP ECC and SAP S/4HANA operations during transition

During migration, organisations often need to operate multiple environments at the same time.

The existing ECC system continues to support the business. The future S/4HANA environment is being built, tested, or converted. Sandbox, development, quality, and training systems may also be required. In some projects, legacy applications and satellite systems must remain available until the migration is complete.

This dual-operation period increases cost.

There may be additional infrastructure requirements, support costs, administration effort, user access management, data synchronisation, and security responsibilities. Business teams may also need to support migration testing while continuing their normal operational roles.

The cost becomes even higher if legacy systems remain live after S/4HANA go-live, only because historical data is still needed.

Keeping old systems running for occasional access can create ongoing licence, infrastructure, maintenance, security, and compliance costs. This is why system decommissioning should be planned early, not treated as a separate clean-up activity after migration. TJC Group explored this topic in detail through its ELSA webinar series on S/4HANA migration and system decommissioning, which covers migration decisions, data preparation, HANA cost control, compliance, long-term access, and post-go-live decommissioning use cases.

A well-planned migration considers both the data moving into S/4HANA and the data left behind.

Infrastructure costs

Infrastructure costs can account for a significant share of SAP S/4HANA migration spend, often depending on the selected licensing model, deployment architecture, data volume, and long-term system growth expectations.

For many organisations, the infrastructure decision is not limited to choosing between cloud and on-premises hosting. It also involves deciding whether to use a hyperscaler environment such as AWS, Microsoft Azure, or Google Cloud, an SAP-managed private cloud, or another architecture aligned with the organisation’s security, compliance, performance, and scalability requirements.

Each option comes with its own cost implications. A fully managed cloud environment may reduce some internal infrastructure responsibilities, but it can still introduce costs related to compute, storage, security, network configuration, monitoring, and ongoing administration. Similarly, SAP-managed private cloud environments can simplify parts of the operating model, but the required system size still depends heavily on the volume of data being migrated and retained.

This is where data becomes a direct infrastructure cost driver. SAP S/4HANA runs on the in-memory SAP HANA database, which means that larger data volumes can increase memory and storage requirements. If organisations migrate unnecessary historical or inactive data into S/4HANA, they may start their new environment with a larger infrastructure footprint than required.

SAP data archiving helps reduce this burden by lowering the active data footprint before migration. By archiving data that does not need to remain in the live database, organisations can reduce the amount of data that must be migrated, stored, backed up, and managed in the new S/4HANA environment. This can help right-size HANA memory requirements, reduce infrastructure pressure, and keep HANA database growth under control after go-live.

Training and business disruption

S/4HANA migration affects people as much as systems.

Users may need to learn new processes, interfaces, reporting structures, and approval flows. Teams may need to adapt to Fiori applications, new roles, changed master data structures, or redesigned workflows.

Training takes time. It also creates temporary productivity loss as users move from familiar ECC processes to the new S/4HANA environment.

Business disruption can also occur during testing. Key users may need to participate in workshops, validate migrated data, run test scripts, review process changes, and support issue resolution. These activities are essential, but they pull business teams away from their regular responsibilities.

This cost is often underestimated because it does not always appear as a simple line item in the project budget. However, it affects the business directly.

A cleaner migration scope can help reduce disruption. If the system carries less unnecessary data and fewer redundant processes, testing and training can focus on what the business actually needs after go-live.

Downtime and cutover risk

Downtime is another major cost driver.

During the final migration and cutover phase, systems may be unavailable or restricted. For global organisations, even a short disruption can affect order processing, finance operations, logistics, reporting, or customer service.

The size and complexity of the database influence this risk. Larger databases can increase conversion runtime, reconciliation effort, and technical processing time. More custom code and more interfaces can also increase the number of dependencies that must be checked before go-live.

This is why reducing data volume before migration is valuable.

Archiving unnecessary data before S/4HANA migration can reduce the amount of data that needs to be processed during conversion. This may help reduce runtime, support a shorter downtime window, and improve predictability during cutover.

It also reduces the burden on testing and validation teams. Instead of reconciling large volumes of old data that may no longer be operationally useful, teams can focus on the data that matters most to current business activity.

Downtime cannot be removed completely, but it can be better controlled when the data footprint is smaller and better understood.

Post-migration legacy system costs

Migration cost does not end at go-live.

After S/4HANA is live, organisations often face a new question: what happens to the old ECC system and other legacy applications?

If historical data remains in those systems, they may need to stay available for legal, tax, audit, or business reasons. However, keeping them operational can be expensive. Old systems still require infrastructure, licences, security monitoring, access control, support, and technical maintenance. They can also create compliance exposure if outdated platforms are no longer properly governed.

This is why legacy system decommissioning should be part of the migration plan from the beginning. Organisations need to decide which data moves into S/4HANA, which data is archived, and how historical data will be accessed after the old system is decommissioned.

With the right approach, companies can preserve access to historical information without keeping the full legacy system running indefinitely.

How does better data management reduce migration cost?

Better data management reduces S/4HANA migration cost by reducing avoidable work.

If unnecessary data is archived or deleted before migration, the organisation has less data to assess, convert, transfer, test, reconcile, back up, and operate after go-live. This can reduce migration complexity and help control HANA memory requirements.

A structured data management approach should include:

• Early data discovery
• Identification of high-volume tables and archiving objects
• Review of active and inactive organisational units
• Assessment of custom tables and technical debt
• Archiving of completed or rarely accessed transactional data
• Deletion of personal data where required under ILM rules
• Planning for legacy system decommissioning
• Controlled access to historical data after migration

This work should start before the migration approach is finalised. Otherwise, organisations may choose a route without fully understanding the data complexity sitting underneath.

HANA memory needs are especially important because S/4HANA runs on a premium database environment. A larger database can push organisations towards a higher memory tier, increasing long-term cost. Reducing data volume before migration helps right-size the future environment and control future growth.

How TJC Group can support SAP data archiving before migration

TJC Group helps organisations reduce migration complexity through data volume management, SAP data archiving, data deletion, legacy system decommissioning, and fiscal compliance support across the migration lifecycle.

The process can start before migration with a data volume management assessment. This helps identify database size, table growth, archiving objects, and potential savings before the project begins. It also gives the organisation a clearer view of which data should move to SAP S/4HANA, which data can be archived, and which data may need to be deleted for compliance.

TJC Group also provides SAP data archiving services for SAP ECC and S/4HANA environments. Archiving before migration helps reduce the amount of data that needs to be moved and lowers the operational burden after go-live. For organisations that need automation, the Archiving Sessions Cockpit can automate data archiving and deletion processes. This is particularly useful for complex SAP landscapes where manual archiving is time-consuming and difficult to scale.

However, support should not stop once the migration begins. During the transition from SAP ECC to SAP S/4HANA, organisations also need to plan how historical data, archived data, and fiscal reporting obligations will be managed across both systems.

This is especially important because SAP ECC decommissioning should ideally be planned alongside the migration project, not treated as a separate activity after go-live. If the legacy ECC system remains active only because historical data is still required, the organisation may continue paying for infrastructure, licences, maintenance, security, and compliance management. A better approach is to plan decommissioning early while ensuring that historical information remains accessible for legal, tax, audit, and business purposes.

For historical information that must remain accessible after migration, TJC Group’s Enterprise Legacy System Application supports system decommissioning while preserving controlled access to legacy SAP and non-SAP data. This helps organisations reduce the cost of maintaining old systems after S/4HANA go-live, while still ensuring that users can access the information they need.

TJC Group can also support organisations with SAP data archiving in the new S/4HANA environment. Once the migration is complete, data growth does not stop. Without ongoing archiving and housekeeping, the new HANA database can continue to grow, increasing memory requirements and long-term operating costs. A post-migration archiving strategy helps keep the S/4HANA system lean, efficient, and easier to manage.

There is also a compliance aspect tied to the migration from one system to another. Organisations must continue meeting legal and fiscal requirements, even when data is split between SAP ECC and SAP S/4HANA during the transition. This may include requirements linked to DART, SAF-T, fiscal archiving, and FEC reporting.

For example, French companies are required to generate the FEC report each year. If the migration takes place during a financial year, part of the data may sit in SAP ECC and the remaining data may sit in SAP S/4HANA. In such cases, companies must ensure that the report can still be generated correctly and that the underlying data remains complete, accessible, and compliant. TJC Group has also published a dedicated article on best practices to generate the FEC file when migrating to SAP S/4HANA, which explains this challenge in more detail.

TJC Group can help organisations manage this continuity by supporting data access, fiscal extraction, archiving, and reporting requirements during and after the migration. This reduces the risk of compliance gaps while helping the organisation move to S/4HANA with a cleaner, more controlled data landscape.

Companies planning a migration can also use the SAP archiving calculator to estimate potential savings from reducing data volume before the project begins.

Conclusion

SAP S/4HANA migration costs so much because the project is rarely just a technical upgrade.

It brings together licensing, implementation, consulting, custom code, data migration, testing, downtime, training, business disruption, and legacy system management. The more complexity an organisation carries in its ECC landscape, the more expensive the migration can become.

Data is one of the most important parts of this cost equation.

A large, unmanaged database increases HANA memory needs, migration runtime, testing effort, backup requirements, and post-go-live operating costs. It can also make cutover more difficult and increase the burden on business users.

SAP data archiving helps reduce this pressure before migration begins. By archiving unnecessary data, deleting what should no longer be retained, and planning legacy data access early, organisations can move to S/4HANA with a cleaner and more manageable landscape.

The goal is not simply to reduce data. The goal is to move the right data, retain the right history, and avoid paying to migrate and operate information that no longer belongs in the active system.

TJC Group’s SAP data archiving services before migration to reduce the amount of data that needs to be moved. TJC Group can also help automate archiving through the Archiving Sessions Cockpit and estimate potential savings through a data volume management assessment.