Yesterday, the DSAG published a recommendation on the further training of SAP developers. You can download it directly here: https://impulsant.dsag.de/wp-content/uploads/2026/07/CIO-Upskilling.pdf
Training SAP Developers: Why Management Needs to Act
As trainers, we see every day that there is extensive training needs among SAP customers. That is why we welcome the fact that the DSAG has now taken a stance on this as well. The aim is to give the staff of SAP development departments arguments to work with, and above all an external, official recommendation on the topic.
How This Paper Came About
At the in-person meeting of the Development working group in February, right after the DSAG Zukunftstag Development, we worked in small groups on various topics. I was in the group that dealt with further training for developers. And pretty quickly we agreed on where the problem really lies: rarely in the development department itself. The developers usually know exactly what they need to learn. They just don't get to decide it.
Out of this discussion came the idea for a DSAG CIO paper on the topic of upskilling. A short document that explains to CIOs and IT managers why further training for SAP developers is a strategic investment and not a nice-to-have. Eight authors from among the DSAG members contributed to it. We had posted a draft at the ABAP Development Days and gathered quite a bit of feedback there.
In a CIO paper you have to keep it brief. That is why I would like to discuss some points here in a bit more detail than was possible there.
Migration Done, Potential Left on the Table
Many companies are now on S/4HANA or in the middle of the migration. The system is running, the old programs work. But that is exactly what obscures the real problem: A technical migration does not bring the custom developments up to a new level. Old processes, old technology, redundant custom developments stay as they are. You use the new platform at the level of the old one. Roughly like putting a Porsche engine into your VW Golf, but still driving to the bakery just like always.
With Clean Core, CDS, RAP, and Fiori Elements, SAP has introduced completely new paradigms. SAP also uses this stack for its own products, and that is a pretty reliable indication that this is not a transitional solution. Anyone who ignores this is programming past the platform. Technically everything still runs. The technical debt grows silently in the background and eventually demands compound interest.
Outdated skills simply do not become apparent right away. Old SAP technologies keep running for years. The deficits only show up later: in weak architecture decisions, in workarounds that slow down migration projects, in custom developments that have to be reworked with every release.
Clean Core Also Works On-Stack
One misconception I keep encountering: Many believe that Clean Core necessarily means that extensions have to be moved out to the BTP. SAP did indeed communicate it that way in the past, and this statement is still floating around in people's heads today. But it is no longer accurate. With on-stack extensibility via ABAP Cloud, there is now a mature way to implement extensions directly in the S/4HANA system, even in the Public Cloud. They remain upgrade-safe because they use only stable, released SAP APIs. This shifts the question: It is about which extension technology fits the specific use case. And to be able to decide that, you need knowledge of both approaches.
Management Attention: The Real Problem
In the working group this quickly became consensus. The developers know what needs to be done. The bottleneck is with those who decide on training budgets and capacity planning.
In many companies, developer training is treated as a peripheral operational topic: a course from the catalog, approved when no project is pressing. That worked for a long time because little changed over the years. With S/4HANA, Clean Core, and BTP, however, this logic no longer works. The technical foundations have changed fundamentally over the past 15 years, and complexity has increased considerably.
That is why the DSAG CIO paper is not addressed to developers, but to CIOs, IT managers, and everyone who decides on investments in training. Developers need an argumentation aid that works at the management level. That is exactly what we wrote it for.
Who Else Needs to Be Considered
Our working group came predominantly from the ABAP environment, so that is where the focus of the paper lies. But the training needs do not stop at the ABAP developers.
Business consultants are the interface between the business department and development in SAP projects. If they continue to tailor requirements to GUI transactions and classic customizing because they do not know Fiori apps and the underlying technology model, then specifications arise that miss the current platform. In the end, things get custom-developed for which the SAP standard has long had an answer with Fiori. Or requirements land on the table that cannot be implemented with RAP at all because they are based on a completely different architectural logic.
Basis administrators quickly slip into a role no one prepared them for when it comes to BTP and side-by-side development. CAP applications on the BTP require know-how in BTP structure, authentication, security, and CI/CD pipelines. Anyone who does not train the Basis team ends up with a platform that no one can administer.
And then there are the external service providers. Many companies have custom developments implemented entirely or partly by externals. That works fine as long as the internal team can assess the quality. If this know-how is missing on the customer side, no one checks whether the architecture is correct, whether Clean Core is being adhered to, or whether the test coverage is sufficient. Whatever slips through at acceptance shows up later as a maintenance problem.
The reverse is also true: A consultant who has no overview of the current SAP technologies will not raise requirements that fit Fiori First and Clean Core. Anyone who wants to keep this risk small needs their own know-how. To recognize what is good, and to be able to demand it.
AI Accelerates – in Both Directions
AI-assisted development tools have arrived in everyday work. SAP Joule, GitHub Copilot, and similar tools suggest code, explain code sections, generate test cases. For developers who master the current technology stack, these are real accelerators.
For developers without a solid foundation, unfortunately the opposite applies. They produce code faster, but the quality does not improve as a result. Anyone who cannot judge whether a CDS view is correctly modeled, whether a RAP implementation is cleanly built, or what a unit test is actually supposed to accomplish, gets one thing above all with AI support: more potential technical debt in less time.
On top of that, AI models orient themselves on the existing code. A poor code base leads to poorer suggestions. Clean code and unit testing are therefore not academic concepts but the prerequisite for AI-assisted development to remain controllable at all. Anyone who wants to use AI as an accelerator needs well-trained developers. It simply does not work any other way.
What Needs to Be Done Concretely
The DSAG CIO paper recommends, among other things:
- Define role-specific curricula, because ABAP developers, CAP developers, integration experts, and business consultants have different learning needs
- Provide learning environments where none exist – SAP CAL, ABAP Trial, and the ABAP Platform Docker container offer cost-effective options for this
- Include training time bindingly in capacity planning and do not treat it as a gap filler between projects
- Time training to coincide with ongoing migration or modernization projects so that the content can be applied directly
The last point in particular is important to me. Learning without a direct application context fades quickly. Developers must be able to apply what they have learned immediately. For that, the training has to take place before the architecture decisions are made. Not during, and certainly not afterward.
The DSAG Academy, SAP, and individual DSAG member companies offer training and webinars on current SAP development technology. The DSAG guidelines also provide a good reference framework, for example the ADT guideline and the ABAP guideline.
The Paper as a Tool
Anyone who is fighting for further training in their own company and running into deaf ears needs arguments that land at the management level. That is exactly what we wrote the DSAG CIO paper for: compact, robust, and in the language of the target audience. It can be found on the DSAG website: https://impulsant.dsag.de/wp-content/uploads/2026/07/CIO-Upskilling.pdf
