Introduction: A New Era of SAP Development
If you’ve spent years developing in classic SAP ECC systems, transitioning to S/4HANA can feel like learning a new dialect of a familiar language. While ABAP remains at the core, the underlying architecture, development paradigms, and best practices have shifted dramatically. SAP S/4HANA – built natively on the HANA in-memory database – demands a fundamentally different approach to programming.
In this article, we’ll break down the most important differences between programming in SAP S/4HANA and older SAP systems (ECC 6.0, R/3, and earlier). Whether you’re planning a migration or starting fresh, understanding these changes is essential for writing efficient, future-proof code.
1. The HANA Database Changes Everything
The most fundamental shift is the underlying database. Classic SAP systems ran on various databases – Oracle, DB2, SQL Server, MaxDB – and ABAP code had to be database-agnostic. S/4HANA runs exclusively on SAP HANA, an in-memory columnar database.
What this means for developers: You can now push complex calculations and data processing down to the database layer instead of handling everything in the application server. This “code pushdown” principle is the single most important paradigm shift in S/4HANA development. In legacy systems, it was common to SELECT large datasets into internal tables and then loop through them in ABAP. In S/4HANA, this is considered an anti-pattern – you should let HANA do the heavy lifting.
2. CDS Views Replace Classic Dictionary Views and Reports
Core Data Services (CDS) views are one of the most significant additions to the S/4HANA development toolkit. They replace traditional ABAP Dictionary views (SE11) and many custom reports with semantically rich, annotation-driven data models defined directly in the ABAP Development Tools (ADT) in Eclipse.
In legacy SAP, if you needed a complex data view combining multiple tables, you’d typically create a database view in SE11 or write a complex SELECT statement in your ABAP program. In S/4HANA, you define a CDS view that:
- Supports associations (replacing traditional JOINs with on-demand navigation)
- Includes built-in annotations for UI, analytics, and OData exposure
- Can be consumed by Fiori apps, analytical queries, and other CDS views
- Supports calculated fields, aggregations, and complex expressions at the database level
CDS views are not optional in S/4HANA – they are the foundation of the Virtual Data Model (VDM), which is SAP’s recommended way to access business data.
3. Eclipse-Based ADT Replaces the Classic SAP GUI Editors
One of the most visible changes for developers is the shift from SAP GUI-based tools (SE38, SE80, SE24) to the ABAP Development Tools (ADT) in Eclipse. While SAP GUI transactions still work, many new S/4HANA development objects – such as CDS views, AMDP classes, and behavior definitions for RAP – can only be created in Eclipse.
For developers who’ve spent decades in SE80, this transition can be jarring. However, ADT offers significant advantages: modern code completion, inline error checking, refactoring tools, Git integration, and a much better experience for working with CDS views and annotations. The sooner you embrace Eclipse, the more productive you’ll be in the S/4HANA world.
4. The New ABAP SQL (Formerly Open SQL) Syntax
ABAP SQL in S/4HANA has been significantly modernized compared to the classic Open SQL used in older systems. The new syntax supports:
- Inline declarations:
SELECT ... INTO TABLE @DATA(lt_result)instead of pre-declaring internal tables - String expressions and templates: Build dynamic strings directly in SQL statements
- CASE expressions: Conditional logic within SELECT statements
- Built-in functions: String functions, date functions, and mathematical operations executed at the database level
- UNION and CROSS JOIN: Standard SQL operations now available in ABAP SQL
- Host expressions: Use ABAP expressions directly inside SQL with the
@escape character
In legacy systems, much of this logic had to be handled in ABAP after data retrieval. Now, you can express complex transformations directly in your queries, letting HANA optimize and execute them far more efficiently.
5. AMDP: Writing HANA SQL Script Inside ABAP Classes
ABAP-Managed Database Procedures (AMDP) are a game-changer for developers who need to leverage HANA-specific capabilities. AMDPs allow you to write SQLScript (HANA’s native procedural SQL language) directly inside ABAP class methods, with the ABAP runtime managing the lifecycle of the database procedure.
In older SAP systems, if you needed a stored procedure, you had to create it directly in the database (outside of the ABAP transport system), which caused maintenance nightmares. AMDPs solve this by keeping everything within the ABAP development workflow while still giving you access to HANA’s powerful features like window functions, hierarchies, and advanced text search.
A typical use case: implementing complex calculation logic that would be too slow in ABAP but runs instantly as a HANA SQLScript procedure.
6. The Fiori/UI5 Frontend Revolution
In classic SAP, the user interface was built with Dynpro (classic screens), Selection Screens, or ALV reports – all running within the SAP GUI. S/4HANA moves to SAP Fiori as the primary UI technology, built on SAPUI5 (SAP’s implementation of OpenUI5, based on HTML5 and JavaScript).
This is not just a cosmetic change – it represents a fundamental architectural shift:
- Frontend and backend are decoupled: Fiori apps communicate with the backend via OData services (REST-based APIs), not direct ABAP function calls
- Role-based design: Instead of monolithic transactions (like VA01, MM01), Fiori apps are task-oriented and role-specific
- Responsive design: Apps work on desktops, tablets, and mobile devices
- Launchpad-based navigation: Users access apps through the Fiori Launchpad, replacing the classic SAP Easy Access menu
For ABAP developers, this means learning to build OData services (using SEGW or, preferably, RAP) and understanding how the frontend consumes them. You don’t necessarily need to become a JavaScript expert, but understanding the OData protocol and Fiori architecture is essential.
7. RAP: The ABAP RESTful Application Programming Model
RAP is SAP’s strategic programming model for building Fiori apps, APIs, and business services in S/4HANA. It replaces the older BOPF (Business Object Processing Framework) and the classic dynpro-based programming model.
RAP introduces several new concepts that don’t exist in legacy SAP development:
- Business Objects defined via CDS: Your data model, behavior, and projections are all interconnected
- Behavior Definitions and Implementations: Declarative way to define CRUD operations, validations, determinations, and actions
- Draft handling: Built-in support for saving incomplete data – something that required significant custom coding in classic systems
- Managed vs. Unmanaged scenarios: Choose how much the framework handles for you
- EML (Entity Manipulation Language): A new ABAP language construct for programmatically interacting with RAP business objects
RAP represents the biggest shift in ABAP programming methodology since the introduction of Object-Oriented ABAP. If you’re developing new applications in S/4HANA, RAP is the recommended approach.
8. Simplified Data Model: Goodbye Aggregate Tables and Indexes
One of the most impactful changes in S/4HANA is the dramatically simplified data model. SAP removed thousands of aggregate tables, index tables, and redundant data structures that existed solely to work around the performance limitations of traditional disk-based databases.
Classic examples that no longer exist in S/4HANA:
- BSEG (accounting line items) is now a compatibility view over the new ACDOCA table
- KONV (pricing conditions) has been restructured
- Many S-tables (summary/aggregate tables) have been eliminated
- Numerous index tables are no longer needed because HANA’s columnar storage and in-memory processing make them redundant
For developers, this means existing custom programs that SELECT from these deprecated tables will need to be adapted. SAP provides compatibility views for the transition period, but for optimal performance, you should migrate to the new table structures.
9. Clean ABAP and Modern Coding Standards
While not strictly a technical requirement, SAP has been strongly promoting “Clean ABAP” – a set of modern coding guidelines inspired by Robert C. Martin’s Clean Code principles. S/4HANA development is expected to follow these conventions:
- Use meaningful, English-language variable names (no more
LV_BUKRSorLT_TAB01) - Prefer functional and object-oriented patterns over procedural code
- Avoid obsolete statements (MOVE, COMPUTE, header lines, field symbols where references work)
- Write unit-testable code with proper separation of concerns
- Use inline declarations and modern ABAP syntax
In legacy systems, it was common to see massive procedural programs with thousands of lines, cryptic variable names, and deeply nested IF/LOOP structures. S/4HANA development culture actively discourages this in favor of modular, readable, and testable code.
10. Cloud-Ready Development with SAP BTP and Steampunk
S/4HANA introduces a cloud-first development mindset. SAP Business Technology Platform (BTP) and ABAP Cloud (sometimes called “Steampunk”) extend development beyond the traditional on-premise ABAP stack:
- Released APIs only: In ABAP Cloud, you can only use SAP-released APIs and objects (no direct table access, no unreleased function modules). This forces clean, upgrade-safe development.
- Side-by-side extensions: Instead of modifying the S/4HANA core, you build extensions on BTP that communicate via APIs
- Key User Extensibility: Business users can create custom fields, logic, and apps without traditional development – a concept that didn’t exist in older systems
- Developer Extensibility: Custom ABAP code runs in a restricted environment with a defined set of released interfaces
This “keep the core clean” approach is a radical departure from the traditional SAP customization model, where modifications and enhancements were applied directly to the system.
Summary: Key Takeaways
The transition from classic SAP programming to S/4HANA development is significant but manageable. Here’s what matters most:
Push code to the database – leverage CDS views, AMDP, and modern ABAP SQL instead of processing data in ABAP loops. Embrace the new tools – Eclipse ADT, RAP, and Fiori/OData are not optional extras but core development technologies. Adapt to the simplified data model – many tables you relied on no longer exist in their original form. Think clean and cloud-ready – write modular, testable code using only released APIs, and design for extensibility rather than modification.
The good news? ABAP is still ABAP. Your core skills in understanding business logic, debugging, and system architecture remain invaluable. The shift is more about adopting new paradigms and tools than learning an entirely new language. Start with CDS views and modern ABAP SQL – they offer the quickest wins and the clearest path into S/4HANA development.
Are you planning or currently going through an S/4HANA migration? Share your experiences and challenges in the comments below, or contact us for expert guidance on your S/4HANA development journey.