How SAP's cost model works, why 2027 is a natural decision point, and how to migrate your customer and process data to an open, in-house data layer, alongside or instead of SAP.
For many companies, SAP is the solid heart of finance and logistics, but also an environment where your own customer and process data has become practically unreachable: spread across encoded tables, locked behind licenses and only changeable through the partner.
Toward the end of 2027, SAP is winding down regular maintenance on the older ECC generation, and the European Data Act bans switching costs for cloud services.
That makes the coming period a natural decision point: not necessarily leaving SAP, but getting your data back in-house, in an open data layer that runs your customer view, reporting and AI without a licensing debate.
That data layer sits alongside SAP, gets filled through a controlled migration with a test round and checks, and afterwards gives you control over what remains on SAP.
SAP wasn't chosen because it was trendy, but because it worked. Inventory, purchasing, invoicing and accounting in one system, with the discipline and reliability a manufacturing or trading company needs. For many companies, the implementation was a significant investment that paid for itself in operational control.
But the model underneath that solidity dates from a time when data and software were inseparable. Your data lives in SAP's tables, in SAP's data model, accessible through SAP's screens and licenses. As long as everything happened within that house, that was no problem. The problem arose when companies wanted to do more with their own data: connect a webshop, build a customer portal, combine reporting with other sources, run AI on their own history. Each of those wishes runs into the same thing: the data is yours, but access belongs to SAP.
SAP's bill consists of three layers that rarely appear on a single overview.
On top of user licenses, you pay annual maintenance on the license value, and the route SAP has in mind, toward S/4HANA and the cloud, is a new round of investment for most customers. The package rarely gets cheaper; the only question is how fast it gets more expensive.
The most remarkable part of SAP's cost model is indirect access, now called digital access: systems that work with SAP data through an integration, such as a webshop, a portal or your own app, can also be subject to licensing. Lawsuits have been fought over this and the rules have since been clarified, but the principle still stands: your own software touching your own data can cost money. For companies that want to digitize, that's a structural brake: every innovation starts with a licensing question.
A report, a field, a changed process: almost every change runs through the SAP partner, in ABAP or through configuration that nobody in-house masters. That's not unwillingness; the platform is too complex to pick up on the side. The result is a dependency that no invoice ever calls "lock-in", but that's exactly what it is.
Every innovation starts with a licensing question.
No per-user licenses on your own data, only low and predictable infrastructure costs.
Two developments make the coming period special. The first: SAP is winding down regular maintenance on the older ECC generation toward the end of 2027. Anyone still running it needs to move regardless; standing still is no longer an option. The standard route then on offer is migration to S/4HANA, a project that costs many SMEs years and a small fortune.
The second: the European Data Act. It requires cloud service providers to make switching practically possible, including handing over your data in a common, usable format. From 12 January 2027, no switching costs may be charged for this. More on this in our article on the Data Act and switching costs.
If you have to migrate anyway, that's the moment to ask a broader question than "which SAP version will it be". Which data and processes actually belong in-house? And what do you genuinely still need SAP for afterwards? Anyone who only asks that question after the S/4HANA migration has just extended their lock-in for years.
Your data comes completely out of SAP, but not all of it the same way, and almost none of it in a form you'll want to use directly. These are the routes.
The export is half the work. The other half is the transfer itself, and that's where migrations that looked fine on paper go wrong. Five rules that make the difference.
First master data, then transactions, then documents; reversing the order creates orphaned records. Keep a mapping per record from SAP key to new ID, so every relationship is traceable and every mistake fixable.
Everything to a test environment. Recount per table: the same number of customers, orders and invoices as in the source. Spot-check the chains from customer to order to invoice and the odd cases, such as old numbering series.
The best moment to deduplicate and normalize: you're already looking at every table anyway. Document what you deliberately leave behind, so "left behind" never means "lost".
The data layer proves itself alongside SAP with a complete customer view, dashboards and AI, while new records flow in. SAP remains the system of record for finance and logistics; nothing is switched off before something better has proven itself.
ABAP customizations and linked process automation can't be carried over literally. Some of it existed only to work around the package's limitations. Rebuild what your process actually needs and leave the rest out.
Where do you migrate to? And Repeat's answer isn't another package, because then you'd just be moving your lock-in. The answer is an AI Native Data Layer: an open, central data layer on PostgreSQL, fully in your own hands, that all your business software connects to.
For SAP companies, the strength is precisely that it's not an all-or-nothing decision. SAP stays the heart of finance and logistics for as long as you want it to. The data layer alongside it becomes the place where your customer view, reporting, portals and AI live: your webshop and customer portal run on your own database without an indirect access debate, dashboards combine SAP data with all your other sources, and AI chat answers questions about your own customers and orders. Every solution on top is interchangeable without data loss, because the data sits underneath it, not inside it.
The cost model is accordingly simple, as the overview in chapter 2 shows. And because the data layer is open and portable, you can always take it with you. Away from us too; that keeps everyone sharp. How that platform fits together is explained in full in the whitepaper on the AI Native Data Layer.
| aspect | everything in sap | open data layer alongside |
|---|---|---|
| access to your data | Through SAP screens, licenses and the partner | Direct: it's your database |
| integrations and portals | Indirect access turns every integration into a licensing question | Webshop and portal run on your own data, no discussion |
| customer view and reporting | Spread across modules, assembled through exports and Excel | One complete, live customer view across all your sources |
| changes | Through the partner, in ABAP or configuration | Built around your way of working, changes in days |
| AI on your business data | Within SAP's offering and licenses | Every AI application connects directly to your own data layer |
| ownership | Data in the vendor's model and systems | Data, model and environment are fully yours |
Every good migration starts with knowing what you have. That's why the first step is always a data scan: we look at your SAP environment together and map out which data lives where, which customizations are running and what the quality of the data is. With a test export, we show you what your customers and orders look like in an open data layer.
After that, you know exactly where you stand: what belongs in-house, what SAP is genuinely still needed for, and what the migration involves. Even if the conclusion is that everything stays as it is for now, because that happens too, you'll have a documented picture of your own data. That's never wasted work, especially not with 2027 on the horizon.
And Repeat helps SMEs bring their data and software fully in-house, with an AI-native data layer as the foundation. Unlocking data from systems like SAP is a logical part of that: the data is already there, it just needs to go back to its owner. One conviction runs through everything: your data and your software should belong to you, not to a vendor.
Book a no-obligation data scan. We'll map out your environment and use a test export to show you what your data looks like in-house. Honest advice, even when that advice is "stay put for now".