SAP on AWS is not a lift, even when the project plan calls it one. It is a re-architecture against contractual constraints — SAP’s certified instance list, AWS’s availability-zone topology, the business’s recovery-time objective — and the projects that succeed treat it that way from the first week. The constraints are public: AWS maintains the canonical reference at aws.amazon.com/sap, and the joint SAP × AWS partnership page lists certifications, supported regions, and reference customers. Here is the playbook we follow on every engagement.
Pre-migration: the four numbers that decide everything
Before any architecture is drawn, four numbers anchor the entire migration:
· The current SAP system’s SAPS (SAP Application Performance Standard) rating.
· The peak concurrent dialog steps the business actually drives.
· The recovery-time objective the business will sign off (RTO).
· The recovery-point objective the business will sign off (RPO).
The first two size the AWS compute. SAP publishes a list of certified EC2 instance families for each workload type — Note 1656099 for SAP on Linux, Note 1928533 for SAP HANA — and you cannot deviate. The third and fourth shape the HA/DR architecture. A 1-hour RTO means a hot standby; a 4-hour RTO means a warm one; a 24-hour RTO means a backup-restore. Each tier costs differently.
Working through your SAPS, RTO, and RPO numbers? We run sizing workshops for African and Gulf enterprises. Schedule a workshop →
The migration pattern: rehost, replatform, refactor
The three migration patterns are well-named, but the choice matters less than the discipline of choosing once and committing.
Rehost. Move the SAP system as-is to certified EC2 instances. Lowest risk, fastest, smallest business benefit. Sensible for systems near end-of-life, or where the move to S/4HANA is on the roadmap as a separate project.
Replatform. Move while changing the database to a managed AWS service (Amazon RDS where SAP supports it, or HANA on EC2 with managed backups). More work, but captures the operational savings AWS is good at.
Refactor. Move and modernise to S/4HANA on HANA, often combined with re-architecting integrations to use AWS-native services. Highest upside, longest project. Almost always a separate project from the migration.
Not sure which pattern fits your SAP estate and timeline? Talk to our SAP-on-AWS team →
HA and DR: multi-AZ from day one
AWS gives you three to six Availability Zones per region (three in af-south-1 Cape Town, me-south-1 Bahrain, and me-central-1 UAE — the regions most relevant to our market). SAP supports certified stretched multi-AZ deployments on all of them. The only reason to deploy production SAP into a single AZ on AWS in 2026 is that the budget will not stretch — and ‘will not stretch’ usually means the AZ cost was not sized into the business case.
The standard pattern: SAP application servers in two AZs front-ended by SAP Web Dispatcher (with an AWS Network Load Balancer in front for HTTPS termination, and a separate NLB carrying the HANA virtual-IP for database failover); SAP HANA primary in one AZ with synchronous replication (HSR) to a hot standby in another; backups to S3 in a third location for the cross-region DR scenario. HANA System Replication for in-region HA plus an AWS Backup vault to a separate region gives an RPO of seconds and an RTO of minutes — at a cost that is a fraction of any pre-cloud equivalent.
Network and security: the parts people forget
The SAP environment talks to the rest of the business. That means:
· Direct Connect or Site-to-Site VPN from the on-prem network for the duration of the project, and often forever.
· Private endpoints for AWS services SAP integrates with (S3 via Gateway endpoint, KMS via Interface endpoint) so application traffic does not traverse a NAT Gateway.
· IAM roles for any access from SAP to AWS-native services — never long-lived access keys on the SAP host.
· Tightly-scoped Security Groups: the SAP application tier talks to the database tier on the specific HANA ports (typically 30013/15/41), nothing else.
None of these are new ideas. They are the items that do not make the project plan and become incidents during cutover.
Cutover: the boring detail wins
The cutover weekend is not where surprises should happen. The boring detail that wins:
· A full dress-rehearsal cutover against a non-production environment with realistic data volumes.
· A documented rollback plan that has been tested, not just written.
· A communication plan: who tells the business, when, in what channels.
· DNS TTLs lowered a week before the move so the cutover does not wait on caches.
Planning a cutover weekend? Our team has run dozens, end-to-end. Get in touch →
The first 30 days: when the bill (and the surprises) arrive
Most projects mark go-live as the end of the engagement. We treat it as the start. The first 30 days are where the right-sizing reality of the production load gets compared to the sizing assumptions; the first cost-optimisation candidates appear (often HANA instances 30% larger than they need to be in steady state); the operational handover happens — runbooks, alerting, on-call; and the first AWS Well-Architected Review is scheduled. We typically run that 60–90 days post-go-live, not earlier; the workload needs time to stabilise.
SAP migrations have a reputation for surprise. They rarely have to. The constraints are public, the patterns are well-trodden, and the failure modes are mostly the same as any other complex enterprise migration: insufficient pre-work, optimistic project plans, and underestimating the operational handover. Get those three right and the migration is repeatable. (For the analytics platform that SAP usually feeds, see our piece on the AWS + Snowflake + Informatica Trifecta.)
Where this applies: SAP-on-AWS migrations land most often in financial services (core banking, insurance back office) and real estate (property ERPs) in our market. Unity Homes and Adrian Group are SAP-on-AWS workloads Shinrai has delivered.
