SAP S/4HANA is SAP's fourth-generation ERP business suite — the successor to classic SAP ERP (ECC) — and it runs exclusively on the SAP HANA in-memory database. First released in 2015, it brings finance, procurement, manufacturing, sales, and supply chain processes into one system, wrapped in a modern Fiori user experience with a simplified data model and embedded analytics. For developers, it is the system that most SAP work now targets, and the one your extensions, interfaces, and Fiori apps have to live with.
If you are joining an SAP project today, you will hear "S/4" constantly — in migration plans, job posts, and architecture debates. This guide explains what S/4HANA actually is, how it differs from the classic ERP it replaces, how it relates to SAP HANA and SAP BTP, and where developers plug in.
What an ERP Suite Actually Does
An ERP (enterprise resource planning) suite is the operational backbone of a company: one integrated system that records every business transaction and keeps the data consistent across departments. When a sales order is entered, the ERP checks stock, reserves inventory, triggers procurement, posts to finance, and updates the general ledger — all from the same data.
SAP has been the dominant ERP vendor for decades, and classic SAP ERP (known as ECC) was its flagship product. S/4HANA is the rewrite of that product for the in-memory era. It covers the same functional ground — financials, materials management, production, sales, human resources touchpoints — but restructures the data model, replaces the SAP GUI-first user experience with Fiori, and bakes analytics into the transactional system instead of shipping them to a separate warehouse first.
The "4" in S/4HANA marks it as the fourth generation of SAP's business suite. The "S" is widely read as "simple," a nod to the simplified data model that was the product's original headline claim when it launched with SAP Simple Finance.
S/4HANA vs SAP ERP: What Actually Changed
Three changes matter more than everything else combined: the database, the data model, and the user experience.
It only runs on HANA
Classic SAP ERP was database-agnostic — it ran on Oracle, Microsoft SQL Server, IBM Db2, and others, which forced the application layer to avoid anything database-specific. S/4HANA dropped that constraint and targets the HANA columnar, in-memory engine exclusively. Because the database can aggregate millions of rows in memory in milliseconds, the application no longer needs the layers of indexes, aggregate tables, and batch jobs that classic ERP used to make reporting survivable. That single decision is what made the rest of the redesign possible. The HANA side of the story is covered in detail in SAP HANA Cloud and on the SAP HANA skills hub.
The simplified data model
The flagship example is the universal journal (table ACDOCA), which merges the separate financial accounting and controlling tables of classic ERP into one line-item table. Similar consolidation happened elsewhere — material documents, for example, collapsed into a single table instead of a cluster of index and history tables. Fewer tables means fewer reconciliations, real-time margin reporting straight from the transactional system, and materially less custom code doing things the suite now does natively. It also means classic custom code that reads old tables has to be reworked, which is why migrations are as much a development project as a functional one.
Fiori and embedded analytics
SAP GUI transactions are replaced (or fronted) by SAP Fiori: role-based web apps served from the Fiori launchpad, built with SAPUI5. Alongside the UX change comes embedded analytics — KPIs, drilldowns, and dashboards modeled on CDS virtual data models and evaluated live by HANA, rather than loaded overnight into a separate BI system. Reports that used to be batch jobs become refreshes.
| Aspect | SAP ERP (ECC) | SAP S/4HANA |
|---|---|---|
| Database | Any supported RDBMS (Oracle, SQL Server, Db2, ...) | HANA only (in-memory, columnar) |
| Data model | Many tables, aggregates, and indices | Simplified — universal journal, fewer tables |
| User experience | SAP GUI transactions, Web Dynpro | SAP Fiori apps on SAPUI5, role-based launchpad |
| Analytics | Separate BW/BI stack, batch loads | Embedded, CDS-based, real-time on HANA |
| Development model | Classic ABAP, open modifications | ABAP Cloud with RAP and CDS; extend, don't modify |
With mainstream maintenance for classic SAP ERP ending in 2027 (and paid extended maintenance available beyond that), most SAP customers are somewhere in a migration program right now — which is precisely why S/4HANA skills are in demand.
S/4HANA Cloud vs On-Premise: The Editions
S/4HANA ships in three main editions, and the differences are mostly about who operates the system and how much you can change it:
- S/4HANA Cloud Public Edition — the multi-tenant SaaS. SAP runs everything, ships feature updates on a regular quarterly release cycle, and upgrades are mandatory. Customization is limited to key-user and developer extensibility. Best for organizations adopting standard processes ("clean core").
- S/4HANA Cloud Private Edition — a single-tenant system hosted and operated by SAP (commonly sold under the RISE with SAP commercial umbrella). You keep most of the on-premise extensibility and keep your own release pace, while SAP handles infrastructure and technical operations.
- S/4HANA on-premise — the classic licensed software on your own hardware. Maximum control, maximum responsibility, and the full (if discouraged) set of modification options.
For developers, the edition decision is really an extensibility decision. Public cloud means everything you build must live within released APIs and the extension framework. On-premise and private cloud still tolerate classic modifications — but every modification makes the next upgrade harder, which is why even there the industry has converged on the clean-core approach.
S/4HANA and SAP HANA: The Suite and the Database
The naming confuses everyone once: SAP HANA is the database, S/4HANA is the application suite that runs on it. HANA stores data in columnar, in-memory tables and does the heavy computational lifting; S/4HANA is the business logic, processes, and UI built on top of that engine.
You will encounter HANA in two packaging flavors: the on-premise/appliance version you install and operate, and SAP HANA Cloud, the managed database-as-a-service on BTP. S/4HANA runs on the HANA family in its various deployments — the details of which flavor backs which edition are an infrastructure conversation more than a development one. What matters for you as a developer is that the database under your S/4HANA code is a HANA engine, so CDS views, SQLScript, and code-pushdown techniques all apply. The SAP HANA hub collects the relevant skills.
S/4HANA and BTP: Core vs Side-by-Side
SAP BTP (Business Technology Platform) is SAP's cloud platform for building and extending applications — it is not part of S/4HANA, and S/4HANA does not require it to run. The two are designed as a pair:
- The clean core idea: keep S/4HANA as standard as possible, so upgrades stay cheap and predictable.
- Side-by-side extension: build the custom functionality on BTP instead, as a separate application that talks to S/4HANA through its released OData and API interfaces.
A typical side-by-side extension is a CAP or Fiori app running on BTP, reading and writing S/4HANA business data through the Destination service and published APIs, with SAP HANA Cloud as its own persistence layer. The full platform picture is in What is SAP BTP? and on the SAP BTP hub.
Where Developers Come In
S/4HANA development happens in three layers, and understanding the split is the fastest way to look competent in a project kickoff.
ABAP, CDS, and RAP
The in-stack extension language is still ABAP — but modern S/4HANA development uses ABAP Cloud: a restricted, upgrade-safe ABAP that works only with released APIs and the RESTful Application Programming Model (RAP). You define data models with CDS views, expose them as OData services with RAP behavior definitions, and get transactional semantics, drafts, and Fiori-elements-ready services almost for free. The learning path is on the ABAP hub, and you can give your AI assistant accurate context with the ABAP and ABAP CDS skills:
npx skills add secondsky/sap-skills --skill sap-abap
Fiori and SAPUI5 frontends
The frontend layer is SAPUI5 — SAP's JavaScript framework — usually with Fiori elements, which generate complete apps from CDS annotations instead of hand-coded views. Frontend work on S/4HANA projects is real web development: OData consumption, routing, component models, and deployment to the launchpad. The Fiori tools skill keeps assistants current with the tooling around this stack.
Key-user, developer, and side-by-side extensibility
| Extensibility type | Who builds it | Where it runs | Typical use |
|---|---|---|---|
| Key-user | Business users, no code | Inside S/4HANA | Custom fields, custom logic, formatted output |
| Developer (in-stack) | ABAP developers | Inside S/4HANA | RAP services, CDS models, ABAP Cloud apps |
| Side-by-side | Any stack | On SAP BTP | New apps, integrations, anything not fitting the core |
Key-user extensibility lets consultants and power users add fields and simple logic from guided UIs — no transport, no developer needed. Developer extensibility is the ABAP Cloud path above, inside the system but confined to released contracts. Side-by-side on BTP is where everything else goes. The strategic direction across all editions is the same: keep the core clean, push custom code to the edges.
The Short Version
S/4HANA is SAP's ERP, rebuilt for an in-memory database it refuses to share: one simplified data model, Fiori on top, analytics inside, and a strict extend-don't-modify development culture. Learn ABAP Cloud and CDS, get comfortable with Fiori frontends, and know when to move work onto BTP — that combination covers most of what S/4HANA projects ask for. Start with the ABAP hub or browse the full catalog of SAP skills to see what your assistant can learn today.