Use this SAP on AWS migration readiness checklist to align SAP Basis, infrastructure, security, operations and business teams before S/4HANA, BW, HANA or wider SAP workloads move to AWS.
SAP migrations fail when important assumptions are discovered too late. Before teams choose instance types, storage patterns or cutover windows, they need a shared view of the SAP landscape, the business criticality of each system, the interface estate, security constraints and the operating model expected after migration.
This checklist is designed for SAP Basis, infrastructure, security, operations and business teams preparing S/4HANA, BW, HANA or wider SAP workloads for AWS.
Use the checklist below before an SAP on AWS migration design is finalised. It is intentionally practical: each area should have a named owner, evidence source and decision before the programme moves from assessment into detailed design or migration execution.
| Readiness Area | Key Question | Evidence To Collect | Decision Needed |
|---|---|---|---|
| Landscape inventory | Which SAP systems, clients, databases, interfaces and third-party dependencies are in scope? | System list, SID/client map, add-ons, interface catalogue, business-owner mapping. | Confirm migration scope, exclusions and sequencing assumptions. |
| HANA and database sizing | What compute, memory, storage and throughput profile does each workload require? | Current utilisation, growth forecast, HANA sizing, backup size, I/O and latency metrics. | Select AWS instance families, storage pattern and performance baseline. |
| High availability and disaster recovery | What RTO/RPO does each SAP component need, and which workloads justify multi-AZ or DR design? | Business continuity requirements, failover expectations, recovery tests, downtime windows. | Choose HA/DR architecture for ASCS/ERS, HANA, application servers and supporting services. |
| Security and compliance | Which controls are mandatory for network access, encryption, identity, audit and data residency? | Security policies, regulatory constraints, IAM model, encryption requirements, audit evidence. | Define landing-zone controls, segmentation, logging and access model. |
| Integration and connectivity | Which interfaces need low latency, fixed routing, firewall changes or partner coordination? | Interface catalogue, protocol list, network routes, DNS dependencies, partner endpoints. | Confirm connectivity design and integration test plan. |
| Backup, restore and operations | How will backups, patching, monitoring, alerting and operational runbooks work after migration? | Backup policy, restore evidence, monitoring standards, runbooks, escalation model. | Agree operational acceptance criteria and support handover. |
| Cutover and business validation | How will the business prove the migrated SAP landscape is ready for production? | Cutover plan, mock cutover results, test scripts, reconciliation checks, go/no-go criteria. | Approve cutover sequence, rollback route and business sign-off process. |
SAP workloads are sensitive to compute, memory, storage throughput, latency and availability design. A readiness review should connect SAP sizing, database behaviour, integration paths and business continuity needs to AWS architecture decisions rather than treating infrastructure as a generic landing-zone exercise.
Moving SAP to AWS changes how teams monitor, patch, back up, secure and operate the landscape. The support model should be designed during migration planning, not after production go-live. This includes security ownership, alert routing, patch windows, runbooks, backup evidence and escalation paths.
A readiness checklist works best when it supports a staged migration methodology. During assessment, it exposes uncertainty. During mobilisation, it turns uncertainty into design decisions and migration waves. During migration, it supports cutover readiness. After migration, it becomes an operating baseline for optimisation.
Useful AWS references include AWS Prescriptive Guidance for SAP migration strategy and AWS for SAP migration readiness guidance.
The most important evidence is a reliable inventory of systems, sizing, databases, integrations, schedules, availability and recovery requirements, and post-cutover operating responsibilities.
Yes. RTO, RPO, backup, high availability and recovery testing should be connected to the migration plan before delivery waves or cutover windows are agreed.
Failures often come from undiscovered interfaces, inaccurate HANA sizing, late security requirements, untested downtime plans or an unclear post-migration operating model.
The checklist connects technical readiness with operating requirements before SAP migration waves begin.
Review landscape inventory, HANA sizing, integrations, recovery, security, operations and cutover planning before delivery waves begin.
Cloudwrxs helps organisations assess, design, migrate and operate SAP workloads on AWS with practical migration governance and delivery support.
