S/4HANA Migration Roadmap: Phases, Owners and Cutover Plan

9 min read ยท 2026-10-25

An S4HANA migration roadmap is the phased plan that takes your company from SAP ECC to SAP S/4HANA: assess readiness, choose a transition approach, prepare data and custom code, build and test, rehearse the cutover, go live and stabilize. A system conversion for a mid-size company often runs about a year from the readiness check to the end of hypercare, while a greenfield implementation across many countries runs longer.

SAP's own delivery method, SAP Activate, uses six phases: Discover, Prepare, Explore, Realize, Deploy and Run. The roadmap below follows that logic and adds what steering committees need: an owner for each phase, milestones you can check, a filled-in example for a brownfield conversion, the risks that most often move go-live, and how to report it all on one slide.

The roadmap at a glance

Goal: The business runs on SAP S/4HANA with reconciled financial and master data, adapted custom code and trained users, and the ECC system is retired or kept read-only for history. Duration: 12 months

  1. Discover and assess (Weeks 1-6)

    Understand what moving to S/4HANA means for your current system and business.

    • Run the SAP Readiness Check on your ECC system to see simplification items, add-on compatibility and custom code impact.
    • Review the simplification items that affect you, such as the Business Partner model for customers and vendors.
    • Analyze custom code usage and mark code that is never run for retirement.
    • Map business pain points and goals, such as a faster close or real-time inventory.

    Milestone: Readiness assessment reviewed with the CIO and CFO, listing major impacts and open decisions. Metric: number of relevant simplification items and share of custom objects actually in use.

  2. Choose the approach and plan (Weeks 5-10)

    Decide how you will move and set up the program to deliver it.

    • Compare greenfield (new implementation), brownfield (system conversion) and selective data transition against your goals, data and timeline.
    • Choose the deployment model, such as SAP S/4HANA Cloud Private Edition or on premise, with IT and finance.
    • Set governance: sponsor, steering committee, program manager, solution architect, process owners and the system integrator.
    • Build the integrated plan with test cycles, mock cutovers and business blackout periods like year-end close.

    Milestone: Transition approach and program plan approved by the steering committee. Metric: open design decisions with an owner and a due date.

  3. Prepare data and code (Weeks 8-20)

    Clean the data and adapt the code before the first conversion run.

    • Clean and archive old data, close open items that should not move and fix duplicates in customer, vendor and material masters.
    • Run customer and vendor integration so every customer and vendor maps to a Business Partner.
    • Adapt custom code that is still used, using the ABAP Test Cockpit checks for S/4HANA, and remove the rest.
    • Check interfaces and third-party add-ons with their owners and vendors.

    Milestone: Business Partner conversion complete in the test system, critical custom code adapted and data cleansing targets met. Metric: open data errors and unadapted custom objects in use.

  4. Convert, build and test (Weeks 18-36)

    Run conversions in test systems and prove the processes work end to end.

    • Run a first conversion of a copy of production in a sandbox, using the Software Update Manager for a system conversion.
    • Fix issues, then repeat in the development and quality systems.
    • Run unit, integration and regression tests across key processes such as order to cash, procure to pay and record to report.
    • Run user acceptance testing with process owners, including month-end close and financial reconciliation.

    Milestone: UAT signed off by process owners with no open critical defects, and financial reconciliation of the converted data accepted by the controller. Metric: test cases passed and open defects by severity.

  5. Train and rehearse cutover (Weeks 34-46)

    Prepare users and prove the cutover fits the downtime window.

    • Train key users first, then end users by role, focusing on changed screens and Fiori apps.
    • Write the cutover runbook with every task, owner, duration, check and rollback point.
    • Run at least two mock cutovers on full production copies and time each step.
    • Agree downtime with the business and plan around blackout periods.

    Milestone: Final mock cutover completed within the agreed downtime, and go-live approved at the go or no-go meeting. Metric: mock cutover duration against the downtime window.

  6. Go-live and hypercare (Weeks 46-52)

    Switch to S/4HANA and stabilize until support can take over.

    • Run the production cutover with a command center and hourly checkpoints.
    • Validate data with finance and process owners before releasing the system to users.
    • Staff hypercare with key users, the integrator and internal support, with a daily issue review.
    • Close the first month-end on S/4HANA and hand over to support with a known issues list.

    Milestone: First month-end close completed on S/4HANA, no open critical issues, support handover signed. Metric: open tickets by severity and time to close them.

Greenfield, brownfield or selective data transition

The approach decides most of your plan. A greenfield implementation starts with a new S/4HANA system and moves selected data. It lets you redesign processes but takes longer and needs more business time. A brownfield conversion turns your ECC system into S/4HANA and keeps your history, configuration and custom code. It is usually faster but carries old design choices with it. A selective data transition sits between the two: you build a new system and move only some data, such as certain company codes or years.

Choose based on three questions. How much do you want to change your processes? How clean are your current configuration and data? How much time does the business have for design workshops? Write the answers down, because the steering committee will ask why you picked one over the others.

Example: a brownfield conversion for a mid-size manufacturer

Picture a manufacturer running SAP ECC with finance, sales, purchasing, production and warehouse modules, a few hundred custom programs and interfaces to a transport system and a payroll provider. The CFO wants a faster close, and IT wants to move off its current database. The steering committee picks a brownfield conversion to keep history and limit business disruption.

Finance owns the reconciliation in this example, not IT. The controller signs off that balances match before and after conversion in every test cycle.

  • Months 1-2, assess: SAP team runs the Readiness Check, solution architect lists the main simplification items. Milestone: assessment accepted by CIO and CFO.
  • Months 2-3, plan: steering committee approves brownfield and Private Edition. Milestone: plan with three test cycles and two mock cutovers.
  • Months 2-5, prepare: master data team cleans vendors and customers, developers retire unused custom code. Milestone: Business Partner conversion in test.
  • Months 5-9, convert and test: integrator runs sandbox and quality conversions, process owners run UAT including month-end close. Milestone: UAT signed.
  • Months 9-11, train and rehearse: key users train teams on Fiori apps, two mock cutovers over weekends. Milestone: final mock fits the downtime window.
  • Month 12, go-live: cutover over a long weekend, two weeks of hypercare. Milestone: first close on S/4HANA.

Who owns what

S/4HANA programs involve your business, your IT team and usually a system integrator. Confusion about who decides on process and data is a major cause of delays. Put a RACI in the program charter and keep it current.

Business ownership of data and testing matters most. IT can run the conversion, but only the business can confirm that the numbers and processes are right.

  • Executive sponsor (often the CFO or COO): owns outcomes, chairs the steering committee, decides trade-offs.
  • Program manager: integrated plan, RAID log, status reporting and coordination with the integrator.
  • Solution architect: approach, design decisions and technical quality.
  • Process owners: design decisions, test scripts and UAT sign-off for their area.
  • Master data lead: cleansing, Business Partner conversion and data quality reporting.
  • SAP Basis and technical team: system copies, conversions, performance and the cutover runbook.
  • Key users: testing, training colleagues and first-line hypercare support.

Risks and dependencies

Most S/4HANA programs slip on data, custom code and business availability rather than on the conversion tools. Log each risk with an owner and a fallback from the first steering meeting.

Check the dates that drive your timeline with SAP, such as maintenance end dates for your ECC release and the support status of your add-ons. Plan go-live away from year-end, audits and peak season.

  • Dirty master data: owner is the master data lead. Fallback: start cleansing in the assessment phase and set data quality gates before each test cycle.
  • Custom code volume: owner is the development lead. Fallback: retire unused code first and adapt only what is used.
  • Third-party add-ons: owner is the solution architect. Fallback: confirm compatibility with vendors early and plan replacements.
  • Downtime too long: owner is the Basis lead. Fallback: optimize the runbook after each mock and agree a longer window with the business if needed.
  • Busy process owners: owner is the sponsor. Fallback: protected time and backfill agreed with their managers.

Metrics to track

Report a short set of metrics to the steering committee every two weeks. Pull them from your test management tool, data quality reports and the cutover log.

After go-live, track business metrics too, such as days to close and order processing time, so you can show the migration delivered more than a technical upgrade.

  • Data quality: open data errors per object, such as customers, vendors and materials, before each test cycle.
  • Custom code: used custom objects adapted against total.
  • Testing: test cases passed and open defects by severity per cycle.
  • Reconciliation: differences in financial balances before and after conversion.
  • Cutover readiness: mock cutover duration against the downtime window.
  • Hypercare: open tickets by severity and days to close the first month-end.

How to present it to the steering committee

Use one slide per meeting: the six phases on a timeline with today marked, status colors for scope, schedule, data, testing and readiness, the top three risks with owners, and the decisions you need that day. Show the date of the next mock cutover and whether the last one fit the downtime window.

Leave out object-level detail and defect lists. Bring them as backup. Frame decisions as options with impact, such as moving a non-critical process change to a later release to protect go-live. That is what the committee is there to decide.

Common mistakes to avoid

  • Choosing the transition approach before running the readiness check leads to surprises in data and code, so assess first and decide second.
  • Starting data cleansing after the first conversion means every test cycle fails on the same errors, so clean master data during the assessment phase.
  • Adapting every custom program wastes effort on code nobody runs, so measure usage and retire unused objects first.
  • Letting IT sign off on converted financial data leaves gaps nobody owns, so make the controller accountable for reconciliation in every cycle.
  • Going live without at least one full mock cutover risks running over the downtime window, so rehearse on full production copies and time every step.
  • Planning go-live near year-end close puts finance under double pressure, so agree blackout periods with the CFO when you build the plan.

Frequently asked questions

How long does an S/4HANA migration take?

It depends on the approach, system size, custom code, data volume and number of countries. A brownfield conversion for a mid-size company often runs around a year, while greenfield programs for large groups can take several years in waves. Build your plan from the readiness check, not a fixed date.

What is the difference between greenfield and brownfield S/4HANA?

Greenfield is a new implementation where you redesign processes and move selected data. Brownfield is a system conversion that keeps your configuration, history and custom code. Selective data transition is a mix, where you move only part of the data into a new system.

What is the SAP Readiness Check?

It is an SAP tool that analyzes your ECC system and reports what will be affected by a move to S/4HANA. It covers simplification items, add-on compatibility, custom code impact and other preparation tasks. Most programs run it at the very start.

What are the SAP Activate phases?

SAP Activate uses six phases: Discover, Prepare, Explore, Realize, Deploy and Run. Many S/4HANA programs map their plan and quality gates to these phases.

Do you need to clean data before migrating to S/4HANA?

Yes, it is one of the biggest factors in a smooth migration. Customer and vendor records must map to Business Partners, and duplicates or incomplete records cause conversion errors. Start cleansing early and set data quality gates before each test cycle.

Generate this roadmap with AI