SAP ERP generations
SAP’s flagship ERP has been shipping since 1992 under three product names that are really three revisions of the same system. Atlas spends most of its time working in one of the three; it needs to read the other two to explain what a conversion is converting from and to.
How the three differ
Section titled “How the three differ”ECC is the earlier generation, designed when databases were row-stores and ABAP servers did most of the joining. That assumption shaped everything about how ECC stores data — thousands of narrow tables, heavy application-side processing, limited ability to push work down to the database. Atlas does not emit code for ECC. It only reads ECC structures when a conversion needs to preserve something that existed there.
S/4HANA on-premise is the current generation and the product Atlas is built to plan against. It runs exclusively on HANA, exposes its data through the Virtual Data Model (the subject of Why the VDM exists), and is still deployed by the customer on their own systems. That last property is what makes on-premise the middle generation — the customer has freedom to host extensions alongside the ERP on the same system, and Atlas can emit into that space when a plan calls for it.
S/4HANA Cloud is the same product under a cloud operating model. Quarterly releases are mandatory. Clean-core enforcement is stricter — you cannot reach into the core from custom ABAP, and extensions must live on BTP. Atlas can target Cloud, but when it does it changes how it emits: everything that would have lived in on-system extensions moves to BTP, because the alternative is not an alternative.
Why Atlas settled on the middle generation
Section titled “Why Atlas settled on the middle generation”Atlas needs enough room to make a conversion plan that actually works on a real system, and enough constraint that what it writes is maintainable across future upgrades. On-premise has both. ECC has neither, because the plan would be for a system that is going away. Cloud has only the second, because extensions are already required to live outside the core — Atlas supports it, but there is less planning work to do inside the ERP itself.
When a case targets Cloud — set at case creation by picking the Cloud target in the release dropdown — Atlas detects the target and switches its emit mode automatically. Nothing you write in the task changes, but the generated plan will place more work on BTP and less inside the ERP. The evidence trail records the placement call so a reviewer can see it.
The one thing that did not change
Section titled “The one thing that did not change”All three generations keep the document-chain mental model: a sales order becomes a delivery, a delivery becomes an invoice, an invoice becomes a general-ledger posting. Atlas’s planner leans heavily on the document chain — it is the mechanism by which Atlas knows what to build next given what was just built. A view over sales orders implies a view over items; a view over items implies a view over products. The chain is what lets Atlas propose a dependency-ordered plan from a single sentence of intent.
That continuity is why a skill you already have as an ECC consultant transfers directly into what Atlas is doing on S/4HANA. You know the chain. Atlas is just an agent that walks it for you and keeps the evidence.