White Paper: Moving to SAP S/4HANA Cloud Without Losing Control

Executive Summary

Moving to SAP S/4HANA Cloud is rarely a straightforward technology upgrade. It changes how an organization manages finance, procurement, manufacturing, supply chain, sales, assets, reporting, and enterprise data.

The business case may be compelling. Companies want a modern ERP foundation, standardized processes, better information, simpler integration, greater automation, and a platform that can support future growth. However, the migration itself introduces cost, operational disruption, technical uncertainty, and difficult decisions about what should be carried forward.

Much of the risk comes from the existing environment.

Years of local configuration, duplicate data, unused reports, aging interfaces, undocumented processes, and custom programs may have become embedded in daily operations. Some are essential. Others continue to exist because no one wants to take responsibility for removing them.

A successful SAP S/4HANA Cloud migration should begin with one principle:

Do not move complexity simply because it already exists.

The migration program should determine which business capabilities must be protected, which processes should be redesigned, which data has continuing value, and which custom developments can be retired.

SAP provides tools and methodologies that can support this work. SAP Readiness Check can analyze an existing SAP environment and identify relevant simplification items and other areas requiring attention. SAP Activate provides implementation roadmaps and project activities, while SAP Cloud ALM can support project execution, testing, requirements, and issue management. The SAP S/4HANA migration cockpit supports the movement of business data, and SAP Custom Code Migration capabilities help teams assess code that may need to be adapted or removed.

Tools, however, do not make the most important decisions. Business and technology leaders must define the target operating model, migration path, acceptable risk, investment priorities, and required level of standardization.

This white paper presents a practical SAP S/4HANA migration roadmap focused on five areas:

1. Readiness and business assessment
2. Data preparation and migration
3. Custom code rationalization
4. Testing and cutover control
5. Employee adoption and operational readiness

It also introduces two critical factors: a migration risk control tower and a clean-core value account. These disciplines can help organizations maintain control after the initial business case has been approved and the difficult delivery work begins.

 

1. Why SAP S/4HANA Cloud Migrations Become Expensive

Migration costs do not usually increase because of one dramatic failure. They grow through hundreds of unresolved decisions.

A business team asks to retain a legacy report because it may still be needed. A local office requests an exception to the standard process. An interface owner cannot confirm whether a connection is still active. Historical data is moved because no one has approved an archive policy. A custom program is rebuilt before anyone checks whether standard functionality can replace it.

Each decision may seem manageable on its own. Together, they create additional scope, testing, integration, training, and support costs.

Five forms of complexity are particularly important.

Process Complexity

The same business process may operate differently across countries, legal entities, plants, business units, and product lines. Some differences are driven by law or commercial need. Others are the result of history, local preferences, or earlier system limitations.

A migration program that attempts to preserve every variation may simply reproduce the old operating model on a new platform.

Data Complexity

Customer, supplier, product, asset, finance, and inventory data may contain duplicates, incomplete records, outdated values, conflicting classifications, and inconsistent ownership.

A technically successful data load does not make poor data reliable.

Custom Code Complexity

Custom developments may include reports, interfaces, forms, workflows, enhancements, transactions, and background jobs. Over time, some become redundant, while others remain critical to business continuity.

The challenge is not only making the code technically compatible. The organization must decide whether the code should exist in the future solution.

Integration Complexity

An ERP system rarely operates alone. It exchanges data with banks, logistics providers, tax platforms, manufacturing systems, CRM applications, data warehouses, e-commerce platforms, payroll systems, and industry-specific tools.

An interface may appear technically minor while supporting a critical business process.

Organizational Complexity

Different groups often expect different outcomes from the migration. IT may prioritize supportability. Finance may want stronger controls. Operations may want minimal disruption. Business leaders may expect rapid transformation and measurable cost savings.

Without a shared definition of success, the program can become a negotiation between competing expectations.

The first step in controlling cost is to make these forms of complexity visible before detailed design begins.

 

2. Choose the Migration Path Deliberately

The migration path influences cost, duration, business disruption, data scope, custom code treatment, and the amount of process change required.

Three broad approaches are commonly considered.

New Implementation

A new implementation, often described as a greenfield approach, creates a new SAP S/4HANA environment based largely on future business requirements and standard processes.

This approach gives the organization an opportunity to simplify structures, redesign workflows, harmonize master data, and avoid carrying forward unnecessary technical debt.

It can also require significant business involvement. Processes must be redesigned, data must be selected and transformed, integrations must be rebuilt, and users must learn new ways of working.

System Conversion

A system conversion, often called a brownfield approach, converts an existing SAP ERP environment to SAP S/4HANA.

It may preserve more configuration, historical information, and established processes. This can reduce certain forms of organizational change, but it does not remove the need for readiness analysis, simplification-item work, custom code adaptation, testing, and data preparation.

Existing custom code may require changes because SAP S/4HANA includes simplified objects, updated data structures, and new application models.

Selective Data Transition

Selective data transition sits between a new implementation and a full system conversion. It allows an organization to move selected data and processes while taking a more controlled approach to historical structures and legacy content.

This model can be useful when a company wants to preserve certain business capabilities or historical data while redesigning other parts of the operating model.

There is no universally correct choice.

The decision should be based on business ambition, current-system health, process consistency, data quality, regulatory obligations, custom code dependency, available time, and the organization’s appetite for change.

Do not choose a migration path only because it appears faster at the beginning. A route that carries forward too much complexity may reduce initial effort while increasing future support, testing, and upgrade costs.

A formal migration-path decision should document:

• Why the selected approach supports the business strategy
• Which alternatives were considered
• What data will be moved
• How much process redesign is expected
• How custom developments will be handled
• What level of downtime is acceptable
• Which risks remain under the selected approach

The decision should be revisited if assessment findings materially change the original assumptions.

 

3. Build the Business Case Around Outcomes and Exposure

A weak SAP business case lists software, infrastructure, implementation, and support costs. A stronger business case also measures the cost of remaining with the current operating model.

That cost may include manual reconciliations, a slow financial close, aging integrations, duplicate support effort, process delays, limited visibility, control failures, and the growing difficulty of making changes to the existing environment.

The business case should separate four financial categories.

Transformation Cost

This includes process design, system configuration, development, integration, data preparation, testing, training, change management, program governance, and specialist support.

Transition Cost

These are the temporary costs of moving from one operating model to another. Examples include parallel systems, temporary environments, additional controls, backfill resources, travel, extended support, and cutover preparation.

Ongoing Operating Cost

This covers subscriptions, infrastructure arrangements, application management, release management, integration operations, security, support, and continuous improvement.

Business Value

Value should be tied to measurable operational changes. These may include fewer manual steps, a faster financial close, reduced process variation, better inventory visibility, improved working capital, stronger compliance, shorter approval cycles, and lower support effort.

Avoid building the case entirely around large benefits that may only appear several years later. Break value into releases that can be measured as individual capabilities go live.

The business case should also contain an explicit risk reserve. Data correction, custom code remediation, integration redesign, and additional testing frequently create unplanned effort. A reserve makes these risks visible instead of hiding them inside later change requests.

 

4. Phase One: Conduct a Readiness and Business Assessment

Assessment should begin before the program commits to a detailed delivery schedule.

SAP Readiness Check can provide an analysis of an existing SAP environment and identify areas relevant to an SAP S/4HANA transformation. It can also help identify simplification items that may affect a specific source system.

The technical assessment should examine:

• Current SAP release and system landscape
• Add-ons and active business functions
• Relevant simplification items
• Data volume and growth
• Custom code footprint
• Interfaces and external dependencies
• Fiori readiness
• Security and authorization design
• Batch jobs and operational schedules
• Archiving and retention arrangements

The business assessment should run in parallel.

Document how major processes work today, including where users leave SAP to complete tasks in email, spreadsheets, shared drives, or specialist applications. These workarounds often reveal the real operating model more clearly than formal process documentation.

Assess each process against five questions:

1. Does it create customer, operational, or regulatory value?
2. Is the variation genuinely necessary?
3. Can standard SAP functionality support the requirement?
4. What would happen if the process were simplified?
5. Who has the authority to approve the future design?

Tools such as SAP Signavio can support process analysis and transformation planning by giving teams greater visibility into existing processes and potential improvement areas.

The assessment should produce a decision-ready report, not a long inventory with no clear conclusion.

Each finding should be classified as:

• Retain
• Redesign
• Replace
• Retire
• Investigate further

Assign an owner, business impact, likely cost, dependency, and decision date to every significant item.

 

5. Phase Two: Design for Standardization Before Configuration

Fit-to-standard is sometimes misunderstood as forcing every team to accept a generic process.

Its real purpose is to begin with a proven standard and require a clear business reason for moving away from it.

SAP Activate roadmaps can guide implementation activities across project phases, while SAP Cloud ALM can provide a structured environment for project execution, requirements, testing, and issue management.

During design workshops, teams should review standard process flows in the system rather than debating requirements only through documents and presentations.

For every identified gap, record:

• The business outcome required
• The reason standard functionality is insufficient
• The number of users or transactions affected
• The regulatory or commercial consequence
• Available configuration or extension options
• Build and support implications
• The person approving the exception

This creates discipline around design.

It also prevents a common mistake: rebuilding the current system screen by screen without questioning whether the underlying process still makes sense.

Global template decisions should be made early. Define which elements are global, which may vary by region, and which require legal localization. Without this structure, individual workshops may create conflicting designs that only become visible during integration testing.

 

Establish a Migration Risk Control Tower

Most programs maintain a risk register. Far fewer create an operating mechanism that connects risk to daily delivery decisions.

A migration risk control tower is not another dashboard. It is a focused governance discipline that identifies where business exposure is increasing and forces timely action.

The control tower should track a limited number of leading indicators:

• Critical processes without approved future designs
• Data objects without accountable owners
• Custom developments awaiting disposition
• Interfaces with incomplete specifications
• Test scenarios without business acceptance
• High-severity defects without recovery dates
• Training content affected by late design changes
• Cutover activities without rehearsal evidence
• Business units with low adoption readiness
• Decisions that have remained unresolved beyond their deadlines

Each indicator should have an agreed threshold.

For example, a program may decide that no critical interface can enter system integration testing without an identified owner, monitoring approach, error-handling design, and support procedure.

The control tower should also measure risk concentration. Ten minor delays spread across several workstreams may be manageable. Three unresolved issues affecting order processing, invoicing, and financial close may threaten the entire go-live.

Hold a short weekly risk meeting focused on decisions rather than status reporting. The questions should be direct:

What has increased business exposure? What decision is required? Who can make it? When will the risk be reduced? What evidence will demonstrate that the risk has been reduced?

This discipline prevents technical activity from creating a false impression of progress. A project can complete hundreds of tasks while its largest business risks remain unresolved.

 

6. Phase Three: Treat Data as a Business Workstream

Data migration is often scheduled as a technical activity that begins after configuration. That is too late.

Data determines whether transactions can be processed, reports can be trusted, controls can operate, and employees can complete their work after go-live.

Begin with a migration data strategy covering:

• Which data objects will be moved
• How much history is required
• What will be archived
• How open transactions will be handled
• Which system owns each data element
• How data will be cleansed
• Who approves transformed data
• How reconciliation will be performed

Common migration objects may include customers, suppliers, business partners, products, materials, bills of material, assets, pricing conditions, open orders, purchase documents, inventory balances, financial balances, and open receivables or payables.

Not every historical record belongs in the new system.

Retaining data may be necessary for operations, reporting, tax, audit, warranty, or regulatory purposes. Other information can be archived and made accessible through an agreed retrieval process.

The SAP S/4HANA migration cockpit supports the movement of business data. Depending on the target environment and migration scenario, data may be migrated from supported source systems or through staging tables and migration objects.

The tool does not replace business ownership. A finance lead must still confirm opening balances. Procurement must approve supplier data. Sales must validate customer records. Operations must confirm materials and inventory.

Use several mock migration cycles rather than waiting for the final cutover.

Each cycle should test extraction, transformation, loading, validation, timing, error handling, and reconciliation. Capture how long each step takes and where manual intervention is required.

Data-quality rules should be measurable. “Clean the customer master” is not an actionable task. “Resolve all active customer records without a valid tax classification before the second migration rehearsal” is clear and testable.

Most importantly, do not use the migration team as a substitute for data governance. The owners of business data must remain accountable after go-live.

 

7. Phase Four: Rationalize Custom Code and Protect the Clean Core

Custom code is one of the largest sources of uncertainty in an SAP S/4HANA migration.

The first mistake is assuming that every development in the current system is still used. The second is assuming that every used development should be rebuilt.

Begin by creating an inventory and combining technical analysis with actual usage data.

Classify custom developments into four groups.

Retire

The functionality is unused, duplicated, outdated, or connected to a process that will no longer exist.

Replace With Standard Functionality

SAP S/4HANA provides a suitable standard capability that meets the future business requirement.

Redesign as an Extension

The requirement remains valid, but the solution should be implemented through a more sustainable extension approach.

Adapt and Retain

The development supports a necessary requirement and remains appropriate for the target architecture.

SAP Custom Code Migration capabilities can analyze custom code that may need to move from an existing SAP Business Suite environment to SAP S/4HANA. The assessment should identify code affected by SAP S/4HANA changes and simplifications.

Usage analysis is essential. A technically complex program may be irrelevant if no one runs it. A small enhancement may be critical if it affects every customer invoice.

A clean-core strategy should guide new development. Clean core means keeping the main SAP environment close to standard, avoiding unnecessary modifications, and using appropriate extension approaches so future upgrades are easier to manage.

Clean core does not mean zero customization. It means customization supported by evidence, ownership, architectural discipline, and a clear lifecycle.

Create a design authority that reviews every proposed extension. It should consider business value, standard alternatives, upgrade impact, security, integration, testing, support ownership, and retirement conditions.

A development should not be approved simply because it is technically possible.

 

8. Phase Five: Redesign Integrations for Operational Resilience

Integration planning should begin with business events, not interface names.

Ask what happens when a sales order is created, a material is changed, an invoice is posted, an employee joins, a shipment is confirmed, or a payment fails.

Then identify the applications, data, timing, controls, and recovery procedures involved.

For each integration, document:

• Business purpose
• Source and target systems
• Data ownership
• Trigger and frequency
• Expected volume
• Security requirements
• Failure handling
• Reprocessing procedure
• Monitoring responsibility
• Business continuity impact

This is also the right time to remove point-to-point connections that no longer serve a useful purpose.

However, simplification should not create a new integration layer that no one understands. The future architecture should include naming standards, interface patterns, monitoring, documentation, and support ownership.

Test failure scenarios, not only successful transactions.

A technically successful message does not guarantee that the receiving application processed the business transaction correctly. Reconciliation should confirm the business result across system boundaries.

 

9. Phase Six: Test the Business, Not Just the Configuration

Testing is the point where design assumptions meet operational reality.

A complete SAP migration testing strategy should include:

• Unit testing
• String or process testing
• System integration testing
• Data migration testing
• Security and role testing
• Performance testing
• Regression testing
• User acceptance testing
• Cutover rehearsals
• Operational readiness testing

SAP Cloud ALM provides test-management capabilities for documenting and tracking manual and automated testing activities. It can connect requirements, business processes, test cases, execution results, and defects in one environment.

The most important tests are end-to-end business scenarios.

An order-to-cash test should not stop when the order is created. It should continue through delivery, invoicing, accounting, reporting, payment, and connected systems.

Testing should include realistic exceptions:

• Credit blocks
• Incorrect master data
• Partial delivery
• Rejected approvals
• Tax calculation differences
• Integration failures
• Inventory shortages
• Reversed postings
• Payment discrepancies
• Authorization restrictions

Create a traceable relationship between requirements, processes, test cases, defects, and approvals.

Business users must participate early. User acceptance testing should not be the first time process owners see the configured solution.

Defects should be prioritized according to business impact, not only technical severity. A minor display problem may be inconvenient. A posting error that affects financial close may threaten go-live.

Define exit criteria before testing begins. These criteria should cover critical process completion, defect thresholds, data reconciliation, performance, security, operational support, and business acceptance.

Without agreed exit criteria, go-live decisions can become subjective and political.

 

10. Phase Seven: Rehearse Cutover and Protect Business Continuity

Cutover is a business event supported by technology.

It may involve transaction freezes, final extraction, data loads, reconciliations, technical changes, interface activation, user provisioning, open-item handling, communications, and support mobilization.

Create a detailed cutover plan with:

• Named activity owners
• Start and completion times
• Dependencies
• Validation evidence
• Escalation paths
• Go or no-go checkpoints
• Backout conditions
• Business communication steps

Rehearse the complete cutover more than once.

A rehearsal should test timing, staffing, system access, decision-making, data validation, issue escalation, and communication. Do not treat it only as a technical data-load exercise.

Define the minimum business capability required for go-live.

For example, the organization may need to create orders, receive goods, pay suppliers, issue invoices, run production, access inventory, complete critical approvals, and post financial transactions.

Plans should exist for temporary manual workarounds when a noncritical capability is delayed. Those workarounds need owners, controls, capacity estimates, and a clear end date.

A backout plan is only useful when the team understands the point beyond which reversal is no longer practical.

 

11. Phase Eight: Build Adoption Into the Design

Employees do not adopt an ERP system because training attendance has reached 95%.

They adopt it when they understand the new process, can complete their responsibilities, know where to get help, and see leaders using the same system and rules.

Change management should begin during assessment.

Identify affected roles, process changes, control changes, job impacts, and likely resistance. Some users may experience only a new screen. Others may lose local authority, take on additional data responsibility, or work through a completely redesigned process.

Training should be role-based and scenario-based.

A warehouse user, finance controller, procurement manager, plant planner, and executive approver require different learning journeys.

Use realistic data and business situations. Teach users what to do when a transaction fails or information is missing, not only how the ideal process works.

Build a network of business champions who participate in design reviews, testing, communications, and early support. Give them sufficient time and authority to perform the role.

Adoption measures should continue after go-live:

• Process completion
• Error and rejection rates
• Manual workaround volume
• Support tickets
• Transaction delays
• Data-quality issues
• Use of new applications
• Reversion to spreadsheets
• Employee confidence
• Manager compliance

A temporary increase in support tickets is normal. Repeated errors in the same process may indicate a design, data, role, or training issue.

Do not assume the user is always the problem.

 

Create a Clean-Core Value Account

Clean core is often discussed as an architectural principle. It should also be managed as a financial and operational asset.

Create a clean-core value account that records the complexity removed and the future cost avoided during the migration.

Track items such as:

• Custom programs retired
• Reports replaced by standard analytics
• Interfaces removed
• Process variations eliminated
• Data objects archived
• Manual reconciliations discontinued
• Modifications replaced by supported extensions
• Local applications decommissioned
• Duplicate master records resolved
• Business rules standardized

Assign an estimated annual support, testing, infrastructure, license, or operational cost to each item when credible data is available.

The purpose is not to create an inflated savings number. It is to make simplification visible.

This changes program behavior.

Without a value account, teams receive recognition for building new functionality but little recognition for removing unnecessary complexity. With a value account, retirement becomes a measurable program outcome.

The account should continue after go-live. Every new extension or exception adds to the organization’s future maintenance responsibility.

Review the account during release planning. Ask whether the landscape is becoming easier or harder to change.

That is the real clean-core test.

 

12. Governance That Keeps the Program Moving

Large SAP programs can become slow because decision rights are unclear.

Create a governance structure with distinct responsibilities.

Executive Steering Group

Owns business outcomes, funding, major scope decisions, risk acceptance, and go-live authority.

Design Authority

Owns process standards, solution architecture, integration patterns, data principles, and extension decisions.

Business Process Owners

Approve future processes, resolve cross-functional conflicts, provide testing resources, and accept business outcomes.

Data Owners

Define quality rules, approve data, and remain accountable after go-live.

Program Management

Maintains the integrated plan, dependencies, budget, issues, risks, resources, and delivery evidence.

Change and Adoption Leadership

Owns stakeholder impact, communication, training, readiness, and post-go-live adoption.

Governance should make decisions at the lowest appropriate level. Sending every design question to the steering committee creates delays. Allowing workstreams to make enterprise-wide decisions independently creates inconsistency.

Maintain a decision log containing the decision, owner, date, rationale, affected areas, and consequences. This record becomes important when team members change or earlier assumptions are questioned.

 

13. Measuring Migration Success

A migration is not successful simply because the system went live on the planned date.

Use a balanced scorecard covering delivery, operations, adoption, simplification, and business value.

Delivery Measures

• Budget variance
• Milestone achievement
• Scope changes
• Defect trends
• Test completion
• Data-reconciliation status
• Cutover readiness

Operational Measures

• System availability
• Interface success
• Transaction-processing time
• Batch completion
• Support volumes
• Critical business incidents
• Financial posting accuracy

Adoption Measures

• User activity
• Process compliance
• Training completion
• Task-success rates
• Manual workaround usage
• Support-request patterns

Simplification Measures

• Custom code retired
• Process variations removed
• Interfaces reduced
• Applications decommissioned
• Data archived
• Standard functionality adopted

Business-Value Measures

• Financial-close duration
• Approval times
• Inventory visibility
• Order-processing performance
• Procurement compliance
• Working-capital indicators
• Reporting effort
• Support cost
• Control effectiveness

Establish baseline measures before migration. Otherwise, the organization may struggle to demonstrate improvement after go-live.

 

Conclusion

Moving to SAP S/4HANA Cloud is an opportunity to modernize the operating foundation of the business. It is also a moment when years of hidden complexity become visible.

The safest response is not to avoid change. It is to manage change with evidence.

Begin with a serious assessment. Choose the migration path based on business ambition and system reality. Clean and govern the data before moving it. Challenge custom developments rather than rebuilding them automatically. Test complete business processes and failure scenarios. Rehearse cutover as an operational event. Prepare employees for new responsibilities, not just new screens.

Above all, keep the program connected to business outcomes.

A migration risk control tower can help leadership focus on the areas where exposure is increasing. A clean-core value account can show whether the organization is genuinely reducing complexity or simply relocating it.

The real benefit of SAP S/4HANA Cloud is not that it replaces an older ERP platform. It is that it can give the organization a more consistent, supportable, and adaptable way to run the business.

That value depends on the decisions made during migration and the discipline used to protect them.

How Infonikka Can Help

Infonikka supports organizations through every stage of SAP S/4HANA Cloud migration, from readiness assessment and process design to data migration, custom code optimization, integration, testing, deployment, and ongoing support. Our SAP specialists help reduce complexity, manage business risk, and build a scalable, clean-core environment aligned with long-term business goals. Explore our SAP Consulting Services.