Every few weeks a programme owner asks me a version of the same question: we have moved to RISE with SAP, so can we stop staffing SAP Basis? It is a reasonable thing to ask. RISE is sold as a managed service, and managed services are supposed to absorb the plumbing.

There is a documented answer, and it does not come from a vendor brochure. SAP publishes a roles and responsibilities document covering SAP S/4HANA Cloud private edition, SAP ERP private cloud edition and SAP Business Data Cloud. The current version is dated July 2026, and it sets out five service categories rather than the two-way SAP-versus-customer split most briefs assume. One of those five decides your headcount.

TL;DR: RISE did not delete the SAP Basis workload; it put a price on it. SAP's responsibility document defines five service tiers, and the decisive one, Packaged Services, covers work the customer performs by default unless it pays SAP to take it. Role administration, ongoing transport operation, single sign-on and identity integration, and note testing all sit on your side of the line. Staff it or buy it back, but budget for it either way.

Complexity slows migrations first, and people second

Ask the German-speaking SAP user group why transformation timelines slip and people are named alongside the technical causes. In DSAG's 2026 investment report, chairman Jens Hungershausen points first to the complexity of members' system landscapes: companies "simply need this time", and he reads that as a reflection of reality in IT departments. Then he adds a second group of causes: "Auch Fachkräftemangel, parallele Transformationsprojekte und begrenzte Budgets führen dazu, dass Zeitpläne nach hinten geschoben werden – selbst wenn dies höhere Wartungskosten zur Folge hat." Skills shortage, parallel transformation projects and limited budgets also push timelines back, even when the delay means paying higher maintenance costs.

The shortage is a second-order cause in that list. It still sits next to a complexity that only people can unpick.

The same report shows an estate caught mid-move. 54% of respondents still run SAP ECC or Business Suite, down from 68% in 2024, while 56% now run S/4HANA on-premise, up from 44%; the totals pass 100% because plenty of members run both at once, which is the point. Among the ECC holdouts, 37% plan to migrate by the end of 2027, almost half by the end of 2030 and a further 4% by the end of 2033. End of maintenance ranks as a top-five challenge for 63%. The survey covers 198 respondents polled between 8 December 2025 and 21 January 2026, with 73% in Germany, 12% in Switzerland and 10% in Austria.

Read those findings together and the picture is a market running two technical worlds at once while short of the people to close the gap.

SAP's contract has five service tiers, not two

SAP's responsibility model has five categories, and your service fee only pays for one of them. SAP's roles and responsibilities document, version 07.2026, defines them in its own words:

• Standard Services are "included as part of the Standard Services, covered by the Service Fee and performed by SAP".
• Optional Services are not covered by the standard fee, "may be elected by customer", are "subject to additional service fees", "must be specifically contracted for and itemized in the customer's contract", and "can only be performed by SAP".
• Additional Services are "one-off tasks/services" outside the other tiers, also elective, also chargeable, and again "can only be performed by SAP".
• Packaged Services "include tasks/services that a customer can perform, but the customer may elect to have SAP to deliver", and are "subject to additional service fees as agreed in a customer's contract".
• Excluded Tasks are "those tasks/services that can only be performed by the customer".

Packaged Services is the tier that decides your hiring plan, because of one sentence an IT director should read twice: "Needs to be performed by customer if applicable and if a Packaged Service is not used." The default owner of that work is you. SAP will take it off you at a price. Excluded Tasks close the other end of the range: no line on this contract moves them to SAP.

One naming detail is worth carrying into your own reading. The same responsibility document records that the Packaged tier was "Formerly: SAP Cloud Application Services (CAS)". Guidance published before the rename still uses the CAS name, so when an integrator's deck talks about CAS scope, it is describing the Packaged tier under its old label.

SAP runs the layer beneath the application; you keep almost everything above it

SAP takes the infrastructure and hands you almost everything that touches how your organisation uses the system.

On SAP's side, Standard Services include implementing patches for system software at OS level such as the SAP kernel, and creating and maintaining the release plan for the managed landscape, including checking for SAP software updates: release version, support packages, kernel updates and DB version. That is real work and genuinely off your plate. Kernel patching and release planning used to be a meaningful slice of a classic Basis week.

Then comes the list that survives the move:

• Role administration is a Packaged Service. The responsibility matrix files "Administer roles, like role creation and role change" in the Packaged tier, which means your team does it unless you contract SAP to take it. Authorisations are the daily grind of a Basis function, and they stay with you by default.
• Transport management is scoped to a default setup. A transport, in SAP terms, is a packaged change moved from development through test into production, and the transport management system is the machinery that routes it. SAP's initial setup of that system is a Standard Service, but the wording is fenced tightly: it is "Limited to the setup of the transport management system and does not include ongoing operation of the transport management system", and the setup row itself is "Limited to a default setup. Customer specific domains or configurations not included."
• Transport operation, and every content failure, is yours. Ongoing maintenance of the transport system including transport routes sits in the Packaged tier, and SAP limits even that to "technical transport problems, not related to problems due to the content of the transports". A transport that fails because the machinery misrouted it is arguably SAP's; a transport that fails because of what is inside it is your engineer's, every time.
• Single sign-on and identity integration are Excluded Tasks. SSO design, architecture and implementation for the cloud landscape are customer-only work, as is integrating "customer Active Directory, Google IdP and other identity management". SAP notes you may engage its separate services for SSO, but nothing in this contract shifts the work.
• Note testing is yours in writing. SAP states it in one line: "Testing of implemented Notes is Customer's responsibility." Whoever applies the note, proving it left your processes intact is your job.

What survives RISE is the part of Basis that requires knowing your business: who gets which authorisation, which transport route serves which stream of releases, how identity flows in from your directory, and what regression testing means for your processes. The managed service moved the infrastructure work and left the judgement exactly where it was. In the SAP briefs that reach me, the note-testing line is the one that surprises programme owners most, because it is the cheapest to overlook and the most expensive to discover during a month-end close.

The demand runs on dated gates through 2033

The 2027 headline is the first step on a staircase, and the top step is 2033. Mainstream maintenance for the core applications of SAP Business Suite 7 runs to the end of 2027, per SAP's maintenance commitment. Optional extended maintenance then runs for three years, from the start of 2028 to the close of 2030, priced at an extra two percentage points on the maintenance basis; customers who decline it move to customer-specific maintenance. SAP has committed to maintaining S/4HANA until the end of 2040.

A further gate sits beyond that one. The SAP ERP, private edition, transition option is purchasable from 2028, with active usage running from 2031 to 2033. Systems must move to SAP ERP private edition before the end of 2030 to qualify. SAP HANA is the only supported database for it. SAP is careful about what the option is: "this is not a maintenance prolongation of SAP ERP. There are no changes for customers running on-premise SAP ERP systems after 2030."

So retire the line about SAP dying in 2027. Every one of those dates is a technical operations workstream: a database migration, a hosting move, a maintenance-tier decision, then a transition window with its own cutover weekend. DSAG's numbers already show 4% of surveyed ECC holdouts planning against end-2033.

Clean core made SAP Basis a governance job

Custom code stayed on the customer side of the line, and it now carries a score. SAP's clean core guidance defines extension levels A to D, where Level A means "Fully compliant extensions using only publicly released and stable SAP interfaces" and Level D covers "Extensions not considered 'clean'". The stated goal is to "keep the core clean, standard, and upgrade-stable while still enabling business-specific differentiation where it counts".

That grading changes what a technical team does all week. SAP names ABAP Test Cockpit for "code-level governance" and a RISE with SAP Methodology dashboard giving "real-time insights into clean core adoption". Somebody has to own that dashboard, argue with development teams about their Level C extensions, and defend the upgrade window when the business wants a shortcut. Those developers are the same population I mapped in the senior SAP ABAP market in CEE vs DACH, and the negotiation between them and whoever guards the core is now a standing feature of the job.

Your search string lags SAP's own curriculum

SAP's current system administration curriculum has quietly dropped the word you are searching on. That curriculum describes the job like this: "SAP system administrators oversee the ongoing reliability, performance, management, and support of SAP application environments", covering tasks "ranging from application and system management to problem response and capacity planning". Read that description cold and it is Basis, in full. The word "Basis" never appears on the page.

It has not vanished from SAP entirely, and the split is the interesting part. The same July 2026 responsibility document still labels rows "SAP Basis / ABAP related" and "Pre- and Post BASIS Tasks". So the contract still says Basis while the curriculum no longer does, and candidates train on the curriculum. In the specifications I get sent the requirement almost always says Basis, while strong profiles increasingly describe themselves as SAP technical operations, system administration or S/4HANA platform engineering. A one-word search string filters out the people who trained on SAP's current material.

No credible salary benchmark exists for this role

One number I will not give you is the cost. No salary or day-rate figure for an SAP Basis hire comes from a source I would put my name to. The ones circulating in blog posts trace back to self-reported freelancer rate surveys rather than to placement data, which makes them a poor guide to what a permanent hire clears. Benchmark against the offers you lose in the market you are hiring in, because that signal is live. ABAP is the one SAP role where the published figures are at least numerous enough to triangulate, so the outliers show up as outliers; I set out the country-by-country picture there, with the caveat stated in that piece that the underlying data is self-reported too.

Sovereign cloud narrows the pool further

Regulated landscapes add constraints before skills enter the conversation. SAP says that "with a long-term investment of more than €20 billion Euros, SAP is making digital sovereignty a strategic priority", targeting "the public sector and regulated environments" (SAP's sovereign cloud investment). The published options include SAP Sovereign Cloud On-Site, described as "SAP-operated infrastructure within a customer-owned or customer-selected data center", alongside Delos Cloud for the German public sector.

For hiring, the practical effect lands on who is permitted to touch the system. Sovereign and regulated environments bring clearance, residency and on-site presence into the brief. Scope those constraints before the search opens, because in my experience they shrink a shortlist faster than the technical requirements do, and they are the hardest to relax later.

How to screen an SAP Basis hire in the RISE era

1. Map the brief onto the five categories first. Sort the recurring work in your landscape into Standard, Optional, Additional, Packaged and Excluded. Whatever lands in the last two tiers is your headcount question, and everything above it is a contract question. That exercise is where most of my SAP recruitment conversations begin, because it turns "we need Basis" into a list you can hire against.
2. Interrogate transports and role administration. Both sit largely on your side under RISE, so ask for specifics: describe a change that broke production because of the transport's contents, when the routing itself was fine, and walk me through how you rebuilt an authorisation concept after an audit finding. You are listening for a named incident and what it cost.
3. Ask for a clean-core level. What did your extensions score, and how did you move something from Level C to Level A? Candidates who have run ABAP Test Cockpit as a governance tool describe the conversations they had with developers as vividly as the findings they closed.
4. Ask what SAP's team actually handed back. For anyone who has worked inside a RISE landscape, the revealing question is which tickets came back marked out of scope, and how they found out. People who have operated the model name the boundary from memory.
5. Run the anti-sell before you open a search. If your estate is small, stable and already converted, a Packaged Service or a managed partner may serve you better than a permanent hire. Permanent capability earns its keep when you have complex authorisations, heavy custom code, several environments and a migration in flight, which is the same permanent-versus-contract split I worked through in hiring for an S/4HANA brownfield migration. And price both sides before you decide: ask your account executive what the Packaged Service line costs at renewal, then set it against a loaded permanent salary.

Common questions about hiring SAP Basis in the RISE era

Is SAP Basis dying?

No. The work moved between contract tiers and kept its volume. SAP's roles and responsibilities document assigns kernel patching and release planning to Standard Services, while role administration and ongoing transport operation sit in the Packaged tier, which the customer performs unless SAP is paid to. Meanwhile 54% of respondents to DSAG's 2026 investment report still run ECC or Business Suite, so the legacy estate needs running too.

Does RISE with SAP mean we don't need Basis people?

Only if you buy the Packaged tier. SAP's wording in the responsibility document is unambiguous: Packaged Services "needs to be performed by customer if applicable and if a Packaged Service is not used". Excluded Tasks stay with you regardless of spend. Both routes have a cost, and comparing them honestly is the useful exercise before anyone writes a job advert.

What do we still own under RISE?

Five areas, and they are where a retained SAP Basis or technical operations person spends the week:

• Role and authorisation administration.
• Ongoing operation of the transport management system, beyond SAP's default setup.
• Single sign-on design and identity integration with your directory.
• Custom code and its clean-core grade.
• Testing of implemented notes.

What should an SAP Basis CV show in 2026?

Evidence at the boundary. Look for authorisation redesign, transport landscape ownership across environments, identity integration, and clean-core remediation with a level attached. A certification alongside that evidence is a bonus; on its own it tells you nothing. Titles will vary, since SAP's current curriculum calls the job system administration, so screen the described work instead of the label.

---

Most of these searches land in Germany and the wider DACH market, which is also where the user-group data above was gathered. Before I take an SAP brief I want the tier answered: which of the five categories does this work sit in, and does what remains justify a permanent hire or a line on the renewal? Two to four active searches at a time is what makes that conversation possible instead of perfunctory. If you are deciding whether to keep, rebuild or buy back Basis capability after a RISE move, tell me about the role and we will work through it before anyone writes a job advert.