The hidden cost of SAP S/4HANA migration: in-memory pricing on cold data

The board approved S/4HANA on a business case eighteen months ago. The case had a clean structure: a one-time migration cost, an ongoing license-and-hosting cost, and a productivity uplift on the operational side. Three lines. Easy to read.

Two quarters after cutover, the actual recurring cost is materially higher than the case projected. The CFO asks for an attribution. The architecture team produces it: data volume. The platform was sized to host more data than the case assumed, the license tier reflects the actual size, the hosting reflects the actual size, and every quarter of operational data growth pushes the number higher.

The honest summary is that the TCO model used did not have a data-volume line item. The line item the model did not contain is the largest recurring delta against the case.

This is the most common form of S/4HANA cost surprise, and it is not exotic. It is what happens when the migration is modeled as a one-time event and the data volume is modeled as a fixed input rather than a growing line item that compounds with operational time.

Step One — The Wrong Assumption

Migration cost is migration cost.

"We did the math. The case is approved. The recurring cost is what the case says it is."

— Standard pre-migration board position

The assumption is that the recurring HANA cost is a function of the migration's design decisions — node count, deployment model, license tier — and that those decisions are fixed at cutover. They are not. They are fixed at migration sizing, which is itself a function of data volume, which is a function of retention discipline. A migration sized to twelve years of unreduced operational data carries a recurring HANA cost shaped by those twelve years, paid every quarter, indefinitely.

Step Two — The Partial Signal

The post-cutover finance review finds the line that was not in the case.

The partial signal is the first post-cutover finance review. The variance against the business case lands on a single line — the recurring HANA cost — and the explanation traces back to data volume that was not modeled. The conversation immediately turns to whether the case should have been different. The architecture team's honest answer is that the case modeled what the available inputs supported: the case team did not have the access-age analysis that would have shown the data-reduction opportunity, and the migration partner had no commercial incentive to perform it.

Step Three — The Failed Fix

Renegotiating the HANA contract instead of reducing the data.

The failed fix is contract-side. The platform team and procurement engage SAP and the hyperscaler, negotiate a better unit price, and report a cost reduction to the CFO. The reduction is real, but it is one-time, and it does not change the growth trajectory of the bill — because the growth driver is data volume, not unit price. Twelve months after the negotiated rate takes effect, the bill is back where it started, plus the next year of growth, and the team is out of negotiating room.

The fix is failed because it treats a placement problem as a procurement problem. Procurement compresses the per-unit number; the unit count keeps growing.

Fig. 1 — Recurring HANA cost is shaped at migration sizing. The retention discipline that exists before sizing is what determines what the bill looks like after cutover.

Step Four — The Real Failure

The actual failure is missing the data-volume line item from the case.

The real failure is in the model. S/4HANA TCO models that omit a data-volume line item are modeling a fixed cost where the cost is actually variable, and they are modeling it at the highest-cost tier. The discipline that produces accurate cases — and accurate recurring costs — adds two things: a data-reduction phase before migration sizing (so that the sizing reflects the dataset the business actually operates on), and a retention regime after migration (so that the dataset does not regrow into the highest-cost tier by default).[1]

Programs that have built the model this way report recurring HANA costs at a meaningful discount to programs that have not — typically the discount that comes from sizing the platform to operational reality rather than to twelve years of unreduced history.

Step Five — The Definition

Now the definition lands.

S/4HANA TCO with a data-volume line item is the discipline of modeling recurring SAP cost as a function of data volume rather than as a fixed input — making the retention regime and the archiving design first-order cost levers rather than afterthoughts.

Reading it that way changes the order of operations. The retention work and the archiving design move into the business-case phase. The migration sizing happens against the reduced number. The recurring cost reflects the reduced number, every quarter, for as long as the platform runs.

What Solix Enforces

Data reduction as a recurring TCO lever, not a one-time cleanup.

What Solix runs in this category is the data-volume line item itself: pre-migration archiving and NLS design that lowers the recurring HANA bill at sizing, plus the ongoing retention regime that keeps the platform sized to current operational reality. The recurring cost becomes a managed number rather than a discovered one.

Three things to do this week

• Add a data-volume line item to your TCO model. Model recurring HANA cost as a function of operational data volume, with a clear assumption about the percentage of historical data retained in memory. The line item makes the cost driver visible to the business case team.
• Pull post-cutover variance back to data volume. For shops already past cutover, run the variance-to-case analysis with data volume as a candidate explanation. The exercise tends to surface the gap between case assumption and actual data-placement reality.
• Treat retention as a recurring cost discipline. Annual retention reviews, run by records management and platform together, with a measurable reduction target. Retention discipline that is treated as a one-time project regresses to the mean; retention as a recurring discipline holds the cost line flat.

References

• SAP Help Portal — Nearline Storage for SAP BW and SAP BW/4HANA. Nearline storage is the SAP-defined mechanism that turns data volume from a fixed cost into a managed one.
• SAP Help Portal — SAP Information Lifecycle Management (ILM) — Overview. ILM is the policy layer that makes retention sustainable across operational time.
• Gartner press — Gartner Forecasts Worldwide Data Management Software Spending. Gartner's data-management forecast tracks the cost-tier-optimization spend pattern that S/4HANA TCO models often omit.
• Forrester — Forrester Wave: Data Management for Analytics. Forrester's research on data-platform economics underlines the cost-curve impact of unmanaged data growth.
• IDC press — IDC Worldwide Global DataSphere Forecast. IDC's global datasphere forecast establishes the growth rate that any TCO model needs to assume.