Post-Migration Operating Model, Cost Governance, and Roadmap Evolution
How architects design the operating model, cost governance, and multi-year roadmap that keep an S/4HANA migration architecture sustainable after go-live.
Explanation
A migration architecture is not finished at cutover; the decisions made during design determine whether the organization can operate, extend, and afford the new landscape for years afterward. This lesson addresses the final and often neglected layer of migration architecture: the post-migration operating model, cost governance, and roadmap evolution. Why it matters: many programs treat go-live as the finish line and under-invest in defining who owns what afterward. The result is fragmented ownership between the SAP Basis team, the integration team, the BTP platform team, and functional teams, leading to slow incident resolution, uncontrolled custom code growth, and unplanned cost overruns from BTP consumption or HANA sizing surprises. An architect's job is to design the operating model as deliberately as the technical migration path. Operating model dimensions to define during migration design, not after: 1. Ownership boundaries: Which team owns the clean core extension layer (BTP side-by-side extensions, in-app extensibility), which owns integration middleware (SAP Integration Suite or third-party), and which owns the core ERP configuration. In hybrid landscapes spanning ECC remnants, S/4HANA, and BTP, unclear ownership at the seams is the most common source of prolonged outages. 2. Change governance: A converted or reimplemented system still needs a controlled path for future changes. Architects should define how new extensions are vetted for clean core compliance (e.g., released APIs only, no core modification) and how integration changes are tested against downstream systems before deployment. This is different from ECC-era change management because cloud components (public cloud S/4HANA, BTP services) may have vendor-driven release cycles the customer does not fully control. 3. Monitoring and support model: Define what "healthy" looks like post go-live: interface throughput baselines, batch job windows, HANA memory and CPU utilization, BTP service consumption. Establish who is paged for which failure category, and ensure runbooks reference the actual migration architecture (e.g., which interfaces run through the cloud connector, which fall back to legacy paths). Cost governance: On-premise and private cloud S/4HANA cost is largely fixed (licensing, infrastructure, support), so cost risk concentrates in sizing errors and custom code maintenance. Public cloud S/4HANA and BTP introduce consumption-based and subscription elements: integration message volume, BTP service units, and API call volume can scale with business growth in ways that are hard to predict at migration design time. Architects should build cost governance into the architecture itself: tagging integration flows by business process for cost attribution, setting consumption alerts, and periodically reviewing whether custom side-by-side extensions could be retired in favor of newly released standard capabilities (a recurring theme in clean core strategies, since SAP continues to extend standard scope over time). Roadmap evolution: A migration architecture should explicitly plan for known future events: SAP mainstream maintenance timelines for the chosen release, planned upgrades to public cloud quarterly releases, and expansion of scope (e.g., adding new countries, new BTP-based innovations, or additional legacy system decommissioning waves). Architecture decisions made for expedience during migration (e.g., temporary point-to-point interfaces to hit a go-live date) must be tracked as technical debt with an owner and target remediation date, not left undocumented. Deployment differences: Private cloud and on-premise customers control their own upgrade cadence and have more latitude to defer roadmap items, but they also carry more operational burden (patching, HANA administration). Public cloud customers receive mandatory periodic updates, meaning the roadmap must include regression testing cycles aligned to SAP's release calendar rather than a customer-chosen schedule. BTP-based extensions in either model require their own lifecycle tracking, since BTP services themselves evolve independently of the core ERP release cycle. Architects should document these differing cadences explicitly rather than assuming a single unified upgrade cycle across all components, since this is a common source of unplanned test cycles and post-update incidents.
Real project scenario
Twelve months after a private cloud S/4HANA conversion, a company found that three side-by-side BTP extensions built to cover perceived functionality gaps duplicated capability that had since become standard in a subsequent release. Because no one owned periodic review of the extension inventory against clean core principles, the extensions kept running, consuming BTP capacity and requiring separate patching, until an architecture review during a cost audit flagged them for retirement, freeing budget and reducing the support surface.
Common mistakes
ā¢ Treating go-live as the end of the migration architecture effort rather than the start of an operating phase ā¢ Leaving ownership boundaries between core ERP, integration middleware, and BTP extensions undefined, causing incident response delays ā¢ Assuming public cloud and BTP costs are fixed like traditional licensing, missing consumption-based cost growth ā¢ Not tracking migration-time technical debt (temporary interfaces, workarounds) with explicit remediation owners and dates ā¢ Applying a single upgrade cadence assumption across on-premise, public cloud, and BTP components that actually evolve on different schedules ā¢ Failing to periodically reassess side-by-side extensions against newly released standard capabilities, leading to redundant maintenance
Best practices
ā¢ Define and document operating model ownership boundaries during migration design, before go-live ā¢ Build cost attribution and consumption alerting into integration and BTP architecture from the start ā¢ Maintain a technical debt register for migration-time shortcuts with owners and remediation timelines ā¢ Align regression testing cycles to each component's actual release cadence rather than assuming uniformity ā¢ Schedule periodic reviews of custom extensions against evolving standard scope to support clean core over the long term ā¢ Ensure monitoring and runbooks reflect the real hybrid architecture, including fallback and legacy paths still in use
Interview angle
Architect interviews often probe beyond cutover mechanics into sustainability: candidates should be able to explain how they structured post-go-live ownership, how they governed clean core extensions over time, and how they distinguished cost risk in subscription-based components from fixed-cost on-premise components, since this demonstrates real operating experience rather than project-only exposure.