Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP BW4HANA sizing — the modelling decisions that set the footprint

As of 2026-08-14

There is no public formula that sizes a BW/4HANA system, and a page that offers one is selling a guess. Sizing is produced by running SAP's own sizing procedure against your system and your data, and the output is specific to that estate. What can be stated usefully in advance is which modelling decisions multiply the footprint — because they are decided by consultants during migration, and they move the answer far more than any headroom percentage applied at the end.

The aDSO type is the biggest lever you control

Every aDSO is one table on the HANA side; what makes it behave like a staging area, a consolidated store or a planning persistence is the type chosen at creation. The storage consequence is not marginal.

A Standard aDSO carries three layers — an inbound queue, an active table and a change log — for roughly three times the footprint of the data itself. A write-optimised aDSO carries only the inbound queue, at roughly one times. A direct-update aDSO carries only the active table, also at roughly one times.

So a staging layer modelled as Standard rather than write-optimised triples its own footprint and adds an activation cost that no HANA tuning will recover. Standard is the right default for business-layer objects — around eighty per cent of modelling — and the wrong default everywhere else.

Activation cost is the other half of the sizing question

Sizing conversations concentrate on memory and ignore the operation that actually shapes the daily window. Activation is the Standard-aDSO operation that consolidates inbound records into the active table by key, computes deltas and writes the change log — the expensive step in BW/4HANA loading.

A very large Standard aDSO with daily activation is slow and costly. The same data staged in a write-optimised object with a Standard business layer downstream is fast and cheap, and the difference is a modelling decision taken in an afternoon.

This is why a sizing exercise run against a converted model tells you about the model you converted. Sizing a lift-and-shift sizes the debt, not the requirement.

The dual-run footprint nobody sizes

If the route to the target platform runs through a bridge, the customer pays twice for the overlap: the target platform's capacity consumption plus the embedded legacy footprint, simultaneously, for as long as the overlap lasts.

A documented sunset date in the architecture decision is what separates a two-year overlap from a seven-year fixture. It is a sizing decision as much as a governance one, because the second copy is paid for monthly.

The corollary is that sizing at the start of a multi-year coexistence and never re-running it is the standard error. A migration cadence that actually retires objects makes the footprint decline; without one, it does not.

How to get a number you can defend

Run SAP's sizing procedure against the actual system rather than against an estimate of it, and do it after the modelling decisions above are settled — not before, because the same data can produce very different footprints depending on type choices.

Size the target model, not the source estate. If twenty to thirty per cent of objects are heading for manual redesign and a share of the estate is not travelling at all, sizing the source over-provisions by exactly the amount you were planning to remove.

And re-size after the first migration wave. A number produced before any object moved describes an estate that no longer exists.

What we cannot assert

We publish no sizing figures — no memory numbers, no node counts, no capacity-unit estimates — because none of those can be honestly stated without the customer's own data volumes, retention rules and load profile. The multipliers above describe relative storage behaviour between object types, not absolute requirements, and they do not replace running SAP's sizing procedure on the system itself.

Frequently asked

Is there a BW/4HANA sizing formula?

Not a public one that is worth applying. The authoritative number comes from running SAP's sizing procedure against your own system and data; anything else is a placeholder that will be re-done before hardware or capacity is committed.

What single decision changes the footprint most?

The aDSO type. Standard carries an inbound queue, an active table and a change log for roughly three times the data footprint; write-optimised and direct-update carry roughly one times. Staging layers modelled as Standard are the classic overspend.

Should we size before or after the migration design?

After. Type choices, what is retired and what is redesigned all move the answer, so a number produced against the source estate sizes the model you are trying to leave behind.

Does a bridge or coexistence change sizing?

Yes, and it is the most commonly missed line: during the overlap the customer pays for the target platform's consumption and the legacy footprint at the same time. Without a documented sunset date, that overlap tends to extend for years.

What this page is built on

Read next