India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP Cloud Readiness Assessment: Sizing, Versions, Code and Interfaces
An SAP Cloud Readiness Assessment is a technical inspection of an SAP landscape that has already been approved to move to cloud, confirming what must change before migration. NTSPL sizes HANA memory and SAPS from live workload data, checks OS, database, kernel and Unicode status, screens add-ons and custom code, and catalogues every interface, for Basis leads and programme managers preparing a migration.
Delivered on
In scope
Why Database Size on Disk Is the Wrong Starting Point for SAP Sizing
The decision to move SAP has been taken, a hyperscaler has been shortlisted, and a partner has already quoted a 6 TB HANA instance based on the database size on disk. That quote is usually wrong in both directions. Compressed HANA footprints differ wildly from Oracle or DB2 sizes, ten-year-old change documents and IDoc tables inflate the estimate, and nobody has checked whether the non-Unicode BW system, the third-party tax add-on or the 140 RFC destinations to plant systems will survive the move. Discovering these after the build has started costs weeks.
NTSPL runs the assessment from evidence inside the system, not from questionnaires. We execute the HANA sizing report on each production system, pull ST03N workload and ST06 peaks for SAPS, run SAP Readiness Check where S/4HANA is the target, and export SM59, WE20 and SOAMANAGER configurations into one interface register. The output is a set of decisions a build team can execute: certified instance per system, required upgrades, blocked add-ons, cleanup actions and a sequenced list of pre-migration fixes.
Signals That a Landscape Needs a Technical Readiness Check First
Signals you need SAP Cloud Readiness Assessment
- A cloud budget is approved but HANA memory estimates from two partners differ by more than 40 percent for the same production system.
- The landscape includes at least one system on an out-of-support OS or database release, such as Windows Server 2012 after its extended security updates ended on 13 October 2026.
- More than 100 RFC, IDoc or web-service interfaces connect SAP to plant MES, dealer portals, banks or GST systems and no current register exists.
- Third-party add-ons for tax, warehouse, payroll or document management are installed and nobody has confirmed their S/4HANA or cloud support status.
- A non-Unicode system or a release below ECC 6.0 EhP6 is still in productive use somewhere in the landscape.
When to choose something else
- The question is still whether SAP should move at all, or RISE with SAP versus your own cloud account. That is a strategic SAP cloud assessment with a business case; the technical check comes after.
- Only a handful of non-production systems are moving for a short project. A lighter sizing exercise during the infrastructure build is enough.
- SAP is already running on a hyperscaler and the problem is cost or performance. SAP Cloud FinOps or HANA architecture review fits better.
What the Readiness Assessment Inspects in Each SAP System
HANA memory and SAPS sizing
HANA sizing report output per ABAP system, BW sizing for BW systems, and ST03N and ST06 CPU peaks converted to SAPS, giving a recommended memory figure with growth and cleanup scenarios.
Release and platform matrix
SAP kernel, NetWeaver and EhP level, database, OS and Unicode status for every system, mapped against the Product Availability Matrix and target cloud OS images.
Add-ons and custom code
Installed add-on list checked for S/4HANA compatibility and cloud support, plus custom-code volume, usage from SCMON or UPL data and ATC findings against the simplification database.
Interface and dependency register
Every SM59 destination, IDoc partner profile, web service, file interface and database link, with owner, protocol, direction, volume and whether it crosses a plant or partner network.
Data volume and housekeeping
Top tables by size, archiving status and basis tables such as change documents, application logs and IDoc tables that can be reduced before migration to shrink the HANA target.
Evidence Pipeline: From System Exports to a Signed Readiness Register
SAP Readiness Evidence Pipeline from System Exports to Readiness Register
System-level exports are collected from each SAP instance, normalized into one landscape model and assessed against SAP and hyperscaler compatibility sources. Findings are scored and published as a readiness register that feeds sizing sheets and the migration backlog.
Select any component
SAP Readiness Evidence Pipeline from System Exports to Readiness Register: click any of its 10 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Matching Sized SAP Systems to Certified Instances on Each Cloud
Sized systems are mapped to SAP-certified EC2 types available in Mumbai or Hyderabad, and the SAP Lens is used to check readiness gaps in operations and resilience before build.
Sizing is aligned to certified M-series and E-series VMs and checked against regional and zonal availability in Central India before an Azure Center for SAP solutions deployment is planned.
Memory figures are mapped to certified M-series or X4 shapes, and Workload Manager rules are reviewed early so OS and configuration gaps are fixed during readiness rather than after build.
Readiness Calls That Change the Migration Plan
Clean up before sizing or size as-is
If change documents, application logs, IDocs and workflow tables exceed 20 percent of the database, model sizing twice and commit to housekeeping before migration. Sizing to the cleaned figure often drops a production system one certified instance size, which saves more over three years than the cleanup effort costs. Where the business refuses archiving, size as-is with 15 percent growth headroom.
Unicode conversion timing
A non-Unicode ECC must become Unicode before or during the move to HANA and S/4HANA. For systems under 2 TB with a single code page, combine conversion with the database migration in one downtime. Above that, or with multiple code pages, schedule a separate conversion weekend at least eight weeks earlier so the S/4HANA cutover keeps a predictable runtime.
Blocked add-ons
Classify each add-on as supported, supported after vendor upgrade, replaced by standard S/4HANA function, or blocking. A blocking add-on with no release plan should be uninstalled or replaced before conversion; SAP Readiness Check results alone are not enough, so NTSPL asks the vendor for a written support statement for the target release and cloud.
Treatment of unused custom code
Use at least six months of usage data from SCMON or UPL. Objects with zero executions in that period should be retired instead of remediated. In most ECC systems this removes 35 to 60 percent of custom objects from scope and directly shortens the remediation stream in the migration plan.
Four-to-Six Week Readiness Programme by System Tier
Access, scoping and system list
Agree the systems in scope, create read-only technical users and confirm usage-data collection has been active long enough.
Automated collection runs
Execute sizing reports, workload extracts, Readiness Check data collection and interface exports on production and one representative non-production system.
Compatibility and code analysis
Assess simplification items, add-ons, ATC results, PAM support and Unicode status, and build the interface register with owners.
Sizing and instance mapping
Produce memory, SAPS and storage-throughput figures per environment and map them to certified instance types on the chosen cloud.
Readiness register review and sign-off
Walk the blocker list with Basis, functional and integration leads and hand a prioritized pre-migration backlog to the migration planners.
What you receive
How We Measure a Complete Readiness Baseline
| KPI | Typical target |
|---|---|
| Systems with sizing from measured data | 100 percent of production systems |
| Interfaces with a named owner and network path | At least 95 percent of discovered interfaces |
| Variance between sized and post-migration peak HANA memory | Within plus or minus 15 percent |
| Blockers discovered after migration build starts | Zero critical, fewer than 3 minor |
Where SAP Readiness Assessments Usually Go Wrong
| Risk | How NTSPL prevents it |
|---|---|
| Workload data covers too short a window and misses year-end or festive peaks | NTSPL requests 13 months of ST03N history and, where unavailable, adds peak factors agreed with finance for close and with sales for Diwali and dealer push periods. |
| Interfaces hidden in ABAP code or OS scripts are missed by configuration exports | We scan custom code for hard-coded destinations, file paths and FTP calls, and review cron jobs and Windows scheduled tasks on application servers. |
| Add-on vendors give verbal assurances that do not hold at conversion time | Written support statements per target release and cloud are logged in the register; anything unconfirmed stays rated as a blocker. |
SAP Readiness Check or a full SAP cloud readiness assessment: what is the difference?
SAP Readiness Check is a free SAP tool that analyses one system for S/4HANA conversion: simplification items, add-ons, custom code and some sizing. It is necessary but narrow. It does not tell you which certified cloud instance to buy, whether your OS and database releases are supported on the target image, how many interfaces cross plant networks, or how much cleanup would shrink HANA memory. A full readiness assessment uses Readiness Check as one input and adds landscape-wide sizing, platform compatibility, interface mapping and a prioritized fix list. If you are moving more than two production systems, the full assessment pays for itself in avoided rework.
Key facts: SAP Cloud Readiness Assessment
SAP Cloud Readiness Assessment in Practice
2 SAP Cloud Readiness Assessment scenarios, from Two-wheeler OEM and Fertilizer co-operative, plus related platform case studies.
Two-wheeler OEM cuts sized HANA memory from 6 TB to 3.4 TB before buying capacity
Fertilizer co-operative finds a non-Unicode blocker 9 months before its Azure move
Auto-ancillary maker converts ECC to S/4HANA on AWS inside a 48-hour downtime window
API manufacturer moves a GxP-validated SAP landscape to Azure without re-validation delays
SAP Cloud Readiness Assessment: Frequently Asked Questions
How much does an SAP cloud readiness assessment cost?
For a landscape of 3 to 5 production systems with their non-production tiers, the effort is typically 25 to 45 consultant-days over four to six weeks. The main variables are the number of production systems, whether BW and PI/PO are in scope and how much custom code needs ATC analysis. NTSPL quotes a fixed fee after a one-hour scoping call.
Do you need access to our production SAP system?
Yes, but read-only. We request a technical user with a time-bound role covering the sizing report, workload monitors, interface configuration displays and Readiness Check collectors. No transactional data is extracted; we take metadata, table sizes and counts. Collection jobs run during low-load hours agreed with your Basis team.
Can the assessment be done if we are moving ECC to cloud first and converting to S/4HANA later?
Yes. For a lift of ECC, we focus on sizing, OS and database support on the target cloud, Unicode status and interfaces. We still run Readiness Check so the later conversion inherits a known simplification and custom-code backlog, rather than discovering it two years later.
How does the assessment handle Indian statutory interfaces?
We list e-invoicing IRP, e-way bill, GST return and TDS interfaces separately, including whether they use SAP's own solutions, a GSP or a custom adapter. These carry legal deadlines, so their connectivity, certificates and cutover sequence get flagged early for the migration planners and for the DPDP Act 2023 data-flow inventory.
Will the sizing hold if business volumes grow after migration?
The sizing sheet includes growth scenarios, usually 15 and 30 percent annual data growth, and shows when each would force a larger certified instance. That lets you plan reservations and archiving together instead of being surprised by a memory limit in year two.
What if a blocker cannot be fixed before the planned migration date?
We present the options with dates: delay the move, migrate with the blocker isolated, for example keeping one add-on on a separate system, or replace the function with standard S/4HANA capability. The steering committee decides with the cost and risk of each written down.