6 steps to a safe and efficient SAP migration for businesses

What is SAP system migration?

SAP system migration is the process of moving an SAP ERP system from one version, infrastructure or operating model to another platform. The most common scenario today is moving from SAP ECC, SAP ERP or SAP S/4HANA On-premise to SAP S/4HANA Cloud, running on SAP's own cloud infrastructure (SAP S/4HANA Public Cloud) or on a hyperscaler partner's infrastructure (SAP S/4HANA Private Cloud). The process involves more than moving data. It also includes reassessing business processes, custom code, authorizations and the integration architecture so that they fit the new technology platform.

Many large enterprises are planning migrations because the capability gap between system architectures keeps widening. According to KPMG's analysis, SAP is redefining industry best practice through Cloud ERP and the Joule AI assistant. As a result, companies that are slow to move risk losing their competitive advantage to rivals that have already modernized their systems.

Migration differs from a regular upgrade or patch in the scale of change. An upgrade typically keeps the architecture and infrastructure unchanged and only updates the software version. Migration of an SAP system, on the other hand, especially from on-premise to cloud, usually changes the entire operating infrastructure, the licensing model and the way the business manages system maintenance going forward.

What are Greenfield, Brownfield and Bluefield?

These are the three most common SAP system migration approaches, named after a metaphor from the construction industry. Greenfield is undeveloped land, corresponding to building an entirely new system; Brownfield is land with existing structures, suggesting renovation on top of the current system; and Bluefield is a hybrid approach, also referred to by SAP as Selective Data Transition.

Greenfield

Greenfield is an approach in which the system is implemented from scratch, without carrying over the configuration or historical data of the legacy system. The business redesigns all of its processes according to SAP best practice. This suits cases where the current system has accumulated too many overlapping customizations over the years, or where the company wants to use the migration as an opportunity to restructure its operations. The drawback of this approach is a longer implementation time and the need for careful change management, because users have to get used to entirely new processes.

Brownfield

Brownfield is a technical conversion (system conversion) performed on the system that is currently in operation, retaining most of the configuration, data and custom code. It is the fastest and least disruptive path, but it also has certain limitations. Brownfield carries over all of the legacy system's technical debt, including old code that nobody clearly remembers the purpose of. If the system is not thoroughly reviewed before conversion, the business risks modernizing its infrastructure while keeping the same process limitations.

Whichever approach is chosen, SAP recommends following the "clean core" principle: keep direct modifications to SAP's core code to a minimum and instead extend functionality through separate layers on SAP Business Technology Platform. The cleaner the core, the easier it is for the business to adopt new releases, integrate AI capabilities and reduce long-term maintenance costs. This is also why Brownfield still needs to be accompanied by a review that removes unnecessary customizations, rather than carrying all of the legacy code over to the new system as-is.

Bluefield

Bluefield combines both approaches above: it retains the configurations and customizations that are working well using the Brownfield approach, while redesigning from scratch the business areas that need optimization using the Greenfield approach. This method requires accurate assessment and segmentation of the system right from the start of the project, so it usually calls for an implementation partner with deep experience in both approaches.

Comparison of the three migration approaches

According to the 2025 ASUG survey, 44% of enterprises chose Brownfield, 29% chose Bluefield and 26% chose Greenfield. These proportions show that most enterprises prioritize reducing risk and implementation time over a full redesign.

6 steps enterprises need to prepare before migrating their SAP system

1. Assess the current system and the reasons for migration

Enterprises need to clearly identify which version their current system is running. The degree of customization, the data volume and the number of existing integrations will determine the complexity of the project.

There is one point that is often overlooked at this step: many enterprises only inventory the custom code directly tied to core processes, while custom reports and small modifications made by internal users over the years are often not fully documented. These issues are only discovered once the project is underway, causing unplanned costs and delays.

This step is also the time to clarify the motivation for migration. It could be expanding AI capabilities, improving data integration, or restructuring operating processes.

2. Define the criteria for choosing the right migration approach

After understanding the definitions of, and differences between, Greenfield, Brownfield and Bluefield, enterprises need to check them against a set of specific criteria to choose the right option, rather than following market trends.

The most important criteria include: satisfaction with the processes currently in operation, the budget and implementation timeline available, the readiness of the organization and end users for change, and the level of risk the business can accept during the transition. Enterprises that are satisfied with their current processes and prioritize speed usually lean toward Brownfield. Enterprises that want to use the opportunity to standardize comprehensively, and have a larger budget and a longer timeline, are usually better suited to Greenfield.

Based on Citek's implementation experience as an SAP Platinum Partner, FDI enterprises and domestic corporations typically struggle most at the stage of defining the scope of customizations to retain. Assessing the current state thoroughly before choosing a migration approach significantly shortens the actual implementation time compared with the original plan.

3. Assess security and governance risks before a lift-and-shift to the cloud

KPMG warns that on-premise SAP systems are often operated separately from the enterprise's core cybersecurity team. Vulnerabilities in custom code can therefore remain undetected for years.

When migrating to the cloud, the shared responsibilities among the enterprise, the cloud provider and the hyperscaler (such as AWS, Azure and Google Cloud) need to be clarified from the very beginning. The enterprise retains control and holds primary responsibility at the application layer.

There is one point to note at this stage. The authorization mechanism in SAP Fiori and the OData data exchange protocol differ significantly from authorization through the traditional SAP GUI. Roles set up for the legacy system may not map accurately to the new Fiori apps, resulting in excessive or insufficient access rights if everything is not re-reviewed during the migration.

4. Build a business case based on quantitative data

Beyond operational requirements, migration needs to be evaluated on concrete business value. Common value categories include operational optimization, better-quality insights to support decision-making, and faster innovation through AI.

Enterprises should ask the implementation partner to quantify this value in their actual business context. Reference figures from vendors should only serve as a starting point and not as a substitute for the enterprise's own assessment.

5. Plan data, integration and user training

A migration project can succeed technically and still fail if users do not actually use the new system. The data and integration plan needs to be accompanied by a training and change management program, starting in the early phase of the project rather than waiting until the system goes live (go-live).

In terms of tools, SAP provides SAP Migration Cockpit (included with the S/4HANA license, suitable for medium data volumes and predefined migration object structures) and SAP Data Services for cases with large data volumes that require more complex processing and transformation. Enterprises with integrations to many third-party systems can also consider adding iPaaS (integration platform as a service) platforms to keep data synchronized throughout the transition.

One area that is often cut back under schedule pressure: a detailed cutover plan, testing in a test environment (sandbox) separate from the production system, and running the legacy and new systems side by side (parallel run) for at least one full business cycle before the legacy system is shut down for good. Enterprises should also prepare a rollback plan to restore the system to its previous state if a serious incident occurs during the cutover period, rather than reacting passively once the incident has already happened.

6. Select an implementation partner and set up a dedicated governance and security workstream

KPMG recommends allocating roughly 5 to 10% of the project budget to an independent governance and security workstream. This is an item that is often underestimated during initial planning.

For a migration project specifically, enterprises should check four additional points beyond the usual criteria for selecting an SAP partner:

• The partner has hands-on experience with migration projects, not only with brand-new implementations.

• The partner can advise objectively on all three approaches (Greenfield, Brownfield and Bluefield), rather than favoring a single direction to shorten the sales cycle.

• The team includes security, risk management and compliance (GRC) specialists who are separate from the purely technical team.

• The partner can support the peak-demand period right after go-live (hypercare), rather than stopping at the project handover milestone.

For a fuller checklist when evaluating and negotiating with SAP partners, enterprises can read the article "What is a SAP Partner? Partner tiers, competencies, and a checklist for choosing the right implementation partner".

RISE with SAP vs. GROW with SAP: which package should you choose?

SAP's transformation programs are often referred to by several different names, which can easily confuse enterprises that are just starting to research them.

SAP Cloud ERP is the umbrella term for SAP's entire family of cloud-based ERP products, comprising two editions: Public Edition (a multi-tenant environment in which many customers share the same infrastructure) and Private Edition (a single-tenant environment with infrastructure dedicated to each customer). RISE with SAP and GROW with SAP are both built on these two editions.

GROW with SAP is an implementation package for enterprises that are new to SAP or are mid-sized, running on SAP S/4HANA Cloud Public Edition. The package comes with pre-standardized processes based on industry best practice, which shortens implementation time but limits deep customization. Learn more: Ebook GROW with SAP: Accelerate sustainable growth with flexible Cloud ERP solution

RISE with SAP is a package designed for enterprises with more complex operating systems. RISE allows a choice between Public and Private Edition, and includes technical migration services, infrastructure from hyperscaler providers and access to SAP Business Technology Platform.

For enterprises that have run SAP for many years and have a large volume of customizations, RISE with SAP is usually a better fit than GROW with SAP. Conversely, GROW with SAP suits enterprises that have never used SAP, or that want to implement a new ERP with standardized processes from the start, without the burden of a legacy system.

The role of SAP Business AI (Joule) in SAP system migration

SAP Joule is SAP's artificial intelligence platform, which allows users to interact with the system in natural language instead of through the traditional interface. Evolving from an initial virtual assistant (copilot), Joule has become an AI platform capable of carrying out tasks autonomously (agentic AI), with thousands of skills that support the automation of common business processes.

This is one of the concrete reasons why migration is not merely an infrastructure question: SAP Joule is currently available only on SAP S/4HANA Cloud (both Public and Private Edition) and is not supported on on-premise systems or SAP ECC. In other words, enterprises still running on-premise cannot access this AI capability until they have completed their migration to the cloud, even if they have already updated to the latest S/4HANA release.

Here is an important insight that is rarely mentioned when planning a migration: Joule does not replace SAP's authorization model. Every action Joule performs runs on behalf of the logged-in user and remains subject to all the roles and authorization objects set up in the system. If authorizations are not reviewed and redesigned properly during the migration, the new AI capabilities will be limited or will not work as expected.

Enterprises should therefore treat AI readiness as part of redesigning the operating model within the migration project itself, rather than as a feature switched on after go-live without clearly defined use cases, an accountable owner or data discipline.

SAP system migration costs: the factors that influence them

The cost of an SAP system migration depends on many factors, not just license fees. According to international SAP implementation consultancies, the most influential factors include:

• The amount of custom code that needs to be reviewed. This is often the factor that causes two companies of the same size to have significantly different migration costs.

• The quality and volume of data that needs to be cleansed and standardized before the conversion.

• The number and complexity of integration points with third-party systems, including EDI (electronic data interchange between systems), middleware (the intermediary layer that connects systems) and APIs (application programming interfaces).

• Implementation consulting fees, which usually account for the largest share of the total budget and cover discovery workshops, readiness assessment, architecture design, configuration, testing and go-live support.

• Infrastructure, the system downtime allowed during the transition period, and user training costs.

The migration approach also has a direct impact on cost. Brownfield typically has lower cost and a shorter implementation time than Greenfield, because it retains most of the existing configuration instead of rebuilding from scratch.

Because actual costs depend heavily on each enterprise's own context and on the implementation market, the overall budget should be built together with the implementation partner based on a specific assessment of the current state, rather than applying international reference figures as-is.

Common mistakes to avoid when migrating an SAP system

• Moving legacy customizations to the cloud as-is without re-evaluating whether they are still needed.

• Overlooking the security and governance workstream as a separate line item in the budget.

• Underestimating the training and change management needs of end users.

• Activating AI features such as Joule right after go-live without reviewing authorizations and defining specific use cases.

• Incomplete user acceptance testing (UAT) that misses business processes which are rarely used but still critical at year-end or quarter-end.

• Making last-minute configuration changes right before go-live without retesting all of the related impacts.

• Mapping master data incorrectly, such as vendor lists, customers or general ledger accounts, leading to reporting discrepancies after go-live.
• Starting to plan too late, which makes it hard to find suitable implementation consulting resources when market demand is high.

Frequently asked questions about SAP system migration

When should an enterprise start migrating its SAP system?

Enterprises should start assessing as soon as they notice that their current system limits scalability, integration or AI adoption. Starting early gives them enough time to assess the current state thoroughly and to be more proactive in finding a suitable implementation partner.

Should we choose Greenfield, Brownfield or Bluefield?

The choice depends on satisfaction with current processes, budget, timeline and the level of risk the enterprise can accept. Enterprises that want to keep the processes that already work well and shorten the timeline are suited to Brownfield. Enterprises that want to standardize comprehensively are suited to Greenfield, while Bluefield is a balanced option when only some processes need to be re-optimized.

How do RISE with SAP and GROW with SAP differ?

GROW with SAP suits enterprises that are new to SAP or mid-sized, with fast implementation on SAP S/4HANA Cloud Public Edition and pre-standardized processes. RISE with SAP suits large enterprises migrating from on-premise systems, allowing a choice between Public and Private Edition along with fuller technical migration services.

How long does an SAP system migration usually take?

Typical implementation time ranges from 12 to 24 months, depending on the scale and complexity of the system. Enterprises that start planning late risk difficulty finding suitable consulting resources, as market demand continues to grow.

How much does an SAP system migration cost?

Cost depends on the degree of customization, the data volume, the number of integration points and the migration approach chosen. Brownfield typically costs less than Greenfield. Enterprises should ask the implementation partner to build the budget based on a specific assessment of the current state rather than applying general reference figures.

How much budget should be allocated to security and governance in a migration project?

According to KPMG's recommendation, the security and governance workstream should account for roughly 5 to 10% of the total migration project budget. This is an item that is often underestimated during initial planning.