Most SAP migration guides are written for consultants and architects. They assume you understand the difference between a brownfield and greenfield migration, that you're comfortable with BASIS administration, and that you have access to an SAP Centre of Excellence. This guide is written for the product manager who owns the roadmap, manages 12 stakeholders, and needs to explain to the CFO why this is taking longer and costing more than initially estimated.
Phase 0: Decide What You're Actually Migrating
The most important decision in an SAP S/4HANA migration isn't which migration path to take (brownfield vs. greenfield vs. selective data transition). It's deciding which business processes you're migrating versus which ones you're redesigning. These are fundamentally different activities with different timelines, different risk profiles, and different success criteria.
A brownfield migration preserves your existing configuration and customisations. It's faster, lower risk, and produces an S/4HANA system that looks and behaves very much like your current ECC system. Which means it also preserves your existing technical debt. A greenfield implementation gives you a clean slate, but it requires re-implementing every business process from scratch. Most real-world programmes end up somewhere in between.
The Stakeholder Map Nobody Draws
SAP migrations have a wider stakeholder footprint than almost any other technology programme. You are simultaneously managing: Finance (who cares about period-end close and reporting), IT (who care about integration, performance, and supportability), Compliance (who care about audit trails and regulatory reporting), and Business Operations (who care about not having their processes disrupted during the transition).
Each group has veto power. Each group has different information needs. Each group will push back at different points in the programme. Map them all before you start, understand their primary concerns, and establish a communication rhythm that keeps each group informed without overwhelming them.
The Go-Live Decision Framework
The most political moment in any SAP migration is the go-live decision. Business pressure pushes for early go-live; technical teams push for more testing time. The right answer requires a structured decision framework, not a negotiation.
The framework I use has three gates. Gate 1: all P1 and P2 defects resolved, all P3 defects have an accepted workaround or are deferred with sign-off. Gate 2: parallel-run reconciliation shows less than 0.1% variance across all financial reports. Gate 3: the finance team, not the IT team, has signed off on the user acceptance testing. Miss any gate and you don't go live. This sounds simple. In practice, it requires enormous discipline to hold to when the pressure is on.
Post-Go-Live: The Forgotten Phase
Most migration programmes are heavily resourced until go-live and then immediately begin winding down. This is backwards. The 60 days after go-live are when the real problems surface: the edge cases that weren't tested, the process gaps that only appear at month-end, the user adoption issues that weren't visible in UAT.
Maintain your full hypercare team for at least 30 days post-go-live. Establish a daily stand-up between finance, IT, and product to triage issues. Keep your cutover team on standby for the first month-end close. The additional cost is small relative to the risk of a delayed or failed close.