Assessing SAP Workloads for Migration
Learn how to assess existing SAP landscapes for Azure migration using sizing tools, dependency mapping, SAP Readiness Check, Early Watch Alerts, and Azure Migrate — then map SAPS benchmarks to the right Azure VM SKUs.
Why assessment comes first
🏗️ Raj is already thinking about VM sizes. “I know our system — I have been running it for fifteen years. Can we just pick some VMs and go?”
☁️ Mei shakes her head. “That is how migrations fail. You think you know, but you need data. How much memory does HANA actually need after conversion? What are your peak SAPS requirements? Which systems depend on each other? Assessment gives us the numbers to make confident decisions — and the evidence to convince Deepak the budget is right.”
Think of it like a house inspection before renovation.
You might have lived in your house for years, but before you knock down a wall, you need to know where the pipes are, which walls are load-bearing, and whether the electrical wiring meets code. Assessment is the inspection — it reveals what you cannot see from daily use and prevents expensive surprises mid-project.
The assessment toolkit
SAP and Microsoft each provide tools that work together. Here is the landscape:
| Tool | Who provides it | What it does | When to use it |
|---|---|---|---|
| SAP Readiness Check | SAP (via SAP for Me portal) | Analyzes your system for S/4HANA conversion readiness — custom code, add-ons, simplification items, business function activation | Before any S/4HANA migration to identify blockers and required code changes |
| Early Watch Alert (EWA) | SAP (automated report from Solution Manager) | Captures system performance baselines, resource utilization trends, and configuration recommendations over time | To establish current performance baselines and identify bottlenecks before migration |
| SAP Quick Sizer | SAP (web tool) | Estimates hardware requirements (SAPS, memory) based on throughput metrics like users, documents, or line items | For greenfield deployments or when you lack production performance data |
| Azure Migrate | Microsoft | Agentless discovery of SAP systems — identifies SIDs, instances, HANA topology, and dependency mapping | To build a comprehensive inventory of your SAP landscape and plan migration waves |
| SAP Note 1928533 | SAP | Lists SAP-certified configurations and supported Azure VM sizes for SAP HANA and SAP applications, including SAPS ratings, supported OS, and memory limits | When mapping your SAPS requirements to specific Azure VM SKUs |
SAP Readiness Check — your conversion checklist
The Readiness Check (accessed through the SAP for Me portal at me.sap.com) runs a series of automated checks against your existing SAP system. It answers the critical question: “What needs to change before we can run on S/4HANA?”
Key checks include:
- Simplification Item Check — identifies database tables, transactions, and functions that changed or were removed in S/4HANA
- Custom Code Analysis — flags your ABAP custom code that uses deprecated APIs or incompatible patterns
- Add-on Compatibility — verifies whether your installed add-ons are compatible with the target S/4HANA version
- Business Function Activation — checks which business functions are active and how they map to S/4HANA equivalents
🏗️ Raj scratches his head. “We have about 2,000 custom ABAP reports. This sounds like it could surface a lot of work.”
☁️ Mei nods. “It usually does. But it is far better to discover that now than during a go-live weekend. The Readiness Check gives you a prioritized list so you can start remediating custom code months before the migration.”
Exam tip: Readiness Check scope
The SAP Readiness Check evaluates S/4HANA conversion readiness — not Azure readiness. It tells you whether your SAP system is ready for S/4HANA, regardless of where it will run. Azure-specific assessment (VM sizing, network planning) comes from Azure Migrate and SAPS benchmarking.
Early Watch Alerts — your performance baseline
Early Watch Alerts are automated health reports generated by SAP Solution Manager. They capture:
- CPU, memory, and disk utilization trends
- Database growth rates and table sizes
- Performance hotspots and long-running transactions
- Configuration recommendations
These reports become your baseline. After migration to Azure, you compare the same metrics to verify that performance has not regressed.
Azure Migrate for SAP discovery
Azure Migrate now includes SAP-specific discovery capabilities. Using an agentless approach, it can:
- Discover SAP System IDs (SIDs), instance numbers, and component types
- Map HANA topology including scale-up and scale-out configurations
- Identify dependencies between SAP systems (which systems call which)
- Feed discovery data into Azure migration planning
🏗️ Raj perks up. “So Azure Migrate can see our SAP systems without installing agents on every box?”
☁️ Mei confirms. “Exactly. It uses existing protocols and SAP interfaces to discover the landscape. You deploy an Azure Migrate appliance in your on-premises network, and it talks to your SAP systems to build the inventory automatically.”
SAPS benchmarks: The universal sizing currency
SAPS stands for SAP Application Performance Standard. It is a hardware-independent benchmark that measures how many standardized business operations a system can process. Think of it as “horsepower for SAP.”
Think of SAPS like a car’s horsepower rating.
Horsepower lets you compare engines across different manufacturers — a 200 HP Honda engine and a 200 HP Ford engine deliver roughly the same power. SAPS does the same for SAP systems. A server rated at 10,000 SAPS can handle the same SAP workload whether it is an Azure VM, an on-premises Dell server, or an AWS instance. One SAPS equals 2,000 fully processed order line items per hour in a standard Sales and Distribution benchmark.
Mapping SAPS to Azure VMs
The workflow for VM sizing is straightforward:
- Measure current SAPS — Use Early Watch Alerts, transaction ST03N (workload analysis), or SAP Quick Sizer for greenfield scenarios
- Add headroom — Typically 20-30 percent above peak utilization for growth and migration overhead
- Consult SAP Note 1928533 — Find Azure VM SKUs that meet or exceed your SAPS requirement
- Validate memory — For HANA, ensure the VM has enough RAM for your database size plus working memory
- Check storage throughput — Confirm the VM supports the IOPS and throughput your workload needs
Exam tip: SAPS sizing for the application tier vs HANA
The application tier is sized primarily by SAPS (compute throughput). The HANA database tier is sized primarily by memory (your database must fit in RAM with room for working memory and growth). Both dimensions matter, but the primary constraint differs by tier. Expect exam questions that test whether you know which metric drives sizing for which tier.
Memory sizing for HANA
HANA is an in-memory database — the entire working dataset lives in RAM. Sizing HANA memory requires understanding three components:
- Data footprint — the compressed size of your tables in memory (typically 40-60 percent of the on-disk database size after HANA compression)
- Working memory — additional RAM for processing queries, column store operations, and temporary calculations
- Growth headroom — room for data growth over the next 3-5 years
A common rule of thumb: take your current database size, apply HANA compression ratios (typically 3:1 to 5:1 for transactional data), and then add 50 percent for working memory and growth. The SAP HANA sizing report (available through SAP Quick Sizer or by running the HANA sizing estimator against your existing database) provides a more precise number.
Knowledge check
Raj wants to evaluate whether PrecisionSteel's custom ABAP code is compatible with S/4HANA before starting the migration. Which tool should he use?
Raj is helping PrecisionSteel select the right Azure VM for their HANA database. Which metric is the PRIMARY sizing driver for the SAP HANA database tier on Azure?
PrecisionSteel's Early Watch Alert shows peak SAPS utilization of 15,000 SAPS for the application tier. What should Raj use as the target SAPS for Azure VM sizing?
Summary
Assessment is the foundation of a successful migration. You now know the tools — SAP Readiness Check for S/4HANA conversion readiness, Early Watch Alerts for performance baselines, Azure Migrate for landscape discovery, and SAPS benchmarks for VM sizing. The application tier is sized by SAPS (compute), while HANA is sized by memory (the database must fit in RAM).
Next, we will use these assessment results to choose the right migration strategy — lift-and-shift, replatform, or reimagine.
🎬 Video coming soon