Is ABAP still worth learning in 2026?

Every quarter, a junior developer at the office asks us a version of the same question: “Should I learn ABAP, or is it dead?”

The question isn’t as silly as it sounds. SAP is loudly pushing everyone to the cloud, RISE and clean core. New extensions are supposed to live in the BTP layer, in JavaScript, in CAP, in Java, in anything except the tightly-coupled ABAP customisations that made ECC 6 so hard to move off.

So the honest answer takes a paragraph, not a word.

Short version

Yes, ABAP is still worth learning — but the ABAP you should learn today is not the ABAP the last generation learned.

The world doesn’t need another Z-report developer copying old code around the customer namespace. The world needs engineers who can work inside a clean core S/4HANA landscape — which means ABAP Cloud, RAP (RESTful Application Programming), CDS views, side-by-side extensions on BTP, and enough eventing and API sense to not paint the customer into another 20-year corner.

If that’s the ABAP you learn, you’ll have work for the next fifteen years.

Why ABAP isn’t going away yet

Four reasons, in decreasing order of durability.

1. The installed base is enormous. There are still tens of thousands of ECC 6 systems in production. Every one of them needs someone to keep it running until the S/4HANA migration is done — and most of those migrations are still 18–48 months out. That’s a large maintenance market for anyone who can read classical ABAP.

2. S/4HANA runs on ABAP. S/4HANA’s application server is still an ABAP application server. RAP is ABAP. CDS is defined in ABAP. Custom Fiori apps still need OData services, which are still ABAP-authored unless you’re going full CAP-on-BTP. If you think S/4HANA killed ABAP, you’re mistaking the box it runs in for the box you extend it in.

3. Some extensions belong in the core. SAP’s own guidance splits extensions into “in-app” (ABAP Cloud, RAP) and “side-by-side” (BTP). The in-app ones are ABAP. They’re supposed to be a small set of extensions, done cleanly, with public APIs — but “small” is not “zero.”

4. Migration is an ABAP-heavy exercise. Custom code check, SPDD/SPAU, obsolete-syntax remediation, replacement of removed function modules, custom Fiori launchpad content — all of it is ABAP work. A programme that migrates 30,000 lines of custom Z-code from ECC to S/4HANA is going to be paying ABAP developers for the entire duration.

What kind of ABAP to learn

Here’s the differentiator between “worth learning” and “career-limiting.”

Learn:

• ABAP Cloud. The restricted-language, side-effect-controlled subset of ABAP that clean core S/4HANA extensions have to be written in. This is where the future is. Practise on abap-cloud-project in embedded Steampunk or on the BTP ABAP environment trial.
• RAP (RESTful Application Programming for ABAP). The model that unifies CDS + behaviour + service exposition. If you can build a RAP business object with managed persistence, OData v4 exposure and draft handling, you can build a modern Fiori-first S/4HANA app.
• Core Data Services (CDS) views. Not just as SQL replacements — as the annotated, semantically rich building blocks that Fiori, analytics and RAP all depend on.
• AMDP + HANA SQLScript. When code has to push down to HANA for performance, this is how.
• Test-Seams, ABAP Unit, ATC (with cloud check variants). Real engineering practices inside ABAP. Yes they exist.
• Object-oriented ABAP, not procedural. Classes, interfaces, dependency injection. If your default is to write a Z_REPORT with an event-based selection screen, you’re writing 2005 ABAP.

Skip (or learn only to survive maintenance):

• ALV grid tricks, module pools, screen painter (SAP GUI). Still installed everywhere, still maintained — but do not build a career on this. It’s a maintenance skill, not a growth skill.
• SAPscript, Smart Forms. Adobe Forms replaced these years ago. Learn Adobe Forms briefly, then move on.
• Business Server Pages (BSP). Dead-end.
• Web Dynpro ABAP. Dead-end, replaced by Fiori.
• BAPIs and function-module-centric integration. Learn what they are — you’ll see them in old code — but the modern equivalent is a RAP-exposed service or an event-driven publish.

What the market will actually pay for

At the risk of oversimplifying — three archetypes.

The S/4HANA extension developer. Fluent in ABAP Cloud + RAP + CDS. Can build a clean side-by-side extension in CAP/Java on BTP when the extension doesn’t belong in-core. Understands eventing and clean core boundaries. This is where the salary curve is bending upwards. Every S/4HANA landscape needs one, and there aren’t enough of them.

The migration specialist. Deep classical ABAP knowledge plus the ability to remediate custom code for S/4HANA — SUM, DMO, obsolete APIs, simplification database, custom code readiness. This work has a five- to seven-year runway as the installed base finishes migrating. Not a career for a fresh grad, but a very good pivot for a senior ABAPer who wants to work S/4HANA jobs without becoming an extension developer.

The functional-technical bridge. Someone who knows enough MM/SD/FI/HCM to sit in the requirement conversation with a business analyst and can write the ABAP or configure the process to solve it. These people were always undervalued and now they’re rarer than ever. If you’re a functional consultant who can code, or a coder who understands finance and logistics processes deeply, you’re in the top 5% of hireable SAP profiles.

Where new ABAP developers usually go wrong

Two failure modes we see over and over.

One: they learn ABAP as a monolithic language. They can write reports, they can write BAPIs, they can write ALV grids — but they’ve never touched CDS, RAP, or ABAP Cloud. When they interview at a shop doing S/4HANA extension work, they get a polite “we’ll be in touch.” Learn the modern subset before you deepen the classical one.

Two: they learn ABAP without learning SAP. ABAP is a language, but its value is that it lives inside SAP. If you don’t understand what a purchase order, a delivery, a billing document, a material master and a customer master actually are — and how they flow — you’re going to write technically correct code that solves the wrong problem. Spend a month with the basic MM/SD/FI process flows before you spend a year on syntax.

The recommendation we give juniors on our team

If you’re joining our SAP practice today, here’s the sequence we’d suggest:

1. Month 1–2: SAP basics. NetWeaver overview, MM/SD/FI process flows, the SAP GUI, the transport landscape. Read SAP for Dummies if you must — it’s not embarrassing.
2. Month 3–4: ABAP fundamentals. Data types, internal tables, ABAP OO, class-based exception handling, package concept, transport layer.
3. Month 5–6: Modern ABAP. CDS views (basic → composite → consumption), ABAP Cloud restrictions, ABAP Unit, ATC.
4. Month 7–8: RAP. Managed and unmanaged scenarios. Draft handling. OData v4 exposure. A small end-to-end Fiori-first business object.
5. Month 9–12: Real project. Ship something. Doesn’t matter if it’s small.

At month 12 you’re not a senior ABAP developer. But you’re employable in a modern S/4HANA shop, which is more than the majority of people currently claiming “SAP experience” on LinkedIn can honestly say.

The uncomfortable answer

The uncomfortable answer to “is ABAP still worth learning” is that ABAP is worth learning if the rest of your career plan is also compatible with it.

If you want to move to San Francisco and work on generative AI, don’t learn ABAP.

If you want to work on enterprise systems that keep a real business running, that are boring in the best sense of the word, that require you to understand the mid-back office of a real economy — yes, learn ABAP. And learn ABAP Cloud, RAP and CDS as your primary dialect.

The people who tell you SAP is dead are, without exception, people who don’t work with it.

If you’d like to talk to us about joining our SAP practice — junior or senior — we’re hiring.