For a large enterprise, an SAP S/4HANA migration typically takes between 18 and 36 months from initial scoping to go-live. The exact timeline depends on the size of the organisation, the number of systems and business units involved, the migration approach chosen, and how much custom code exists in the current SAP landscape. The sections below walk through the main phases, the key decisions you will face, and where the highest risks tend to concentrate.
How long does an SAP S/4HANA migration take for a large enterprise?
A large enterprise SAP S/4HANA migration typically runs between 18 and 36 months. Smaller programmes with a focused scope can land closer to 18 months, while complex multi-country or multi-system transformations often extend to three years or more. The most important factor is not the software itself but the organisational complexity surrounding it.
Several variables directly affect the timeline. The number of company codes, legal entities, and integrations in scope all add time. So does the volume of custom code that needs to be assessed, adapted, or retired before the new system can go live. Organisations that have invested heavily in modifications to their existing SAP ECC environment tend to face longer preparation phases than those running closer to standard.
Another factor that often gets underestimated is organisational readiness. Even a technically well-planned programme can stall if business stakeholders are not aligned, if process owners are unavailable for workshops, or if key decisions about the target design keep getting deferred. Getting that alignment right early, before the programme is fully underway, is one of the most useful things you can do to protect your timeline.
What are the main phases of the SAP S/4HANA migration process?
An SAP S/4HANA migration for a large enterprise follows a structured sequence of phases, typically covering preparation and scoping, design, build and configuration, testing, cutover, and post-go-live stabilisation. Each phase has distinct deliverables and decision points, and skipping or rushing any of them tends to create problems downstream.
- Preparation and scoping: Define the programme scope, assess the current system landscape, and establish the business case. This is also where a maturity assessment helps organisations understand where they actually stand before committing budget and resources to a full roadmap.
- Design (Blueprint / Explore): Document current processes (As-Is) and define the target state (To-Be). Decisions made here shape everything that follows, so thoroughness pays off.
- Build and configuration: Configure the system, develop integrations, and handle any necessary custom development. Data migration objects are also built and tested during this phase.
- Testing: Unit testing, integration testing, user acceptance testing, and performance testing. This phase validates that the system behaves as designed and that users can work with it effectively.
- Cutover: The final transition from the legacy system to the new environment. This phase includes data load, system checks, and the go/no-go decision.
- Hypercare and stabilisation: Intensive post-go-live support to resolve issues quickly and prevent disruption from affecting operations.
Across our full range of services, we see programmes succeed or struggle largely based on how well these phases are sequenced and governed, not just on the technical configuration itself.
What is the difference between greenfield and brownfield SAP S/4HANA migration?
A greenfield SAP S/4HANA migration means building a new system from scratch, adopting SAP’s standard processes as the baseline. A brownfield migration means converting the existing SAP ECC system to S/4HANA, preserving historical data, custom developments, and existing configurations. The right choice depends on how much of your current setup you want to carry forward and how much transformation you are willing to take on.
Greenfield: starting clean
Greenfield gives you the opportunity to redesign processes from the ground up, adopt best-practice standards, and remove years of accumulated technical debt. It is typically the right approach when the existing system is heavily customised, when business processes need significant redesign, or when the organisation wants to use the migration as a genuine transformation rather than a technical upgrade. The trade-off is that greenfield programmes are generally longer and more resource-intensive, and they require strong change management because the way people work changes substantially.
Brownfield: converting what you have
Brownfield keeps your existing data, configurations, and, to a large extent, your existing processes. It is faster to execute and less disruptive in the short term. The risk is that you carry forward complexity you might have been better off leaving behind. Brownfield works well when the current system is relatively clean, when time-to-go-live is a hard constraint, or when the business case does not justify a full process redesign. Many organisations also opt for a hybrid approach, converting the core system via brownfield while selectively redesigning specific processes or business units.
What makes data migration the riskiest phase of an SAP S/4HANA project?
Data migration is the riskiest phase of an SAP S/4HANA project because errors in data quality, mapping, or loading can directly affect operational continuity from day one. Unlike configuration problems that can be corrected after go-live, corrupted or missing data can cause immediate business disruption, financial reporting errors, and loss of trust in the new system.
The risk concentrates in several specific areas. First, data quality in the source system is almost always worse than expected. Duplicate records, inconsistent formats, missing mandatory fields, and outdated master data all need to be identified and resolved before migration can proceed. This cleansing work is time-consuming and requires active involvement from business teams who understand what the data means, not just the technical teams who manage it.
Second, the mapping between source and target structures is complex. SAP S/4HANA has a different data model from ECC in several areas, particularly around the Business Partner concept, which replaces separate customer and vendor records. Getting these mappings right requires detailed As-Is and To-Be analysis of the current data structures, followed by rigorous testing across multiple migration cycles before the final load.
Third, the final data load happens under time pressure during the cutover window. There is limited room to fix problems at that point. Organisations that invest in thorough data migration management earlier in the programme, including multiple mock migrations and automated validation checks, are far better positioned when it counts.
How does cutover management work in a large SAP S/4HANA migration?
Cutover management in a large SAP S/4HANA migration is the structured process of shutting down the legacy system, executing the final data load and technical steps, validating the new system, and making the go/no-go decision to open it to users. For a large enterprise, this process typically runs over a weekend or a planned downtime window of two to five days, and it is one of the most operationally sensitive moments in the entire programme.
Good cutover management starts long before the actual cutover weekend. A detailed cutover plan documents every task, the sequence in which it must be completed, the team responsible, and the expected duration. This plan is rehearsed in mock cutovers, which are full dry runs of the cutover sequence against a production-like environment. Each mock run reveals gaps in timing, dependencies that were missed, or steps that take longer than planned.
During the actual cutover, a command centre structure keeps all workstreams coordinated in real time. Technical teams handle system preparation and data loading. Functional teams validate that data has landed correctly and that key business processes work as expected. A clear escalation path ensures that problems get resolved quickly rather than quietly ignored until they become critical.
The go/no-go decision is a formal checkpoint. It requires sign-off from business and technical stakeholders based on predefined criteria, not on optimism or schedule pressure. If the criteria are not met, a rollback plan must be ready to execute. After go-live, a hypercare period of typically four to eight weeks provides intensive support while users and processes stabilise in the new environment.
How Optinus helps with SAP S/4HANA migration
We support large enterprises through the full SAP S/4HANA migration journey, from the first assessment of where you stand to post-go-live stabilisation. Our consultants have worked on real migrations at leading multinationals, so we bring hands-on experience to every phase, not just methodology.
- Maturity assessment: We start by giving you a clear picture of your current ERP and transformation readiness before any roadmap or budget is committed.
- Project and program management: We manage scope, timelines, and stakeholder alignment across workstreams, available on-site and remote across the Netherlands, Belgium, and internationally.
- Data migration management: We use rigorous As-Is/To-Be analysis and structured testing cycles to prevent data loss and errors during the migration.
- Cutover management: We plan and run the cutover end-to-end, including mock cutovers, real-time command centre coordination, and hypercare after go-live.
- Change management: We address the human side of the transformation, driving genuine adoption across the organisation rather than just delivering training sessions.
If you are preparing for or already running an SAP S/4HANA programme, get in touch with our team to discuss where we can add the most value. You can also learn more about what we do and how we approach complex ERP transformations.
