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 plus SAP RACE can take a large slice of the project cost off the table.
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.
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 mechanics (Section VI) determine how much AWS and SAP pay for. CloudRoute's job is to line up a partner who has done this specific shape of migration before and structure the funding so the project clears finance.
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.
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.
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. This is where SAP RACE / value funding matters most.
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. Direct AWS MAP funding mechanics differ when SAP owns the account (the funding shifts toward SAP's RISE/value programs), and 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 and a cleaner MAP-funding path.
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:
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).
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/Snowball) 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.)
SAP migrations are large enough that funding is not a footnote — it can decide whether the project clears finance. Two distinct funding rails exist, they stack, and they are the core CloudRoute mechanism.
AWS Migration Acceleration Program (MAP). MAP is AWS's structured, partner-led migration funding, run in three phases. Assess produces a TCO and readiness analysis (often free / heavily funded) — for SAP, where the certified-instance sizing and business case get built. Mobilize funds a pilot and the AWS landing zone. Migrate & Modernize funds the production move. AWS provides credits scaled to the projected post-migration AWS spend, and the partner is paid through MAP for delivery. For a substantial SAP estate the MAP-funded share is material — assessment largely absorbed and a meaningful slice of migration/landing-zone cost credited.
SAP value / RACE programs. SAP runs its own value-engineering and adoption funding (commonly referenced under the RACE umbrella and SAP's migration/value programs) to encourage and partly fund the move to S/4HANA and RISE. This rail targets the application transformation cost — the S/4HANA conversion — where MAP targets the infrastructure migration cost. Because they fund different layers of the same program, a well-structured migration can draw on both.
How CloudRoute structures it. We route you to a partner who holds the AWS SAP Competency and the SAP certifications and can file the MAP record correctly while engaging SAP's funding programs in parallel. The partner runs the migration; MAP funds the infrastructure side; SAP's programs co-fund the S/4HANA side; the partner is paid through those programs; CloudRoute is paid a commission by the partner. The net effect for a qualifying enterprise is a migration delivered at a fraction of unfunded list cost.
The honest framing. MAP funding applies to qualifying migrations — typically those with a meaningful committed AWS spend post-migration and a real production workload, which a large SAP estate comfortably clears. SAP's funding is discretionary and negotiated. Where a workload does not qualify, CloudRoute is still valuable as a vetted-partner referral that de-risks the cutover — and we tell you plainly which case you are in rather than overselling the funding.
Phase 0 — Match + Assess (weeks 1–6). CloudRoute routes you to a SAP-on-AWS partner who runs the (typically MAP-funded) 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 funded 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 funded follow-on. This is where the consumption model pays back versus the old fixed appliance.
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 | Primary funding |
|---|---|---|---|---|---|
| Homogeneous lift (HANA→HANA / AnyDB kept) | Infrastructure only | Low | 3–6 months | Low (infra flexibility, opex) | AWS MAP |
| 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) | AWS MAP |
| 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) | AWS MAP + SAP RACE |
| Greenfield S/4HANA on AWS (new implementation) | Net-new S/4HANA, re-engineered processes | High | 12–18+ months | Highest (standard processes, no legacy debt) | AWS MAP + SAP RACE |
| 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) | SAP RISE/value (MAP differs) |
Situation: ECC on aging on-premise hardware due for a costly refresh, with the 2027 maintenance deadline forcing a decision. 24/7 manufacturing meant downtime had a hard per-hour cost. The board wanted the value of S/4HANA but could not absorb a full transformation and the deadline pressure at once. The internal SAP Basis team had no cloud-migration experience and no spare capacity.
What CloudRoute did: Routed within 5 business days to a partner holding the AWS SAP Competency plus SAP delivery certifications. Partner ran the MAP Assess (AWS-funded): SAP sizing confirmed a ~6 TiB HANA target on an SAP-certified High Memory instance, app tier on r6i/m6i across two AZs. Recommended path: homogeneous lift to Suite-on-HANA on AWS via DMO with System Move first (beat the deadline), then a brownfield S/4HANA conversion as funded phase two. Landing zone built in Mobilize; cutover rehearsed three times against production-sized data; HSR HA across two AZs plus async DR to a second EU Region for residency. MAP funded the infrastructure migration; SAP value funding earmarked for the S/4HANA conversion.
Outcome: Production cutover executed in a single planned weekend with measured business downtime of ~7 hours (rehearsed target was under 9), and the on-premise capex refresh avoided. Phase-one infrastructure migration ran ~9 months Assess-to-hypercare, with the assessment fully MAP-funded and a material share of the migration cost credited; the S/4HANA conversion is the funded follow-on. Partner was paid through AWS MAP and SAP programs; CloudRoute's commission was paid by the partner — the customer paid CloudRoute $0.
path: lift-then-S/4 · HANA target: ~6 TiB · business downtime: ~7 hours · phase-1 duration: ~9 months · funding: MAP + SAP RACE · cost to customer for CloudRoute: $0
CloudRoute routes you to a vetted SAP-on-AWS partner who runs the MAP Assess, sizes the certified HANA target, engineers the cutover, and structures MAP + SAP funding. Customer pays CloudRoute $0.