The step, not the slope
Most IT costs behave like a slope. You add a user, you pay for a user. You add storage, you pay for storage. The relationship is roughly linear and roughly predictable.
HANA in-memory licensing does not behave like that. It is sized in blocks, and there is no partial step between them. An estate sitting comfortably inside its current tier can cross the boundary through ordinary growth and land on the next one, at which point the cost moves in a single jump that has nothing to do with any decision anybody took.
That is why the conversation usually starts the way it does: the licence went up, the user count did not, and nobody can immediately explain it.
Growth has no owner
The reason this catches people is structural rather than technical. Data volume is the one line in an SAP estate that grows on its own and belongs to nobody.
Finance owns the budget but does not see the tables. IT owns the system but is not asked to reduce it. The business owns the transactions but has no visibility into what they cost. Support contracts cover keeping the system running, not making it smaller. So the volume grows, quietly, for years.
Then a renewal, an audit or a migration forces someone to look, and the number is much larger than anyone expected.
Where the volume usually sits
When we measure an estate, the distribution surprises people more often than the total does. The growth is rarely spread evenly. It concentrates in a small number of objects, and those objects are frequently not the ones anyone would have guessed.
Application logs, change documents, idoc tables, material documents and financial line items tend to dominate. A large proportion of what sits in memory is historical, closed, and read perhaps once a year for a report that could be served from an archive without anyone noticing the difference.
That is the useful finding. Not that the estate is large, but that a significant part of it is doing nothing except occupying the most expensive storage tier you own.
Why this is different from other cost levers
Most SAP cost reduction takes a long time to show up. Process improvements pay back over years. Licence reclassification depends on a renewal cycle. Infrastructure changes need a migration.
Archiving is unusual in that it can move a number inside the same financial year. If reducing volume takes an estate back under a licensing threshold, the saving is not a projection. It is a line on the next invoice.
It also compounds with anything else you are planning. Every terabyte removed before a migration is infrastructure you do not provision in the target system, downtime you do not spend moving it, and subscription cost you do not carry afterwards.
The part people get wrong
The common mistake is treating this as a one-off clean-up. An estate that is archived once and then left alone refills, because the processes that generated the volume are still running.
What actually solves it is a retention policy that lives in the system rather than in a document: rules for what is kept, for how long, and what happens at the end of that period. That turns the exercise from a project into a property of the landscape, and it is also the thing that makes the position defensible when a regulator or an auditor asks.
Where to start
Ask for a table-level breakdown of your largest objects and how fast each one is growing. It is a short piece of work and it produces a number you can act on.
Most teams have never seen this analysis for their own estate, which is precisely why the licence increase arrives as a surprise rather than as a forecast.