The initial HANA sizing for an S/4HANA system is done before anyone knows what the actual workload looks like. The sizing document produced during a migration project is an educated estimate: source system data volume converted to projected HANA column store requirements, user count projections multiplied by per-user memory factors, batch workload estimates based on ECC job runtimes. The methodology is sound. The inputs are incomplete, because you cannot accurately model production behavior before production exists.
Some sizing assumptions turn out to be conservative and the system runs with comfortable headroom. Some turn out to be optimistic and the memory trajectory after go-live heads toward the allocation limit faster than expected. Either way, the sizing document becomes irrelevant the moment production starts, because the system is now generating real data that replaces every estimate in that document with a measurement.
This article covers what to measure post-go-live to validate whether the sizing holds under real workload, how to project future memory and storage needs from post-go-live data rather than from pre-migration estimates, when sizing adjustments become necessary, and how to build ongoing capacity planning from the monitoring data the system continuously produces.
Why post-go-live sizing validation matters differently from pre-migration sizing ?
What the initial sizing got right, and what it could not have known
Pre-migration HANA sizing estimates are based on three inputs: the ECC source data volume, the expected transaction load, and a set of multipliers and growth assumptions from SAP’s sizing methodology. The source data volume is usually accurate. The transaction load is usually a reasonable approximation. The growth assumptions are guesses calibrated against industry averages.
What sizing methodology cannot account for is the specific behavior of custom ABAP programs that were not part of the sizing analysis, the memory consumption pattern of custom calculation views built during the project, the actual delta merge frequency under production write volumes, and the row store consumption of tables that the project team did not identify as memory-significant. None of these are negligence. They are genuinely unknowable before production starts.
There is also a category of post-go-live memory growth that has nothing to do with the sizing assumptions: data growth from business operations. An S/4HANA system that went live with 1.2 TB of migrated data generates new data at a rate determined by transaction volume. After 18 months of production, the database has grown. If that growth rate was underestimated in the sizing, the memory trajectory will exceed what the hardware was sized for earlier than expected.
The first 90 days : when the real memory profile emerges
The memory behavior of an HANA system in the first 90 days of production is not stable. It evolves as the working dataset warms into memory, as new data accumulates, and as the column store’s internal structures optimize through delta merge cycles.
Day one after go-live, the system is in a cold state. Column store partitions that exist on disk are not all loaded into memory. As users and batch jobs access data, HANA loads the required partitions. Memory consumption rises over the first days as the working dataset warms. This rise is expected and does not indicate a sizing problem. What indicates a potential sizing problem is memory consumption that continues rising beyond the expected steady state.
The steady state for a well-sized system is a memory utilization that stabilizes between 50% and 70% of the allocation limit under normal daily load, with higher peaks during month-end batch processing. If the system reaches 75% during the first week before a single month-end has run, the sizing probably needs revisiting. If it stabilizes at 60% through the first month including month-end, the sizing has headroom for the growth model.
This is why post-go-live monitoring that captures the memory trajectory daily over the first 90 days is more valuable than a snapshot check at day 30. The trajectory tells you whether the system is stabilizing or still growing, which determines whether the current sizing holds for the next 12 to 24 months or needs attention sooner.
Memory sizing validation: the metrics that matter
Peak used memory against the allocation limit
The allocation limit is the ceiling HANA will not exceed. It is configured in the global.ini file under the parameter global_allocation_limit, typically set at 90 to 95% of physical RAM to leave operating system headroom. This is the number that defines whether your sizing is adequate.
Post-go-live sizing validation requires tracking peak used memory as a percentage of the allocation limit, measured at the granularity of peak production load events: business hours peak, month-end batch peak, and year-end processing peak if applicable. Not daily averages. Peaks.
The thresholds that define the sizing verdict are: peak utilization consistently below 70% of the allocation limit means the system is well-sized with room for growth. Peak utilization regularly reaching 80 to 85% means the sizing is adequate today but capacity planning needs to model the next 12 months explicitly. Peak utilization touching 90% means a sizing review is overdue. The sequence from 85% peak to an out-of-memory stop is shorter than most teams realize when it occurs during a high-load event like month-end close.
Reading M_MEMORY_OVERVIEW correctly
The view M_MEMORY_OVERVIEW in HANA provides the consolidated memory picture. The fields that matter for sizing validation are USED_PHYSICAL_MEMORY, ALLOCATED_PHYSICAL_MEMORY, and FREE_PHYSICAL_MEMORY at the service level, combined with the instance-level allocation limit from M_CONFIGURATION.
The number most often misread is USED_PHYSICAL_MEMORY. It is the current active memory consumption. It does not include memory that has been allocated by HANA but is not actively occupied by data at the moment of reading: memory fragmentation, pre-allocated buffers, and reserved space. The more useful number for sizing assessment is ALLOCATED_PHYSICAL_MEMORY, which reflects how much memory HANA has claimed from the operating system. The difference between ALLOCATED and USED is the overhead that does not shrink even when data is unloaded.
A system where ALLOCATED is at 85% of the allocation limit but USED is at 65% appears to have comfortable headroom on the used metric. The operational constraint is ALLOCATED, not USED. If ALLOCATED continues growing and approaches the limit, HANA will start triggering aggressive column store unloads to free space, which degrades performance. Monitor ALLOCATED, not just USED.
Column store loaded data: what is actually consuming memory
The largest contributor to HANA memory consumption in an S/4HANA environment is column store table data. The view M_CS_TABLES shows the memory consumption per column store table, including the split between main store (compressed, read-optimized) and delta store (write-optimized, uncompressed).
Post-go-live sizing validation should include an analysis of the top 20 tables by memory consumption at the 30-day mark and at the 90-day mark. Two things to look for. First, tables that have grown significantly between day 30 and day 90, which identifies the fastest-growing data areas and allows more accurate growth projection. Second, tables where the delta store is large relative to the main store, which indicates that delta merges are not keeping up with the write volume on those tables and that the effective memory consumption is higher than it needs to be.
A delta store that represents more than 20% of a table’s total memory consumption is worth investigating. Tuning the merge threshold or triggering a manual merge for the largest tables reduces memory consumption without any infrastructure change. This kind of in-system optimization is often available before a resizing decision is needed, and it is only visible when column store memory is being monitored at the table level rather than just at the aggregate.
| Note: M_CS_TABLES can return thousands of rows in a large S/4HANA system. Query it with a filter on MEMORY_SIZE_IN_TOTAL > 1000000000 (1 GB) to focus on the tables that materially affect the memory picture. The top 50 tables by memory size typically account for 60 to 70% of total column store memory consumption. |
Projecting future memory needs from post-go-live data
The growth rate calculation and why it requires more than 30 days of data
A memory growth rate calculated from 30 days of post-go-live data is unreliable as a planning input. The first 30 days include the cold-start loading phase, which inflates the growth rate compared to steady state. They may or may not include a month-end cycle, which is the highest-load event and the one that most affects peak memory consumption. And 30 days is not long enough to distinguish a linear growth trend from a logarithmic one, which has very different implications for when the system needs to be resized.
Ninety days gives a usable growth rate for linear projection. Six months gives a growth rate that can distinguish linear from accelerating trends. The practical approach is to start projecting conservatively from the 90-day data and to refine the projection as more data accumulates.
The calculation is straightforward: take the memory consumption at day 90 minus the memory consumption at day 30 (excluding the cold-start phase), divide by 60 days to get a daily growth rate, and project that rate forward. Apply it to the current headroom between peak ALLOCATED memory and the allocation limit. The result tells you how many days at the current growth rate before the peak reaches the 85% warning threshold.
If that number is less than 6 months, a sizing review is warranted now. If it is 12 to 18 months, a sizing review in the next quarterly planning cycle is appropriate. If it is 24 months or more, the current sizing is comfortable and growth monitoring on a monthly basis is sufficient.
When to resize : the decision criteria worth setting in advance
Resizing an HANA system, whether on-premise or in a cloud environment, has lead time. On a hyperscaler, changing the instance type for a production HANA system requires a planned maintenance window and typically involves a brief restart. The process is faster than on-premise hardware upgrades but still not immediate. The decision needs to happen 4 to 6 weeks before the constraint becomes critical, not when the system is already at 88% memory utilization under production load.
Setting decision criteria in advance rather than reacting to memory pressure serves two purposes. It removes the urgency from the decision, which improves the quality of the analysis. And it creates a clear trigger that operational monitoring can surface: when the monitoring data shows that peak memory utilization has reached X% for three consecutive month-end cycles, initiate the sizing review process.
A practical set of criteria: initiate a sizing review when peak utilization during any month-end cycle exceeds 82% of the allocation limit. Begin the resizing process when the 6-month growth projection indicates the system will reach 85% peak within the next quarter. These are lagging indicators, not trailing ones, which gives time to act before the constraint becomes operational.
| In practice: On RISE with SAP environments, memory resizing requests go through SAP rather than directly to the hyperscaler. The process involves a formal sizing review with SAP and a change request. Factor in 6 to 8 weeks of lead time rather than the 2 to 3 weeks typical for a direct hyperscaler instance type change. Build this into the decision trigger timing accordingly. |
CPU and storage: the sizing dimensions that get less attention
CPU thread utilization under peak load
HANA CPU sizing is often treated as a secondary concern relative to memory, because HANA is memory-bound for most workloads. That is mostly correct. Where CPU becomes the constraint is in parallelism-heavy operations: large analytical queries that spawn dozens of execution threads, delta merge operations running concurrently with peak business hours, and year-end closing batch runs that execute multiple concurrent reporting jobs.
Post-go-live CPU sizing validation means observing CPU thread utilization during peak events, not daily averages. M_SERVICE_THREADS shows the active thread count and their states during a query or batch operation. A system where all available CPU threads are in active state simultaneously during month-end close has no headroom for concurrent load. The user experience during that window is degraded because every additional query competes for threads that are fully occupied.
The specific scenario to watch for is a system that looks fine on CPU metrics daily but shows CPU thread saturation during exactly the 3 to 4 hour window of the month-end batch run. That pattern does not appear in daily average metrics. It is only visible in the peak utilization data during those specific events, which is why monitoring CPU at peak events, not just at daily average, matters for sizing validation.
Data volume growth rate and the log volume configuration
Data volume growth after go-live is driven by the rate of new data creation: new documents posted, new movements recorded, new analytics aggregates computed. The growth rate from the first 90 days is the most accurate basis for storage capacity planning available, because it reflects the actual transaction volume of this specific production environment.
Calculate data volume growth by querying M_DISK_USAGE weekly for the first 12 weeks after go-live and recording the DATA component size each time. The weekly delta gives the growth rate. Project it forward over 24 months. If the projected data volume at month 24 exceeds 80% of the allocated storage, either storage expansion or data lifecycle management needs to be planned within the first year.
Log volume sizing is a different problem. Log volume does not grow with data volume in the same way. It accumulates redo log until log backups are taken, at which point backed-up segments become overwritable. The risk is not gradual growth to a limit but sudden exhaustion if log backups stop running. The post-go-live check for log volume is not a growth rate calculation but a confirmation that the backup interval is calibrated to the production write throughput and that the log volume is sized with enough buffer for a backup window failure of at least 2 hours without reaching 100% utilization.
Data lifecycle and its effect on the sizing trajectory
How archiving changes the memory picture ?
HANA column store data consumes memory proportional to the volume of data loaded. The most direct way to reduce memory consumption growth, beyond hardware resizing, is to remove data from the database that the business no longer needs to access in production operations. This is data archiving, and its effect on memory is direct: archived data that no longer resides in HANA does not consume memory.
Most S/4HANA projects plan for archiving as a future activity. It rarely happens in the first year of production. The practical implication for sizing is that the memory growth trajectory in year one does not include the offsetting effect of archiving that was assumed in the initial sizing estimate. The sizing may have been calculated with a 3-year archiving cycle assumed. The actual first three years may have no archiving at all, making the growth trajectory steeper than the sizing document projected.
Post-go-live monitoring that tracks data growth by functional area, such as financial documents, material movements, purchase orders, gives the business context to have an informed conversation about which data areas are growing fastest and which archiving programs would have the most sizing impact. Without that data, archiving decisions are made based on compliance requirements or project convenience rather than on memory impact.
Cold data in HANA that should not be there
After 12 to 18 months of production, most S/4HANA systems contain a significant volume of data that was active in year one but is now accessed rarely or never. Historical financial documents from closed periods, completed production orders, shipped sales orders from two years ago. This data is stored in the column store, occupies memory, and is loaded during table scans even when the query only needs current data.
HANA’s native table partitioning capability allows historical data to be segregated into partitions that are marked as unloaded, meaning they do not consume memory unless explicitly accessed. Implementing range partitioning on date fields for large transactional tables keeps current data warm in memory while allowing historical data to remain on disk until needed.
The monitoring signal that indicates cold data is consuming meaningful memory is a high ratio of total column store data size to the volume of data accessed by production queries over the past 30 days. If a table has 200 GB of data and monitoring shows that only 15 GB of it has been accessed in the past month, 185 GB of that table’s memory footprint is cold data that partitioning could remove from the working memory set. M_CS_UNLOADS shows which table parts have been unloaded due to memory pressure and subsequently reloaded, which is a proxy for identifying the least-accessed data structures.
From sizing validation to ongoing capacity planning
The monthly capacity review cadence
Sizing validation is a project deliverable. Capacity planning is an operational discipline. The transition from one to the other happens around the 90-day mark, when the post-go-live memory profile has stabilized enough to support reliable projection.
A monthly capacity review does not require a long meeting or a complex report. It requires four numbers, updated monthly: current peak memory utilization as a percentage of the allocation limit, current data volume growth rate in GB per month, projected date at which peak memory utilization will reach 82% based on the current growth rate, and projected date at which data volume will require storage expansion. With those four numbers updated monthly, the team has 60 to 90 days of advance warning for any capacity constraint before it affects production operations.
The review becomes consequential when one of those numbers moves materially. A growth rate that has accelerated from 15 GB per month to 35 GB per month over three consecutive months is not noise. It is a signal that something has changed in the data creation pattern, whether business growth, a new integration generating more records, or a housekeeping job that stopped running. The monthly review is the mechanism that catches this change while the runway to act is still months rather than weeks.
What to report and to whom ?
The operations team needs the raw metrics: HANA memory utilization trend, data volume growth, delta merge health, log volume status. These go into monitoring dashboards where the Basis team can see them continuously.
IT management and business leadership need something different: a simple signal on whether the current sizing covers the next 12 months and what the planning horizon is for the next sizing decision. Not the raw HANA memory numbers, but the conclusion those numbers support. A monthly capacity summary with three lines, current headroom, projected date of next decision point, and recommended action if any, is more useful to a decision-maker than a chart of M_MEMORY_OVERVIEW readings.
The distinction matters because sizing decisions involve budget, procurement, and planning lead time. The people who approve those decisions need to understand when a decision is required, not how HANA memory management works. Translating monitoring data into business-relevant capacity signals is part of the capacity planning function, not a separate communication task.
The sizing document is a starting point, not a destination
Every sizing document produced for an S/4HANA migration has an expiry date: it is valid until production starts. After that, actual measurement replaces estimation as the basis for every capacity decision.
The teams that get post-go-live sizing right are the ones that treat the transition from estimation to measurement as a deliberate process. They start monitoring memory trajectory from day one, they establish the baseline metrics at 30 and 90 days, they set the decision criteria for when a sizing review is triggered, and they report capacity status monthly before the topic becomes urgent.
The teams that get it wrong are the ones that treat the sizing document as correct until something breaks. Those teams discover that the sizing was optimistic at the first month-end when memory utilization spikes to 91% during the closing batch run, with no runway to procure additional capacity before the next month-end four weeks later.
Post-go-live monitoring does not change the hardware. It changes the amount of time available to make informed decisions about the hardware. That time is either used proactively or consumed in reactive crisis management. The difference between the two is continuous measurement.
