SAP to AWS Migration - A Practical Guide with MAP Funding

This guide is aimed at organisations running a production SAP environment (ECC, S/4HANA, BW, Solution Manager) that are weighing an exit from on-premise or colocation. If you need a broader AWS migration overview (not SAP-specific), see our complete AWS cloud migration guide.

Why organisations move SAP to AWS

The end of the hardware refresh cycle

An on-premise SAP environment usually means specialised high-memory servers (for HANA) and storage arrays that need replacing every four to five years. Each refresh is a capital project running into hundreds of thousands, planned a year ahead. On AWS you size memory and compute to actual demand and pay for usage, and you change an instance in a maintenance window instead of waiting on a hardware delivery.

The S/4HANA 2027 deadline

SAP will end mainstream maintenance for Business Suite 7 (including ECC) at the end of 2027, with extended support available to 2030. That forces thousands of organisations to make a decision about moving to S/4HANA. Migrating to AWS and converting to S/4HANA is a natural moment to combine both projects and fund them from a single MAP budget, rather than doing a hardware migration now and starting a separate conversion two years later.

Flexibility for non-production environments

An SAP estate typically runs several environments (development, test, QA, training, production). On-premise, they all run around the clock because the hardware is already bought. On AWS, non-production environments can be switched off outside working hours and at weekends, which for an SAP estate can cut the bill for those systems by 60-70%. It’s one of the fastest cost wins after migration.

SAP certification and compliance

AWS is an SAP-certified platform for production workloads, with instances validated for HANA (listed in the SAP HANA Hardware Directory). For regulated industries, AWS certifications (ISO 27001, SOC 2, PCI DSS) and EU regions with data residency matter: workloads stay within the EU and latency to most of Europe sits comfortably within tens of milliseconds, which keeps GDPR and sector compliance obligations manageable.

RISE with SAP or a self-managed deployment on AWS

This is the first and most consequential architectural decision. Both options run on AWS, but they differ in the responsibility model and in how they are billed.

The distinction that matters most for this guide: MAP funding applies to a self-managed deployment on AWS, not to RISE. RISE is a subscription bought from SAP, so AWS does not fund partner work within it. If you want full control over the architecture, integration with the rest of your AWS estate, and 70-80% of the project covered by MAP, you choose self-managed. If your priority is handing the whole of SAP management to a single vendor and you accept less flexibility, RISE can be justified. In practice we recommend comparing the total cost of ownership of both during the assessment phase, because the gap can be significant in either direction.

Sizing instances for SAP HANA

SAP HANA keeps the entire database in memory, so instance sizing is first about RAM and only then about CPU. AWS offers SAP-certified instances across several families.

A few practical rules:

• Sizing for HANA comes from an SAP report. For a fresh S/4HANA install that’s the SAP Quick Sizer; for converting an existing system it’s the /SDF/HDB_SIZING report run against the source. The target memory follows from that, not from the current on-disk size of the database.
• Certification matters. Production HANA runs only on instances from the SAP HANA Hardware Directory. Non-production environments can run on non-certified instances, which lowers cost.
• Scale the application tier (SAP NetWeaver, dialogue servers) separately. These don’t need high-memory instances; standard compute families are enough, and dialogue servers can scale out horizontally under user load.
• Storage for HANA is io2 or gp3 with throughput matched to SAP’s requirements for log and data write performance.

Weighing up an SAP move to AWS?

Book a free 30-minute call. We help teams plan SAP migrations on AWS, RISE vs self-managed, HANA sizing, and the cutover, and we check whether your project qualifies for AWS MAP funding (typically 70-80% of partner fees).

Book a call Send us a message

SAP to AWS migration strategies

Your approach depends on whether you stay on your current database (for example ECC on AnyDB) or move to S/4HANA, and on how much downtime you can accept.

Rehost (lift-and-shift)

Move the SAP system to AWS without changing the version or the database. The fastest route to the cloud, good when the priority is exiting on-premise before a hardware refresh and you plan the S/4HANA conversion later. Tools: AWS Application Migration Service (MGN) for server replication, or native SAP mechanisms (backup/restore, system copy).

Replatform (migration with a database conversion to HANA)

Move while switching the database to SAP HANA, but without changing the application version (for example Suite on HANA). Uses the SAP Database Migration Option (DMO) within the SUM tool, which converts the database during the migration.

Greenfield (new S/4HANA implementation)

Implement S/4HANA from scratch, with new processes and migration of only master data and open items. Chosen when current processes are badly outdated or weighed down by years of modifications nobody wants to carry forward. The most project work, but the cleanest result.

Brownfield (system conversion to S/4HANA)

Convert an existing ECC to S/4HANA, keeping processes, configuration, and history. Delivered through SAP SUM with DMO. Lower business risk than greenfield (you keep what works), but it also carries the technical debt forward.

Bluefield (selective approach)

A middle path: a new S/4HANA install into which you selectively bring across chosen data and configuration from the old system. A compromise between greenfield’s cleanliness and brownfield’s retention of history.

The migration process, step by step

SAP licensing on AWS

Moving to AWS doesn’t change how SAP itself is licensed: your SAP licences (application and HANA) remain a contract with SAP regardless of where the system runs. The BYOL (Bring Your Own Licence) model means you carry your existing licences into the cloud.

A few points worth keeping in mind:

• SAP application and HANA licences are independent of AWS. AWS bills for infrastructure (instances, storage, networking); SAP bills for the software. They are two separate line items.
• RISE with SAP bundles both into one subscription. If you choose RISE, software and infrastructure sit in a single SAP contract, but you lose access to MAP funding and some of the cost flexibility.
• Operating systems for SAP (SUSE Linux for SAP, Red Hat for SAP) have their own billing model on AWS: either included in the instance price (hourly subscription) or BYOS (Bring Your Own Subscription).
• Plan a licence audit before migrating, so you carry across only what’s genuinely in use and don’t pay for surplus licences in the new environment.

Minimising downtime

How much downtime an SAP migration requires depends mainly on the strategy you choose and the size of the HANA database.

• Rehosting a large HANA database via backup/restore is a maintenance window measured in hours, driven by database size and link throughput. For large databases you use HANA System Replication: replicate the database to AWS live, then in the maintenance window perform only the takeover, which cuts downtime to minutes.
• A brownfield conversion to S/4HANA (SUM with DMO) has a longer window, because the database conversion happens within it. You shorten it with the downtime-optimised DMO mode and with dry runs that let you measure and tune the real elapsed time.
• Greenfield minimises production downtime (the new system is built in parallel) but shifts the weight onto data migration and running both systems in parallel through a transition period.

In every scenario the rollback plan is prepared and tested before the actual cutover. Keeping the source system read-only for the first days after cutover is a standard safeguard.

How AWS MAP funds an SAP migration

What the AWS Migration Acceleration Program (MAP) is

MAP is an AWS funding programme for organisations migrating from on-premise or colocation. It runs across three phases, and SAP environments are among the workloads AWS is particularly keen on, so they qualify for an elevated budget.

Why SAP qualifies for a higher budget

AWS treats SAP migrations as strategic and runs a track for them with funding ceilings above the standard MAP. The reason is straightforward: an SAP estate is a large, steady workload that stays on the platform for years once migrated. In practice that means, for the customer:

• Higher funding ceilings than a typical application migration
• Additional credits toward the target infrastructure for the duration of the migration and stabilisation
• Access to AWS architects who specialise in SAP, and to the partner’s SAP Competency programme

This is the core commercial argument: with a well-run MAP application, the real cost of an SAP migration on your side drops by 70-80%, and the point of a forced S/4HANA decision (the end of ECC support in 2027) becomes an opportunity largely funded by AWS rather than a pure cost.

Who qualifies

• An active SAP environment (on-premise, colocation, or already partly in the cloud)
• A target on native AWS (self-managed, not RISE)
• A minimum project size at the level of partner engagement typical for SAP environments (most SAP projects clear the threshold comfortably)
• A certified MAP partner to submit and run the application. We handle that end to end.

What you can realistically get

Beyond covering partner fees, you typically also get AWS credits toward the target infrastructure for the project’s duration, plus support from AWS architects. Flag the date of your hardware refresh or SAP support renewal at the outset, as it can be a point of leverage that unlocks additional funding.

SAP migration costs and timelines

What drives cost and time most: the number of systems in the environment, the rehost vs S/4HANA-conversion decision (a conversion is a separate application project), the number of integrations with external systems, availability requirements (HA/DR), and the acceptable downtime window (the shorter it is, the more work goes into replication and dry runs).

On the savings side, the biggest items are the end of the hardware refresh cycle, switching off non-production environments outside working hours, and Savings Plans for steady production load. Together these typically deliver a 20-50% reduction in infrastructure cost against on-premise, depending on how inefficient the starting environment was.

Frequently asked questions

Next steps - a free migration assessment

Every SAP migration starts with an assessment of the environment. We analyse your systems (versions, HANA sizes, integrations, availability requirements) and come back with specifics:

1. Target sizing on AWS - which HANA-certified instances, what HA/DR architecture
2. A strategy recommendation - rehost, brownfield, or greenfield, and why that one
3. A realistic cost estimate and timeline - concrete ranges, including the MAP funding projection
4. A cutover plan - how to switch with minimal business disruption

We deliver production migrations and modernisations for organisations in regulated industries, with the emphasis on compliance, business continuity, and zero-downtime cutovers. Whether you’re facing the end of ECC support, a hardware refresh for HANA, or just weighing the direction, the first step is understanding what you’re working with.

Planning an SAP move to the cloud?

Book a free 30-minute call. We'll give an initial read on the complexity of migrating your SAP environment and check whether your project qualifies for AWS MAP funding (typically 70-80% of partner fees).

Book a migration assessment