Move SAP to AWS: certified, partner-led, with MAP funding where it qualifies.
Running SAP ECC, S/4HANA or BW on-premise, and being pushed toward a target by the 2027 ECC mainstream-maintenance deadline? This is the senior engineer's guide to SAP on AWS: the certified instances that actually run HANA (high-memory and U-series), the two real migration paths, where RISE with SAP fits, the DMO tooling that does the heavy lifting, and how AWS MAP funding works for SAP. A vetted partner files MAP when the migration qualifies, and AWS decides the amount.
- SAP runs on AWS on SAP-certified instances — and AWS is the only hyperscaler with a published, SAP-certified path to 24 TiB of memory for a single HANA scale-up node (the High Memory and U-series families), which is what makes large production S/4HANA and BW/4HANA workloads viable without re-architecting.
- There are two honest migration paths and a managed third option. (1) Homogeneous lift — move your existing HANA database and SAP stack to AWS roughly as-is; minimal business change, fastest. (2) Migrate-to-S/4HANA on AWS — convert or re-implement onto S/4HANA during the move; more value, more project. (3) RISE with SAP on AWS — SAP sells you S/4HANA Cloud Private Edition as a managed subscription running on AWS underneath.
- This is enterprise, partner-led work, and AWS can help fund it. AWS runs MAP (the Migration Acceleration Program) for SAP migrations, including as part of a RISE with SAP strategy. CloudRoute can match you with a vetted SAP-on-AWS partner who runs the cutover and files the MAP request when the migration qualifies. AWS decides the amount. Where no funding applies, the partner still de-risks the move.
ISAP on AWS, accurately: certified instances and why memory is the whole game
SAP is not a workload you "lift to a couple of EC2 instances" and hope. SAP only supports production deployments on instances it has explicitly certified, and for HANA the binding constraint is memory — not vCPU, not storage. Get that picture right and the rest of the architecture follows.
SAP HANA is an in-memory database: the entire productive dataset (plus working memory) lives in RAM, and that single fact drives the AWS sizing exercise. SAP maintains a Certified and Supported SAP HANA Hardware Directory; on AWS the certified families are the memory-optimized X-series (x2idn, x2iedn) for mid-size HANA, and — critically — the SAP HANA on AWS High Memory and U-series instances, certified up to 24 TiB of memory for a single scale-up HANA node. Azure and Google Cloud top out lower on published single-node certified HANA memory, which is why AWS is frequently the default for the largest BW/4HANA and S/4HANA estates.
For the SAP application tier (NetWeaver / ABAP / Java application servers, SAP Web Dispatcher, the (A)SCS central services), the certification net is much wider — general-purpose and compute-optimized families like m6i, m7i, c6i, and r6i are all SAP-supported. That tier is comparatively cheap and horizontally scalable; the cost and risk concentrate almost entirely in the HANA database tier.
Storage for HANA on AWS is Amazon EBS against specific SAP KPIs (data/log throughput, IOPS, latency) — io2 Block Express for the HANA data and log volumes on large systems, gp3 for smaller ones. The /hana/data, /hana/log, /hana/shared, and backup volumes each have a sizing formula tied to the certified instance's memory; the partner sizes these against SAP Note guidance rather than guessing.
Two practical implications fall out. First, sizing is a real engineering deliverable — driven by your current HANA memory footprint (or, from ECC, by the SAP sizing report that projects the post-migration HANA size, typically smaller than the source AnyDB because columnar compression shrinks the data). Second, the database tier is where every downtime, HA, and DR decision concentrates, because it is the stateful, hard-to-move part of the estate. Everything else — app servers, Fiori front-end, web dispatchers — is replaceable cattle.
Running productive SAP on a non-certified instance voids SAP support for that system — in an incident, SAP can decline to engage until you are on a certified configuration. For a production ERP that runs the business, "unsupported" is not a position any CIO will sign off on, which is why the certified High Memory / U-series families, not raw price-per-GB, anchor the architecture.
IIWhy this is on the 2026 roadmap: the 2027 deadline and the modernization case
Most SAP-to-AWS projects in 2026 are not discretionary. There is a hard date driving them, and a value case sitting on top of it. Naming both honestly is how you get budget approved.
SAP has set mainstream maintenance for SAP Business Suite 7 / ECC to end in 2027, with an extended-maintenance option (at a premium) running to 2030, and an optional further window to 2033 for some customers. Beyond that, ECC moves to customer-specific maintenance — effectively unsupported in practical terms. That deadline is the forcing function: every SAP customer must land somewhere — S/4HANA on a hyperscaler, RISE with SAP, or a costly extended-maintenance holding pattern — before it hits.
The infrastructure case lands harder for SAP because the hardware is so lumpy: a production HANA appliance is a large, single-purpose capital purchase sized for peak and quarter-end, then run at low average utilization for five years. On AWS you size the certified instance to the workload, scale the app tier elastically, stop non-production systems (dev, QA, training) outside business hours, and convert a multi-year capex commitment into consumption-based opex.
There is also a hard-to-replicate-on-prem capability story. SAP on AWS unlocks adjacent services that are awkward on-premise: Amazon S3 for cheap, durable HANA backups (via Backint) and SAP archiving; Amazon Bedrock and the SAP-to-Bedrock integration for generative-AI on enterprise data; Amazon Redshift / Athena for analytics on data extracted from SAP; and the broader account-level security and governance fabric. The deadline forces the move; these capabilities justify doing it as modernization rather than a like-for-like rehost.
The right mental model: the 2027 deadline sets the when, the migration path (Section III) sets how much change, and the funding (Section VI) sets how much of the move AWS helps pay for. CloudRoute's job is to match you with a partner who has done this specific shape of migration before and can file the MAP request.
IIIThe two migration paths (plus RISE) — and which one fits
Almost every SAP-to-AWS conversation collapses to one decision: do you move the SAP estate you have, or change it on the way? That decision determines the timeline, risk, cost, and business value. Here are the three honest options.
There is no universally correct answer. The right path depends on how far you are from S/4HANA today, how much business-process change your organization can absorb in one program, and how much of the work you want SAP to own versus your own teams and a partner.
Path 1 — Homogeneous lift (move what you have to AWS)
What it is: Move your existing SAP system to AWS with the same database platform. If you are already on HANA (Suite on HANA, or S/4HANA on-premise), this is a HANA-to-HANA relocation. If you are on ECC with a traditional "AnyDB" (Oracle, IBM Db2, SQL Server), the homogeneous move keeps that database — though most teams move to HANA at the same time, which makes it heterogeneous (see DMO in Section IV).
Why choose it: Lowest business-process risk and the fastest route off the on-premise datacenter — you change the infrastructure, not the application. Ideal when the 2027 clock is the dominant pressure and the organization cannot absorb a transformation program right now.
The honest tradeoff: You arrive on AWS with the same application — including its technical debt and custom code. If you are still on ECC, you have relocated the problem, not solved it: the S/4HANA conversion is still ahead. Many enterprises deliberately sequence it this way — lift first to beat the deadline and get infrastructure flexibility, then convert to S/4HANA on AWS as a less time-pressured phase two.
Timeline: Typically 3–6 months for a moderate-size production system, dominated by test cycles and cutover rehearsals rather than the technical move itself.
Path 2 — Migrate to S/4HANA on AWS (change on the way)
What it is: Land on S/4HANA running on AWS. Two sub-flavors: a brownfield system conversion (convert your existing ECC system in place — keeps history and config, technically intensive) or a greenfield new implementation (stand up a fresh S/4HANA and migrate selected data and re-engineered processes onto it). A "selective data transition" / bluefield middle path mixes the two.
Why choose it: You solve the deadline and capture the modernization value in one program — clean core, S/4HANA simplifications, Fiori UX, embedded analytics, and a platform ready for AWS-native AI and data services. Greenfield is the lever for shedding decades of custom code and reverting to standard.
The honest tradeoff: This is a transformation program, not an infrastructure project — it pulls in business process owners, master-data cleanup, ABAP custom-code remediation (it must be made S/4HANA-compatible), and far more testing. Brownfield is faster and keeps history but inherits the mess; greenfield is cleaner but is effectively a re-implementation.
Timeline: 9–18+ months for a production S/4HANA conversion or new implementation, depending on scope, countries/company codes, and custom-code volume.
Path 3 — RISE with SAP, deployed on AWS (let SAP own the stack)
What it is: RISE with SAP is SAP's managed subscription bundle built around S/4HANA Cloud, Private Edition. You buy an outcome from SAP — the ERP, the managed infrastructure, the technical operations — and SAP deploys it on a hyperscaler. You can request AWS as the underlying hyperscaler, so your RISE estate runs in an AWS environment SAP manages on your behalf.
Why choose it: You want a single commercial relationship with SAP, less hyperscaler operations to staff for, and a contractually managed path to S/4HANA. Attractive for organizations without a deep internal SAP-Basis-on-cloud bench.
The honest tradeoff: You give up some control and direct cost transparency: SAP, not you, holds the AWS account and the infrastructure levers inside the RISE construct. AWS says MAP can support a RISE with SAP strategy as part of a phased approach, but confirm with your partner and AWS how funding works when SAP holds the account before you count on it. Integrating RISE-managed SAP with your own AWS-native services (Bedrock, Redshift, your data lake) needs deliberate network and identity design across the boundary.
Where CloudRoute fits: Even on RISE you typically still want a partner for the conversion, the integration to your wider AWS estate, and the change program. We route to partners who do RISE-on-AWS deployments, and we are honest when a non-RISE "BYOL on your own AWS account" model gives you more control.
IVThe tooling: DMO, SUM, and the AWS migration services that surround it
SAP migrations have their own purpose-built tooling — generic lift-and-shift tools are the supporting cast, not the star. The single most important tool to understand is DMO.
The Database Migration Option (DMO) of the Software Update Manager (SUM) is SAP's flagship tool for the combined database-migration-plus-upgrade move. DMO can, in one orchestrated run, migrate your source database to HANA and upgrade the SAP software to the target release — which is exactly the "move to HANA while you move to AWS" combination most ECC customers want. DMO has a "DMO with System Move" variant designed precisely for migrating to a new host (i.e., from on-premise to an AWS instance) in the same procedure, and DMO supports a benchmarking/optimization cycle so you can tune the downtime window before the productive run.
Surrounding DMO, the relevant AWS migration services are:
- AWS Launch Wizard for SAP — guided, prescriptive provisioning of a SAP-certified, well-architected landing for HANA and NetWeaver. It deploys the right certified instances, EBS layout, and OS configuration so the target is correct before the data move, rather than hand-rolled.
- AWS Application Migration Service (MGN) — block-level replication for a true rehost when you relocate an existing SAP host as-is (most relevant for the application tier, sandbox/training systems, or a homogeneous HANA-to-HANA lift).
- AWS DataSync and the AWS Data Transfer Terminal: for moving the large backup, archive and export datasets (and the initial HANA backup) into Amazon S3, online with DataSync or offline at a Data Transfer Terminal when the export is too large for the network. Snowball Edge is no longer available to new customers.
- Backint for SAP HANA + Amazon S3 — the SAP-certified backup interface that streams HANA backups directly to S3, replacing on-premise backup appliances with cheap, durable, long-retention backups as part of the target architecture.
- AWS Migration Hub — tracks the overall migration portfolio (useful when SAP is one of several workloads moving); the SAP-specific sequencing lives in the partner's cutover plan and DMO runbook.
This is partner-led work, not a self-serve console exercise: the value is in the runbook and the rehearsals, not the tools. A competent partner runs DMO against a copy of production multiple times and only then schedules the productive cutover with a tested rollback (the downtime engineering is detailed in Section V).
VHA, DR, and minimizing the business downtime
SAP runs the business — order-to-cash, financial close, the shop floor. The two questions every CIO asks: "how much downtime to cut over?" and "once on AWS, how resilient is it?" Both have concrete, engineered answers.
High availability on AWS. The standard pattern spreads the system across two Availability Zones in a Region. HANA System Replication (HSR) keeps a synchronous secondary HANA node in a second AZ; a cluster manager (commonly the SUSE or Red Hat pacemaker-based HA cluster, with the AWS-specific resource agents) handles automatic failover of the database and the SAP (A)SCS central-services single point of failure. Application servers run in both AZs behind the message server / web dispatcher. The loss of a single AZ does not take the system down — failover is automatic and typically completes in minutes.
Disaster recovery. For regional resilience, HSR replicates asynchronously to a third HANA node in a separate Region, paired with infrastructure-as-code (and frequently AWS Elastic Disaster Recovery for the surrounding components) so the DR Region can be brought to production within a defined RTO/RPO. Because that capacity is on demand, you are not paying for an idle second datacenter year-round — a meaningful advantage over physical DR sites.
Minimizing cutover downtime. The business-impacting window is driven by the database move and engineered down through several levers: DMO benchmarking and table-split/parallelism tuning; the downtime-optimized / near-zero-downtime DMO options that move the bulk of data while the source is still live and cut over only a delta; pre-staging the large data transfer (DataSync, or the AWS Data Transfer Terminal for offline uploads) so the cutover carries only the change delta; and rehearsing the runbook against production-sized data until the window is predictable. For most mid-size systems this lands the downtime in a planned weekend window measured in hours, not the multi-day outages on-premise migrations historically required.
The honest caveat. "Near-zero downtime" is real but not free — it adds complexity, cost, and rehearsal time, justified where every hour of downtime has a hard business cost (24/7 manufacturing or retail). For a system that tolerates a quiet Sunday-night window, the simpler downtime-optimized DMO run is the cheaper call. A good partner sizes the resilience and downtime engineering to the actual cost of an outage rather than over-engineering by default.
SAP carries the most sensitive enterprise data — finance, HR, customer PII — so the target inherits hard compliance requirements. AWS Regions pin the estate to a specific jurisdiction for residency (EU, UK, KSA, UAE, India, etc.), encryption is enforced at rest and in transit, and account-level controls (Organizations SCPs, CloudTrail, GuardDuty, a SAP-aware landing zone) satisfy the auditors — provisioned in from the start rather than bolted on. (Frameworks and timelines: see the FAQ.)
VIThe funding mechanics: AWS MAP, and where CloudRoute fits
SAP migrations are large enough that funding is not a footnote: it can decide whether the project clears finance. AWS runs MAP for SAP migrations, and your matched partner files it.
AWS Migration Acceleration Program (MAP). MAP has three phases. Assess builds readiness and a TCO model; for SAP, that is where the certified-instance sizing and business case get built. Mobilize covers a pilot and the AWS landing zone. Migrate & Modernize covers the production move. AWS describes MAP as tools, training, partner expertise and financial investments that offset initial migration costs, and it runs a MAP track for SAP, including RISE with SAP strategies. Your matched partner files the MAP request when the migration qualifies, and AWS decides the amount. Partner funding programs reach about $1M, but that tier is for enterprises such as banks, hospitals and municipalities, not startups.
SAP-side incentives. SAP may offer its own incentives for the move to S/4HANA or RISE. We do not quote them here because we cannot check current terms on a public page. Ask SAP or your SAP account team directly, and treat anything SAP offers as separate from MAP.
How CloudRoute fits. We match you with a partner that holds the AWS SAP Competency and SAP certifications and can file the MAP request. The partner runs the migration and is paid for the work, partly through AWS-approved MAP funding where the migration qualifies. CloudRoute is free for you. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
The honest framing. MAP funding applies to qualifying migrations, and AWS decides what qualifies and how much. A large production SAP estate is the kind of workload MAP is built for, but nothing is certain until AWS approves it. Where a workload does not qualify, a vetted partner still de-risks the cutover, and we tell you plainly which case you are in.
VIIWhat a SAP-on-AWS program actually looks like, phase by phase
Phase 0: Match + Assess (weeks 1–6). CloudRoute matches you with a SAP-on-AWS partner who runs the MAP Assess: SAP sizing report projecting the target HANA memory, system landscape inventory, custom-code analysis for the S/4HANA path, TCO model, and the path recommendation (lift vs S/4HANA vs RISE). Output: a business case and a target architecture on certified instances.
Phase 1: Mobilize + landing zone (weeks 6–14). The partner stands up the AWS landing zone (accounts, networking, security guardrails, the SAP-aware account structure) and a pilot/sandbox SAP system, validated with Launch Wizard for SAP, then runs DMO for the first time against a non-production copy to benchmark the approach. Output: a working SAP system on AWS and a measured, tuned migration runbook.
Phase 2: Build non-production + rehearse (months 3–7). Dev, QA, and training systems are migrated first; the cutover runbook is rehearsed against production-sized data with the downtime window measured and the rollback tested; HA across two AZs and DR to a second Region are configured and failover-tested. Output: a production-ready target and a rehearsed cutover plan with a known downtime window.
Phase 3: Production cutover (a planned weekend, within months 6–14). The productive DMO run executes inside the rehearsed window (data pre-staged, only the delta carried at cutover, downtime in hours), followed by hypercare. Output: SAP live on AWS, on certified instances, with HA/DR in place.
Phase 4: Optimize + modernize (ongoing). Right-size instances against real load, stop/start non-production to cut spend, wire S3 Backint backups, and begin the AWS-native modernization the platform now enables: Bedrock on SAP data, analytics in Redshift/Athena, and (if you lifted ECC first) the S/4HANA conversion as a follow-on project. This is where the consumption model pays back versus the old fixed appliance.
SAP migration approaches to AWS — compared
The path you choose sets the timeline, the risk, the business value, and the funding mix. This is the decision that defines the program — here are the four realistic shapes side by side.
| Approach | What changes | Business-process risk | Typical timeline | Modernization value | AWS funding route |
|---|---|---|---|---|---|
| Homogeneous lift (HANA→HANA / AnyDB kept) | Infrastructure only | Low | 3–6 months | Low (infra flexibility, opex) | MAP, if it qualifies |
| Lift + DMO to HANA (ECC → Suite on HANA on AWS) | Infra + database to HANA | Low–medium | 4–8 months | Medium (HANA platform, sets up S/4) | MAP, if it qualifies |
| Brownfield S/4HANA conversion on AWS | Infra + DB + app to S/4HANA (history kept) | Medium–high | 9–15 months | High (S/4 clean-ish core, Fiori, analytics) | MAP, if it qualifies |
| Greenfield S/4HANA on AWS (new implementation) | Net-new S/4HANA, re-engineered processes | High | 12–18+ months | Highest (standard processes, no legacy debt) | MAP, if it qualifies |
| RISE with SAP on AWS | SAP-managed S/4HANA subscription on AWS | Medium (SAP owns ops) | 9–15 months | High (managed S/4 + AWS underneath) | MAP can support a RISE strategy; confirm with SAP and AWS |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks MAP funding
Your matched partner scopes the migration with you. Then it checks whether the move qualifies for MAP (Migration Acceleration Program) funding. MAP is for teams that are not on AWS yet.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
Can AWS really run our large production HANA, or is that just for small SAP systems?
Should we lift-and-shift to AWS first, or go straight to S/4HANA?
What is the difference between RISE with SAP on AWS and migrating SAP to our own AWS account?
How much business downtime does the cutover actually require?
What does AWS MAP fund for a SAP migration?
Why do we need an SAP-certified partner — can our team not do this with AWS tooling directly?
How do we keep SAP data in our jurisdiction, stay compliant, and how long does it all take?
Get a partner-led path for SAP on AWS
A vetted SAP-on-AWS partner runs the MAP Assess, sizes the certified HANA target, engineers the cutover and files MAP funding when the migration qualifies. AWS decides the amount. CloudRoute is free for you.