The bottom line
The move to S/4HANA Cloud hands the infrastructure layer to SAP and the hyperscaler, shifting the Basis role toward cloud architecture and application operations — but a real operations layer (monitoring, urgent issues, custom extensions) still stays with you or a partner.
A note for leaders weighing what their SAP technical team should look like after the move to S/4HANA Cloud — written for the people who own the budget, not the build sheet.
The views below are my own, drawn from conversations with SAP Basis architects and from years of watching technical roles evolve across the ERP ecosystem. SAP would frame parts of this differently, and I welcome that.
The role that kept the lights on
For most of two decades, the SAP Basis consultant was the technical guardian of an on-premise estate. The job lived in the data center: installing servers, operating systems, and databases; administering the underlying database — Oracle, DB2, or SQL Server — through patching, tuning, and backups; chasing performance bottlenecks; owning backup and disaster recovery; and shepherding transports from development to production.
It was indispensable work, and it was almost entirely about stability. The measure of a great Basis team was that nothing fell over. That is a defensible thing to be good at. It is also, increasingly, work that the platform vendor and the hyperscaler have taken off your plate.
What S/4HANA Cloud actually changes
When SAP moved to a SaaS model, it absorbed most of the infrastructure layer that used to define the Basis role. The servers, the database health, the patching cadence — much of that now sits with SAP and the underlying hyperscaler. The skill set does not disappear; it migrates upward into three roles that are worth naming precisely:
- The SAP technical architect (cloud) designs the cloud footprint on AWS, Azure, or GCP for scalability, availability, and security.
- The SAP solutions architect translates business needs into technical design, using S/4HANA Cloud and the SAP Business Technology Platform (BTP) to build for outcomes rather than uptime.
- The SAP cloud engineer is the hands-on builder, automating and operating the environment with Infrastructure as Code and CI/CD pipelines.
Here is the part that gets lost in the vendor narrative. "SAP manages the infrastructure" does not mean operations vanish. A real layer of support stays with you or your partner: application-level monitoring that catches a failed financial-close job before the controller does, urgent issues that require deep knowledge of your specific configuration, and the care and feeding of the custom extensions that make your business yours. That layer is precisely where a Basis professional, re-skilled toward application operations, becomes more valuable than ever — because it blends technical depth with business context that a generic cloud SRE does not have.
Why this matters above the IT line
For a CIO or CFO, the interesting question is not "what does my team do all day" — it is "what am I paying for, and what is it producing." The shift from custodian to builder changes the answer in three concrete ways.
Capacity is freed, not eliminated. When the team is no longer consumed by routine maintenance, that capacity can move to work the business can feel: a mobile app for the sales team, an AI-assisted forecast, an integration that closes a manual gap. The constraint stops being headcount and starts being how you prioritize.
IT spend gets a clearer line to outcomes. The Solutions Architect role exists to ensure technology serves a business purpose. Done well, it creates a traceable link from investment to result, which is exactly the accountability a CFO wants before approving the next phase.
The cost shape changes. Moving to cloud converts large upfront hardware capital into a predictable operating subscription. That is a real financial-flexibility gain — and it also raises a discipline question. A subscription that quietly grows every year is not automatically better than the capital line it replaced. The win only lands if the work underneath the subscription is being measured and reduced over time, not simply re-papered as OpEx.
Clean Core is the operating model, not a slogan
The strategy that makes all of this hang together is SAP's Clean Core principle. The old habit was to modify SAP's core code to fit the business, which produced a fragile system where every upgrade became a large, risky, expensive project. Clean Core inverts that: keep the S/4HANA Cloud core as standard as possible and build customizations side-by-side on BTP.
That principle reshapes the new roles directly. It pushes the Solutions Architect to design extensions through APIs and cloud services instead of disruptive modifications, and it makes the Cloud Engineer a BTP specialist who builds and integrates the external applications that differentiate the business. The payoff is that upgrades become routine, vendor-managed non-events, and the team's energy redirects toward continuous improvement on a core that stays stable, secure, and current.
The discipline this demands is underrated. Clean Core only holds if someone is continuously policing what lands in the core versus what belongs in BTP. Left unwatched, "side-by-side" quietly becomes "in-line again," and you are back to fragile upgrades within a few release cycles.
What I would actually do with this
If you run SAP and you are somewhere on the road to S/4HANA Cloud, the practical moves are not exotic:
- Re-skill before you re-hire. Your strongest Basis people already understand your estate. Most of the value in a Cloud Engineer or application-operations role is the business context they carry; the cloud tooling is the part you can train. Treat attrition here as a cost, not a cleanup.
- Define who owns the operations layer that remains. Application monitoring, urgent issue handling, and custom-extension care do not belong to SAP. Decide deliberately whether they sit in-house or with a partner — and make sure that layer is staffed by people who know your processes, not a generic queue.
- Measure the repeatable work, then compress it. The justification for moving capacity off maintenance is that maintenance shrinks. Instrument it. If the manual, repeatable operational work is not measurably declining year over year, the cloud model is holding cost flat at best, not compressing it.
- Govern Clean Core as an ongoing function. Make adherence a standing review, not a one-time migration checkbox.
The takeaway
The SAP technical role is not disappearing — it is moving up the value chain, from guarding a server room to building on a platform. For the economic buyer, that is good news only if it is managed deliberately. The cloud takes work off your plate; whether it takes cost off your books depends entirely on whether the operations layer that remains is measured, owned, and steadily made smaller. Treat the move as a chance to compress what you spend on keeping the lights on, not just to relabel it.
Analysis by Ravi Madhavan. Originally published on LinkedIn. Allari runs the ERP production-support layer for JDE, SAP, Oracle Fusion, and NetSuite estates — owning the application-operations work that remains after the move to cloud, measuring it, and finding where repeat work can be automated.
