Your migration code is written, your budget is spent - but the real risk begins 30 days before go-live.
Most S/4HANA failures are not coding failures. They are decision failures. The Horváth study of 200 SAP-using organizations found that more than 60% exceeded budget, schedule, or both - and only 8% completed the transformation on the original timeline. A 2024 ASUG survey reinforced that finding: 49% of organizations already live on S/4HANA reported costs above their initial budgets, with consulting fees representing the single largest source of overruns.
If you are a CIO who has approved the migration, selected a Brownfield or Greenfield path, and watched the implementation progress, you are not finished. You are entering the phase where projects actually fail. The go-live window - the 30-to-90-day period before and after cutover - is where organizational alignment, executive judgment, and pre-approved protocols determine whether the business operates normally on Day 1 or spends six months in remediation.
This checklist is not a technical testing guide. Your team handles testing. What follows are the 10 executive decisions that no one will make without you - decisions that determine business continuity, total cost of ownership, user adoption, and the architecture that your organization runs on for the next decade.
Decision 1: Finalize Your Clean Core vs. Custom Code Strategy
Bottom line: The custom code you carry into S/4HANA is the custom code you will pay to maintain, test, and defend through every future upgrade.
SAP ECC environments accumulate years of custom ABAP code. That code addressed real business requirements in an era when the alternative was rigid standard functionality. The problem is structural: custom modifications embedded in the ERP core create upgrade blockers, increase regression testing cycles, and prevent native AI adoption. Every quarter that SAP releases S/4HANA updates, a heavily modified core requires expensive re-testing of thousands of objects before those updates can go live.
The migration is your one opportunity to change this. The decision is not binary. Under SAP's formalized A-through-D extensibility classification framework, custom developments range from fully upgrade-safe Level A extensions (built on ABAP Cloud or side-by-side on SAP BTP) to Level D violations - direct core modifications that carry severe upgrade risk and must be placed on a retirement timeline. Every custom object currently in your ECC environment needs to be classified into one of three dispositions before go-live: retire, remediate, or re-implement on BTP.
The business cost of technical debt
Every custom object you carry into S/4HANA represents a liability, not an asset. The maintenance cost compounds over time - each new implementation partner must learn it, each system upgrade must account for it, and each new SAP AI capability must work around it. Enterprises that adopted clean BTP extensions early are now running faster upgrade cycles and spending materially less on annual system maintenance. The migration project is the natural forcing function for this conversation. Once you are live, the appetite to revisit custom code drops to near zero.
Leveraging SAP BTP for side-by-side extensibility
Custom logic that cannot be achieved through standard S/4HANA functionality belongs on SAP Business Technology Platform - not in the core. BTP extensions using SAP Build Apps, the SAP Integration Suite, or the Cloud Application Programming (CAP) model survive upgrades independently because they are decoupled from the ERP core. The S/4HANA system functions as the system of record; BTP functions as the system of innovation. This architecture is not aspirational - it is now the operational standard for organizations that intend to activate SAP Business AI, Joule, and predictive analytics without structural obstruction.
As a CIO, your pre-go-live decision is not technical: it is strategic. How much technical debt are you willing to carry forward, and what is the board-level justification for that choice? Document the answer before cutover.
Decision 2: Confirm Data Archiving and Migration Cutoffs
Bottom line: Not all data needs to move. The data that moves unnecessarily increases system complexity, migration risk, and long-term TCO.
Data volume is one of the most underestimated cost drivers in S/4HANA migration. Organizations that attempt to migrate every historical record - decades of invoices, purchase orders, and legacy material master entries - extend timelines, inflate cloud hosting costs, and introduce data quality problems that surface only after go-live. The Horváth study cited underestimated data migration phases as one of the primary causes of project overruns.
This is an executive decision because it requires deliberate trade-offs between legal compliance, operational necessity, and financial discipline.
Data volume management frameworks
Your migration team can identify what is technically possible to move. Your job is to define what is operationally necessary. In most S/4HANA migrations, the practical answer involves migrating open items and a defined window of historical transactional data - typically 2-3 fiscal years, depending on industry - while archiving older records in a compliant long-term data repository accessible outside the core system. This approach controls system footprint, reduces migration runtime, and keeps the new environment clean from Day 1.
Legal compliance vs. operational necessity
Financial records, tax documentation, and audit trails carry legally mandated retention periods that vary by jurisdiction. In India, the Companies Act mandates book retention for a minimum of eight years. UK entities face similar obligations under HMRC regulations. The decision is not whether to retain this data - you must - but whether it needs to reside inside the active S/4HANA system or in a separate compliant archive. The right answer for most organizations is archiving with indexed search access. Agree on this boundary with your legal, finance, and compliance leaders before the data migration team begins production cutover preparations.
Decision 3: Validate Business Continuity and Rollback Protocols
Bottom line: Go-live is not a point of no return - unless you have failed to define exactly when and how you would revert.
Every S/4HANA go-live carries a rollback risk window. For most migrations, that window closes somewhere between 48 and 96 hours after cutover, after which the volume of new transactional data in S/4HANA makes reverting to ECC operationally impractical. Before that window closes, your organization needs explicit, pre-authorized protocols for two scenarios: a controlled go/no-go gate and an emergency rollback.
The majority of go-live failures are not discovered in the first hour. They surface in the first week, when business-critical processes - order-to-cash, procure-to-pay, month-end close - encounter conditions that UAT did not replicate. The 65% of organizations that reported severe-to-very-severe quality issues after go-live in the Horváth 2025 study were not surprised by bugs. They were surprised by business-process failures that testing did not anticipate.
Defining the point of no return
Work with your program director and integration partner to define, in writing, the specific system and business conditions that trigger a rollback decision. Who has the authority to call it? Under what technical thresholds - transaction failure rates, system performance benchmarks, critical integration errors - does rollback become mandatory versus discretionary? This document must exist before cutover weekend, and it must be signed.
Communication templates for downtime
Customers, suppliers, employees, and regulators do not tolerate operational silence during system outages. Pre-draft communication templates - for internal stakeholders, key suppliers, and customer-facing teams - that explain the nature of the cutover, the expected downtime window, and the escalation path if issues persist beyond the planned window. Silence is interpreted as loss of control. Pre-authorized communications are interpreted as competence.
Decision 4: Approve the Integration Landscape and API Strategy
Bottom line: S/4HANA integrations break in predictable ways. The executive decision is whether you have mapped every critical path dependency before they break in production.
S/4HANA operates on a different data model than ECC. Interfaces, IDOCs, and RFC-based integrations that worked in ECC do not automatically translate. Third-party systems - CRM platforms, warehouse management systems, manufacturing execution systems, e-commerce platforms, banking interfaces - each carry integration risk at cutover.
The 2025 SAPinsider Benchmark Report noted that SAP Integration Suite adoption jumped from 33% to 46% in a single year, reflecting how quickly organizations are recognizing the API-first imperative. That shift is not cosmetic. Direct database calls and legacy RFC integrations that bypass the API layer create hidden dependencies that break when S/4HANA's schema changes - and schema changes are the mechanism by which SAP delivers innovation.
Mapping critical path integrations
Before go-live, your integration landscape must be documented to the process level, not just the system level. The question is not "does System X integrate with S/4HANA?" - it is "which specific transactions in System X depend on which specific APIs in S/4HANA, and what is the business impact if each fails?" Tier 1 integrations - those that block revenue or regulatory reporting on Day 1 - require individual sign-off and contingency protocols. Tier 2 and Tier 3 integrations can be addressed in the first 30 days post-go-live.
SAP Integration Suite utilization
For organizations running RISE with SAP or adopting BTP-based architecture, SAP Integration Suite is the recommended mechanism for managing third-party and legacy connections. It provides pre-built adapters, API lifecycle management, and monitoring capability that reduces the manual overhead of maintaining point-to-point integrations. If your current integration architecture still relies on direct RFC or BAPI calls, your pre-go-live decision is whether to remediate those before cutover or accept the technical risk and remediate post-go-live. Accept it only if your contingency protocols can absorb a failure.
Decision 5: Authorize User Access and Role Mappings
Bottom line: On Day 1 of go-live, every employee who cannot perform their job because of an access issue is a direct operational cost - and a segregation-of-duties failure is a compliance event.
Role mapping between ECC and S/4HANA is not a one-to-one translation. The Fiori UX model introduces a tile-based, role-specific interface that departs fundamentally from the transaction-code model of ECC. Users who could navigate ECC through memorized T-codes require active training and correctly configured Fiori catalogs before go-live. Access errors on Day 1 are not just helpdesk tickets - they stop procurement, halt approvals, and freeze month-end processes.
The more serious risk is segregation of duties. S/4HANA migrations that inherit ECC role structures without review frequently carry SoD violations into the new environment. This is a compliance exposure that auditors - internal and external - will find in the first post-go-live review.
SAP GRC alignment
If your organization uses SAP GRC (Governance, Risk, and Compliance), the role migration must be validated through GRC's access risk analysis module before go-live - not after. This requires coordination between your basis team, the security architect, internal audit, and line-of-business process owners who can confirm that role assignments match actual job functions. This is a business decision, not a technical one: the business owns the definition of who is permitted to do what.
Zero-trust principles in S/4HANA
S/4HANA's API-first architecture enables a more granular access control model than was practical in ECC. Pre-go-live is the moment to apply zero-trust principles: least-privilege access as the default, explicit justification required for any access grants beyond that, and a 90-day post-go-live access review built into the project plan. Establishing this discipline at go-live is materially easier than retrofitting it 12 months later.
Decision 6: Execute Hypercare and Support Resource Allocation
Bottom line: The 30-to-90 days after go-live will surface more issues than any prior phase of the project. The question is whether your support model is designed for that volume or designed for steady-state operations.
Hypercare is the structured high-support period that bridges go-live and normal operations. During hypercare, issue volume is typically 5 to 10 times higher than steady-state. Users encounter the new interface for the first time in production conditions. Integrations that passed UAT encounter transaction combinations that testing did not cover. Reporting that looked correct in the test environment produces unexpected results against live data.
Organizations that treat hypercare as a reduced-effort phase - releasing implementation consultants immediately after go-live - consistently report longer remediation periods and higher post-go-live costs. The Horváth study found that weaknesses in project management and underestimated testing phases were the two most commonly cited causes of plan deviation. Hypercare is where that debt is collected.
Defining hypercare vs. steady-state support
The hypercare model requires explicit resource commitments, not informal agreements. Specifically: who is providing Level 1, 2, and 3 support, what are the SLAs for each priority tier, what is the escalation path to the implementation partner, and when does the transition to Application Management Services (AMS) steady-state begin? ITChamps' Application Management Services are designed to take on this handoff - providing continuous post-go-live support across functional areas without requiring organizations to retain full implementation teams beyond the hypercare window.
War room protocols and escalation matrices
In the first two weeks post-go-live, your team needs a structured incident-management process, not informal communication. A war room - physical or virtual - with defined issue triage, priority assignment, and resolution tracking reduces the chaos that otherwise characterizes the early post-go-live period. The escalation matrix should be pre-agreed: who is the first call for a critical finance issue, who authorizes emergency configuration changes, and which issues require vendor escalation to SAP? Documenting these paths before go-live saves hours when the system is live and the pressure is on.
Decision 7: Align Organizational Change Management (OCM) Milestones
Bottom line: S/4HANA is the most sophisticated ERP system your organization has ever deployed. If your people cannot use it effectively from Day 1, the technology investment does not generate returns.
The Horváth 2025 study identified organizational resistance as a primary driver of migration failures, with 49% of respondents citing business-process changes as the single largest migration challenge. Technology adoption without behavior change is not adoption - it is installation. And an installed system that people work around rather than work with generates no ROI.
The OCM failure mode in S/4HANA migrations is predictable: change management is treated as a training program delivered in the final weeks before go-live, rather than as a continuous organizational alignment process that began at project initiation. By the time users are trained, the go-live date is immovable, and resistance has had months to calcify.
Executive sponsorship visibility
User adoption rates correlate directly with visible executive engagement. When the CIO is seen using the system, attending training, and communicating the strategic rationale for the migration, adoption signals follow. When the only communication is from the IT project team, the implicit message is that this is an IT initiative - and IT initiatives are optional for business users.
Before go-live, your OCM decision is specific: which executive communications will you personally deliver, on which schedule, and to which employee segments? A single all-hands communication on go-live week is not a sponsorship model.
Targeted training for Fiori adoption
SAP Fiori represents a departure significant enough to require targeted intervention, not just awareness. Power users - the individuals who process high transaction volumes in Finance, Procurement, and Supply Chain - require structured Fiori training on their specific role-based tiles. Key users in each business area need to be certified as first-line support contacts before go-live. The training investment made in the 60 days before cutover determines whether Day 1 productivity is 60% of normal or 90% of normal. That difference in operational throughput is measurable in revenue terms.
Decision 8: Finalize Testing Sign-Off and Defect Triage Thresholds
Bottom line: You will never reach a zero-defect state before go-live. The executive decision is defining which defects prevent go-live and which ones do not.
Testing phases in S/4HANA migrations routinely identify more defects than the team has time to resolve before the go-live window. The organization then faces a choice it has not pre-authorized: delay go-live, or proceed with known defects and accept post-go-live remediation risk. Without pre-defined thresholds, this decision is made under deadline pressure by people who lack the authority or the business context to make it well.
The go/no-go decision is a business decision, not a testing decision.
Business scenario testing vs. unit testing
The unit testing that your technical team conducts validates that code executes correctly. Business scenario testing - end-to-end process walkthroughs covering order-to-cash, procure-to-pay, record-to-report, and plan-to-produce - validates that the system supports the way your business actually operates. The latter is what matters for Day 1 continuity. Before go-live, confirm that your quality assurance plan distinguishes between the two, and that business scenario test sign-off is the governing criterion for the go/no-go decision.
Setting acceptable risk thresholds
Pre-define, in writing, the defect categorization that governs go-live eligibility. A standard framework classifies defects as critical (blocks a core business process and has no workaround), high (significantly impacts a core process but has a documented workaround), medium (impacts secondary processes), and low (cosmetic or peripheral). Zero open critical defects is typically the non-negotiable threshold. The threshold for high defects, and the conditions under which they can be accepted with a committed remediation date, requires your explicit sign-off.
Decision 9: Validate Cloud Infrastructure and Performance Benchmarks
Bottom line: An S/4HANA system that meets functional requirements but cannot process your peak transaction volumes on time is a system that will fail your business at its most critical moments.
Infrastructure and performance are the testing categories most likely to be compressed when project timelines run tight. The consequence surfaces predictably: go-live during a period of normal transaction volume proceeds without incident, and the system degrades or fails at month-end close, during peak order periods, or at annual financial reporting cycles.
The hosting decision - whether RISE with SAP managed private cloud, hyperscaler (AWS, Azure, GCP), or on-premises - carries SLA obligations that must be stress-tested, not assumed.
Stress testing for peak business cycles
Before go-live, your performance validation must simulate the specific transaction profiles of your peak business periods, not average load. For a retail organization, that means simulating promotional sales volumes. For a manufacturing company, it means quarter-end production scheduling. For a financial services firm, it means month-end close processing. Performance benchmarks that pass under average load and fail under peak load are not benchmarks - they are risks deferred to the worst possible moment. Require documented stress test results that demonstrate system performance at 150% of peak load before signing off on go-live readiness.
Network latency checks
For organizations deploying S/4HANA to geographically distributed user populations, network latency between user locations and the hosting environment is a Fiori performance variable that often goes unmeasured until after go-live. Fiori is a browser-based interface; round-trip latency above 200 milliseconds degrades user experience meaningfully. Before go-live, confirm that network performance has been validated across all major user locations, not just the primary headquarters, and that performance does not degrade under concurrent load from distributed offices.
Decision 10: Map Post-Migration AI and Innovation Roadmaps
Bottom line: Clean core is not a migration methodology - it is the prerequisite for everything SAP is building next. The value of the migration depends on what you do with the foundation it creates.
SAP's product investment is concentrated in Business AI - Joule, embedded analytics, intelligent automation, and predictive capabilities delivered through S/4HANA and BTP. These capabilities require standardized data models, clean processes, and BTP-native integrations. An organization that migrated to S/4HANA but retained a heavily modified core and legacy integration architecture cannot activate them without additional remediation. The architecture decision you make at go-live determines your AI-readiness for the next three to five years.
<cite index="1-1">As of 2025, 61% of organizations plan to use SAP BTP as part of their S/4HANA investment, up from 57% in 2024 - signaling that BTP-based innovation is no longer an optional add-on but an expected component of the S/4HANA architecture.</cite>
Enabling SAP Business AI
SAP Business AI capabilities - including Joule, the conversational AI copilot embedded across S/4HANA - require clean, structured master data and standard process flows to function accurately. Duplicate vendor records, inconsistent material classifications, and non-standard process variants generate AI outputs that are unreliable. Before go-live, the question for your team is whether the data quality and process standardization achieved through the migration is sufficient to activate AI capabilities in the first 12 months post-migration, or whether additional data governance work is required.
ITChamps' proprietary 3PS (Third-Party Support and Strategic Advisory) framework is designed precisely for this transition point. By accelerating clean-core architecture adoption and reducing unnecessary customization during migration, organizations working with ITChamps have realized migration timelines up to 30% faster than standard project estimates, while arriving at a foundation that is AI-extensible from Day 1.
Data structuring for Joule and predictive analytics
Joule operates on a natural language interface that queries structured S/4HANA data. Its outputs are only as useful as the data structures underlying them. Before go-live, confirm that master data governance - vendor master, customer master, material master, cost center hierarchies - meets the quality standards required for AI-assisted decision-making. This is not an abstract IT standard. It is a board-level question: will the AI insights your executives expect to generate from S/4HANA be grounded in data that is accurate, complete, and governed?
Map the specific AI and automation use cases your business intends to activate in Year 1 post-migration. Assign ownership. Define the data readiness requirements for each. Confirm that the go-live architecture supports them. This is how the migration investment becomes a business transformation rather than a system upgrade.
The Go-Live Decision Is Yours
Your implementation team can tell you when the system is technically ready. Only you can determine when the business is ready.
The 10 decisions in this checklist are not checklists for your project manager - they are ownership decisions for the CIO, CFO, and executive leadership team. Each one carries a risk if left to default, and each one creates a defensible position if made deliberately and documented.
If your organization is approaching go-live and has not addressed these decision points, the time to act is now - not after the cutover weekend.
ITChamps offers an S/4HANA Go-Live Readiness Assessment designed specifically for this phase: a structured review of your pre-go-live decision posture across the 10 dimensions above, delivered in two to three weeks, with a prioritized action plan and executive-level readiness report. Engage your ITChamps advisory team before the cutover date is locked.
Frequently Asked Questions
What is the most common reason S/4HANA migrations miss their go-live dates?
The Horváth 2025 study of 200 SAP-using organizations identified scope expansion, weaknesses in project management, and underestimated testing and data migration phases as the top drivers of delayed go-lives. Only 8% of organizations completed their S/4HANA transformation on the original schedule. The root cause is typically not technical: it is the absence of pre-defined executive decisions on scope boundaries, defect thresholds, and resource allocation during the critical pre-go-live window.
How long should the hypercare period last after S/4HANA go-live?
For most mid-to-large enterprise implementations, a structured hypercare period of 60 to 90 days is appropriate, with the first 30 days being the highest-intensity period for issue resolution. The transition from hypercare to steady-state AMS support should be governed by measurable criteria - open critical defect count, helpdesk ticket volume, and business process stability benchmarks - rather than a fixed calendar date.
What does "clean core" mean in practice for a business leader?
Clean core is the principle of keeping the S/4HANA ERP system as close to SAP's standard configuration as possible, with business-specific customizations built on SAP BTP as independent extensions rather than modifications to the core. For a business leader, it means lower ongoing maintenance costs, faster adoption of SAP's quarterly innovation releases, and a system architecture that can activate native AI capabilities - like Joule - without requiring additional remediation work.
How should a CIO frame the S/4HANA migration ROI conversation for the board?
The migration ROI argument has two dimensions. The defensive case is risk avoidance: SAP mainstream maintenance for ECC ends in 2027, and organizations that extend maintenance pay a premium while receiving no new security patches or functional enhancements. The offensive case is capability acquisition: S/4HANA and BTP unlock real-time analytics, AI-assisted planning, and automation capabilities that ECC cannot support. The CIO's job is to quantify both - the cost of staying, and the capability value of moving - using the specific process improvement opportunities identified during the migration project. Actual TCO savings and migration outcomes vary based on existing system architecture and implementation scope.
What is the right approach to managing SAP GRC and access governance at go-live?
Role mapping for S/4HANA should not inherit ECC role structures without review. The Fiori-based UX model requires role-based tile configurations that differ from ECC transaction-code access patterns, and the migration is the natural moment to apply least-privilege access principles and clear segregation-of-duties controls. GRC access risk analysis should be completed before go-live - not scheduled as a post-go-live activity - so that any SoD violations identified in the new role structure are remediated before the system goes into production.