SAP S/4HANA Migration Conversion Overview: Phases, Decisions, and Controls

SAP S/4HANA migration is a coordinated business and technology program rather than a single technical upgrade. The work includes selecting a transition path, assessing the source system, resolving functional and technical dependencies, preparing data and custom code, validating integrations, and controlling the production cutover.

A useful migration plan connects each workstream to an operational decision: what is retained, what is redesigned, what is retired, and what must be proven before go-live. This approach gives the project team a practical baseline for estimating effort, sequencing dependencies, and assigning ownership.

01What an SAP S/4HANA migration includes

An SAP S/4HANA migration normally covers the source ERP system, the target release and deployment model, business processes, master and transactional data, custom developments, interfaces, security, reporting, testing, cutover, and post-go-live support.

The first planning activity is to establish the scope boundary. Record the company codes, plants, sales organizations, purchasing organizations, controlling areas, ledgers, interfaces, reports, forms, workflows, and external applications that are in scope. Map each item to an owner and a validation method.

A migration inventory should also capture the source release, database platform, installed add-ons, active business functions, custom namespaces, batch schedules, file exchanges, RFC destinations, middleware flows, and downstream reporting dependencies. The inventory becomes the reference for readiness reviews and cutover rehearsals.

02Choose the transition approach

The main transition approaches are system conversion, new implementation, and selective data transition. The right choice depends on the value of existing configuration and history, the desired process redesign, data-retention requirements, landscape constraints, and the time available for business validation.

A brownfield-style conversion is generally appropriate when the current system contains valuable configuration, historical data, and established processes that the organization intends to preserve. A greenfield-style implementation is generally appropriate when process redesign, harmonization, or a clean organizational model has priority. A selective transition requires especially clear rules for retained history, open items, balances, and reconciliation.

Document the decision with measurable criteria. Include process fit, historical-data requirements, custom-code volume, add-on compatibility, integration complexity, business downtime tolerance, compliance obligations, and the organization's capacity to redesign processes.

For a detailed comparison of the two common approaches, use SAP S/4HANA brownfield vs greenfield migration.

03Assess readiness before build work

Readiness work turns assumptions into evidence. Start with the source-system inventory, then assess software compatibility, simplification impacts, data quality, custom code, interfaces, security, and operational capacity.

The team should maintain a finding register with these fields:

• Finding and affected object
• Business or technical owner
• Impacted process
• Required action
• Dependency
• Target completion date
• Validation evidence
• Residual risk and decision authority

Run the simplification assessment early enough to affect scope and design. Each relevant item should have an owner, an implementation decision, a test case, and evidence that the result works in the target environment. Link findings to process owners so that technical remediation receives business validation.

The SAP S/4HANA simplification item check provides a focused companion for organizing this assessment.

Readiness also includes organizational preparation. Confirm decision rights, business-process owners, data owners, security owners, integration owners, cutover leadership, and the escalation path for unresolved findings.

04Plan the migration project phases

A practical phase model separates decisions from execution while allowing controlled iteration:

1. Discover and assess — Define objectives, inventory the landscape, identify constraints, and estimate the major workstreams.
2. Prepare and design — Confirm the transition approach, establish the target architecture, define the data scope, and approve the delivery plan.
3. Explore and validate — Review standard processes, assess fit, confirm organizational impacts, and make scope decisions.
4. Realize and remediate — Configure the target, adapt custom code, prepare data, build integrations, and execute iterative tests.
5. Deploy and cut over — Freeze changes, complete final migration activities, reconcile results, activate the target, and validate business operations.
6. Run and optimize — Stabilize the solution, resolve defects, measure adoption, and move approved improvements into the normal change process.

Each phase should end with evidence-based exit criteria. Examples include an approved scope, completed readiness findings, signed process designs, passed integration tests, reconciled migration results, an approved cutover plan, and a staffed hypercare model.

For a phase-by-phase delivery view, see SAP S/4HANA migration project phases.

05Control data migration and business partner conversion

Data migration requires more than extracting and loading records. Define the source of truth, transformation rules, validation rules, ownership, retention requirements, and reconciliation method for every data object.

Separate data into categories such as configuration, master data, open transactions, balances, historical records, and technical control data. For each category, record whether it is migrated, transformed, archived, retained in the source, or recreated in the target.

Business partner conversion deserves its own workstream when customer and vendor records are involved. Establish grouping and numbering rules, role requirements, duplicate handling, mandatory attributes, synchronization dependencies, and post-conversion validation.

The SAP S/4HANA business partner conversion guide is useful when planning this workstream.

Reconciliation should cover record counts, balances, open items, organizational assignments, document relationships, tax-relevant values, and representative business scenarios. Store the evidence with the migration run identifier and approval record.

06Manage custom code and integrations

Custom code remediation should begin with an inventory of custom objects and their business owners. Classify each object as retain, adapt, replace with standard functionality, retire, or defer. Prioritize objects that affect financial postings, logistics execution, master data, interfaces, batch processing, and reporting.

A good remediation workflow includes static analysis, technical adaptation, unit testing, process testing, performance testing where needed, and business-owner acceptance. Track dependencies between custom objects and changed data structures or APIs.

The SAP S/4HANA custom code migration guide provides a focused workflow for this workstream.

Interfaces need the same discipline. Inventory inbound and outbound messages, APIs, RFC-based connections, files, middleware flows, certificates, schedules, monitoring ownership, and error-reprocessing procedures. Test both successful processing and controlled failure handling.

07Build a risk-based test strategy

Testing should demonstrate that the target system supports the business outcomes defined in scope. Combine several layers:

• Unit tests for adapted developments and transformations
• Functional tests for configured processes
• Integration tests across SAP and external systems
• Data-reconciliation tests for migrated objects and balances
• Regression tests for retained business processes
• Security tests for roles, segregation of duties, and sensitive data
• Performance and volume tests for critical workloads
• Cutover rehearsal tests using representative timing and dependencies
• User acceptance tests led by business process owners

Prioritize scenarios by financial impact, transaction volume, regulatory significance, integration dependency, and business interruption risk. Test negative paths as deliberately as successful paths: rejected messages, duplicate records, missing master data, authorization failures, locked periods, and restart recovery all need defined outcomes.

Record test evidence that identifies the scenario, system state, data set, result, defect reference, retest result, and approval. A passed test without traceable evidence is difficult to use during go-live decisions.

08Prepare cutover and go-live controls

The cutover plan should be a time-sequenced operational runbook. Assign an owner, start condition, expected duration, dependency, completion evidence, and escalation path to every task.

Typical cutover controls include:

• Change freeze and transport sequencing
• Final data-extraction and transformation windows
• Interface pause and restart instructions
• Background-job handling
• User and role provisioning
• Open-item and balance migration
• Technical validation and monitoring activation
• Business smoke tests
• Reconciliation and sign-off
• Backout or recovery decision points
• Hypercare staffing and incident routing

Run at least one rehearsal with production-like data volumes and realistic dependency timing. Capture elapsed time, failed steps, manual workarounds, and decision latency. Use the results to update the final runbook rather than relying on nominal estimates.

Go-live approval should be based on agreed thresholds for critical defects, reconciliation differences, test completion, operational readiness, business-owner sign-off, and support coverage.

09Stabilize after go-live

Hypercare should have a defined duration, severity model, triage process, communication rhythm, and exit criteria. Separate incidents caused by data, configuration, custom code, integrations, security, and user procedures so that the right owner receives the issue quickly.

Monitor business-critical flows as well as technical health. Examples include financial postings, order-to-cash processing, procure-to-pay processing, goods movements, batch jobs, interfaces, output, authorizations, and reconciliation reports.

Maintain a daily stabilization review that covers new incidents, aging defects, failed interfaces, data corrections, performance signals, business impact, and decisions required from governance. After hypercare, transfer recurring tasks, monitoring ownership, runbooks, and known-error records to the operational support model.

10Migration decision checklist

Before approving the next major milestone, confirm that:

• The transition approach has documented business and technical rationale.
• In-scope organizational units, processes, data, interfaces, and reports are identified.
• Readiness findings have owners, due dates, validation evidence, and risk decisions.
• Simplification impacts are assessed and reflected in the design.
• Data rules, reconciliation totals, and business partner requirements are approved.
• Custom code and add-on decisions are recorded.
• Integration, security, regression, performance, and user acceptance tests have traceable evidence.
• Cutover tasks have owners, dependencies, durations, and recovery decisions.
• Business and technical go-live criteria are measurable.
• Hypercare support, monitoring, incident routing, and operational handover are staffed.

The most reliable migration programs keep this checklist current throughout delivery. It should operate as a governance control, not as a final presentation artifact.