S/4HANA navigation path: Standard project support during and post go-live

SUMMARY: Migrating to SAP S/4HANA is not a single event; it is a sustained operational shift. The journey depends heavily on maintaining stability during the transition and establishing robust support operations once the new system is live. This blog – the seventh in our S/4HANA blog series – is your comprehensive guide to the standard support items required during an S/4HANA migration, the complexities of dual maintenance, and the critical differences between supporting Cloud and on-premises environments.

Navigating the dual maintenance phase

During the conversion process, most organisations run a dual maintenance setup. Your Business as Usual (BAU) legacy systems – typically ECC – remain fully live and operational, while parallel S/4HANA environments are built and tested alongside them. You must support both environments simultaneously until the final cutover, where the newly converted S/4HANA system officially takes over BAU operations.

Operating in dual maintenance introduces specific risks and demands highly controlled procedures:

• Watertight retrofit processes: Any functional changes, test incidents, or hotfixes applied to the live BAU system must be meticulously mirrored (retrofitted) in the S/4HANA build environment. Failure to do so results in system differences, missing transports, and critical business functions absent at go-live.
• Transport request (TR) management: Before moving deeply into the S/4HANA conversion phase, Basis teams must close and migrate all near-completed Transport Requests to reduce technical conflicts.
• Business outage management: At the point of cutover, the business will face an outage window. Support teams often leverage techniques like Near Zero Down Time (NZDT) to limit this outage by dividing data loads into multiple increments.

Standard project support items: during and post go-live

Whether you are in the thick of the migration or settling into your post-go-live reality, standard support items generally overlap with traditional SAP environments – but S/4HANA introduces new nuances that demand attention.

• System maintenance, upgrades, and patching: With S/4HANA, patching and upgrades are dictated by your deployment model. However, maintenance now heavily involves safeguarding the ‘Clean Core’ – avoiding alterations to the core ERP code and ensuring that standard system updates will not break your customised processes.
• Basis and functional work: Basis teams are critical during the transition. Their tasks include applying necessary SAP Notes to the legacy ECC server to prepare for migration and performing full backups of the production system to secure a fallback point. Post-go-live, Basis teams must adapt to managing the in-memory SAP HANA database, requiring new skills in HANA architecture and hardware management.
• Standard system jobs: Background jobs that ran effortlessly in ECC must be reviewed. S/4HANA operates in real-time, and some traditional batch jobs (like asset depreciation) are replaced by real-time functionality. Teams must perform a detailed analysis to identify CPU-intensive transactions or long-running background jobs that are no longer relevant – or could cause unwanted side effects in the new environment.
• Third-party application and integration: S/4HANA acts as a digital core connecting to numerous satellite applications (e.g., Ariba, SuccessFactors, or non-SAP software). Support teams must focus heavily on hardening these interfaces to prevent unauthorised access to sensitive data and ensure smooth data flow across the ecosystem.
• Transports and system configuration changes: Because of the dual landscape, transport management requires strict governance. You must secure the transport management of HANA views and Fiori Apps to avoid erroneous changes to program code. A Senior Project Management Office (PMO) should enforce strict approval gates for any proposed system configurations or customisations.
• Resource adjustments and monitoring: A successful transition requires sustained involvement from IT, finance, and data teams. Support leaders must plan for workforce capacity and backfills so that day-to-day operations and critical tasks – like the financial close – are not disrupted.
• Project work and development: Support teams must analyse custom code (Z-code) using the ABAP Test Cockpit (ATC) to check compatibility. Development teams must shift their mindset to the SAP Business Technology Platform (BTP). Any new project work or unique extensions should be built on BTP rather than inside the ERP, utilising approved APIs to prevent accumulating technical debt.

Cloud vs. on-premises support: key differences

When transitioning to SAP S/4HANA, your support model diverges significantly depending on whether you choose Cloud or On-premises. The main differences centre around infrastructure management, upgrade cycles, and extensibility.

Infrastructure and hosting responsibilities

• On-premises: You have maximum control, but this comes with the highest management burden. Your internal IT teams (or a managed service provider) are entirely responsible for supporting the hardware, operating system, database, and application layers.
• SAP S/4HANA Cloud Public Edition: A multi-tenant SaaS model hosted, managed, and maintained entirely by SAP. SAP handles all infrastructure support and Basis tasks.
• SAP S/4HANA Cloud Private Edition: A single-tenant SaaS model. While you gain more control and a dedicated instance, the infrastructure is still managed and maintained by SAP (on a chosen hyperscaler like AWS, Google Cloud, or Azure), removing the day-to-day hardware support burden from your internal teams.

Upgrades and patching cycles

• On-premises: Your organisation dictates the timeline for upgrades and patches. While this offers stability and control, it can lead to massive, disruptive upgrade projects every few years if the system falls behind.
• Cloud: Cloud environments operate on continuous innovation cycles. The Public Edition receives mandatory, automatic updates (quarterly or semi-annually), meaning your support team must focus on testing and adopting new features rather than executing the technical upgrade itself. The Private Edition allows more flexibility in scheduling updates, but you are still bound to a subscription model and regular update cadence.

Customisation vs. configuration (the ‘Clean Core’)

• On-premises: Support teams have full access to modify the core ABAP code, enabling highly tailored processes. However, this creates immense support challenges during future upgrades.
• Cloud: SAP strictly enforces the ‘Clean Core’ methodology. In the Public Edition, there is no direct core customisation – only configurability. All functional extensions must be built side-by-side using BTP. Cloud support therefore shifts away from deep ABAP code troubleshooting and toward managing APIs, BTP integrations, and standardised best practices.

After cutover: what changes?

Support requirements shift significantly after a system cutover, transitioning from migration-focused tasks to system stabilisation, continuous improvement, and adapting to new real-time processes. Here is what to expect:

• Handling initial disruptions (hypercare): Immediately following cutover, support operations must be prepared for ‘hypercare’ scenarios. Hypercare needs to run through the first month-end, to monitor these once-a-month processes, as many other interfaces and process get tested live for the first time. Information flow may be disrupted, and teams might need to manage reporting delays or revenue reconciliation discrepancies that require significant incremental manual work. The priority is rapid elimination of these defects and manual workarounds.
• Adapting to real-time processes and new IT controls: The shift to S/4HANA alters fundamental IT and business controls. Traditional batch jobs are often replaced by real-time functionality, meaning support teams must adjust related user controls and procedures. General IT controls – including backup and restore processes, change management, and interface integrations – all need updating to align with the new platform.
• Transitioning away from Systems Integrators (SIs): Post-cutover, the goal is to return to business as usual. Your internal support team must leverage their newly developed S/4HANA architecture skills to manage the environment, enabling the organisation to gradually reduce its dependence on external SIs.
• Leveraging Managed Services/TechOps: Organisations may also shift their support strategy to utilise post-go-live managed services. These services provide ongoing application management, Basis and platform support, and further modernisation initiatives backed by defined Service Level Agreements (SLAs). We also have a dedicated team to facilitate and consult you on your Managed Services requirements.

The role of SAP BTP after migration

Migrating to S/4HANA completely redefines how your business uses the SAP Business Technology Platform (BTP). If S/4HANA is the new, high-performance engine of the business, BTP is the flexible chassis that allows you to bolt on custom features, AI capabilities, and third-party integrations – without ever voiding the engine’s warranty.

What is SAP BTP?

At its core, SAP BTP is a comprehensive collection of cloud, analytics, AI, machine learning, application development, and integration tools. It is designed to act as the unified technological foundation for enterprise mission-critical business processes.

How S/4HANA enhances BTP use cases

• Enabling the ‘Clean Core’ strategy (decoupled customisation): In legacy SAP ECC environments, unique business requirements were met by writing custom ABAP code directly inside the core ERP system. Over time, this created massive technical debt, making upgrades incredibly difficult and risky. When you migrate to S/4HANA, BTP becomes the SAP-sanctioned platform for building all customisations and extensions outside of the core ERP. S/4HANA and BTP communicate through well-defined APIs and the SAP Integration Suite. Because the custom code lives on BTP instead of inside S/4HANA, standard system updates and patches no longer break your custom applications.
• Accelerated innovation and continuous delivery: Because S/4HANA relies on BTP to handle custom extensions, it drastically speeds up the innovation lifecycle. Development teams can build, test, and deploy new functionalities on BTP without altering the core ERP. This decoupled approach simplifies continuous delivery models and allows organisations to implement innovations much more quickly – a major advantage for digital transformation.
• The gateway to AI and advanced technology: S/4HANA provides the simplified digital core, but BTP is the platform that unlocks next-generation technology. Migrating to S/4HANA and adopting BTP allows your business to seamlessly integrate embedded AI (like SAP’s AI assistant, Joule), predictive analytics, and process automation into daily workflows. Enterprises that ignore the Clean Core/BTP strategy are accumulating technical debt that will ultimately block their ability to adopt AI in the future.
• Simplified ecosystem integration: Modern enterprises rarely run on SAP alone. S/4HANA relies heavily on BTP to serve as the integration layer between the core ERP and other SAP cloud products (like Ariba or SuccessFactors) as well as third-party, non-SAP applications.