How to migrate SAP to cloud comes down to seven steps in a fixed order: inventory, target design, non-production systems first, data and database, interfaces, a rehearsed cutover, and go-live with hypercare. Each step ends in a test that shows it is done.
Last reviewed 2026-11-14 by Manish Sharma.
An SAP landscape is the set of production, test and development systems, plus the interfaces around them. The basis team is the group that administers those systems. S/4HANA is SAP’s successor suite to ECC, and this plan treats a conversion to it as a separate decision. The plan is provider-neutral and gives no prices, downtime figures, dates or tool names. It suits an IT head, CIO or SAP basis lead in India or the GCC who must sequence the move and know who signs off each step.
How to Migrate SAP to Cloud: The Seven Steps at a Glance
The table gives each step a suggested owner and a done-when test. We suggest these owners. Swap in the job titles your firm uses.
| Step | Suggested owner | Done when |
|---|---|---|
| 1. Inventory | The basis lead leads, with each system’s owner. | Every system, interface and custom program has an owner and a line on the list. |
| 2. Target and move method | The IT head or CIO owns the choice, and the basis lead advises. | The target design is written down, and the move method for each system is chosen. |
| 3. Non-production first | The basis lead runs it. | Test and development systems run in the target, and a mock run has finished. |
| 4. Data and database | The basis lead runs it, with the business data owner. | Record counts and key totals in the target match the source. |
| 5. Interfaces | Each interface owner tests their own link. | Every interface passes a test on the target, and its owner signs it off. |
| 6. Cutover rehearsal | The basis lead runs it, with the business owner. | A full rehearsal fits the agreed time window, and no interface defect is left open. |
| 7. Go-live and hypercare | The business owner and the IT head decide. | Production runs in the target, and the old systems stay until the business owner signs off. |
Teams that plan to migrate SAP to cloud in this order find out what is missing while the old systems still run.
Key Takeaway First fix the facts, then practice on copies, and only then touch production.
Before You Migrate SAP to Cloud: Team, Scope and the S/4HANA Question
Settle two things before step 1: who does the work and signs it off, and where an S/4HANA conversion sits against the move.
For the team, name a basis lead, a CIO or IT head who owns the decision, a finance owner for data checks, an owner for each interface and a security lead for access. Without a named person at each step, a sign-off turns into a general nod.
The infrastructure move and the S/4HANA conversion are two projects, and doing both in one jump multiplies what can fail. A conversion can keep the existing system’s data and settings, start with a rebuild, or carry over selected data only, and the market uses several names for these routes, so ask which one is meant. The name matters less than a clear order. There are three options to test:
- Convert first, then move. The cloud move then starts from a converted system.
- Move first, then convert. The old release runs in the cloud, and the conversion follows as a second project.
- Convert during the move. One project covers both, with one larger set of tests.
Three questions decide between them. Is the conversion project already dated? Can the team absorb two changes at once? Does the target give test systems for the conversion? Keep the answers on record, because they explain the order later.
The infrastructure move and the S/4HANA conversion are two projects. Decide their order before step 1, and write the decision down.
How to Migrate SAP to Cloud, Steps 1 to 3: Inventory, Target and Non-Production
Steps 1 to 3 give the move its map, its destination and a safe place to practice. The first three steps fix the facts, so the later ones can run to a schedule.
Step 1: Inventory Every System, Interface and Owner
First, list every system with its release, database, size and peak use. Then list every interface with an owner, and every custom program. Walk the list with the people who use the systems, since the basis team alone does not know every link.
Done when each item has an owner and a line on the list.
Step 2: Design the Target and Pick a Move Method
Size the target from measured use, not from the old hardware. Then settle access roles, the recovery design and the network links to your sites. Names for cloud servers vary by provider, and infrastructure as a service is the plain term.
Three kinds of move are available, and each comes with a question for the basis team. Moving as is to cloud servers asks whether the current database and release still run there. Changing the database asks whether SAP supports the target database for your release. Redesigning asks whether the business wants the change now. The AWS guide to SAP HANA migration scenarios groups moves by source database, such as a non-HANA database or an existing HANA system, which is why the database question comes first. Then ask which server types are certified for your SAP release, and check the answer in SAP’s own documentation and the provider’s.
AWS and Azure are the two platforms Signisys works with, and this plan compares neither.
Step 3: Move Non-Production Systems First
Build test and development systems in the target first. Then run a mock run of the data move, clean the data and check the custom code there. A mistake on a copy costs a rerun, while the same mistake in production costs a business day. This step tests the plan on copies before anything live depends on it.
Done when the test systems run in the target and a mock run has finished.
How to Migrate SAP to Cloud, Steps 4 to 7: Data, Interfaces, Cutover and Hypercare
Steps 4 to 7 move what the business depends on. Each one needs the earlier steps to be done first.
Step 4: Move the Data and the Database
Choose the method from the documented routes for your source database and release, such as those in the scenarios guide linked in step 2. Clean the data first, because the move copies old problems along with the data. Also, agree the downtime window with the business before the first rehearsal.
Then reconcile. Compare record counts and key totals in the target with the source, and keep the comparison as evidence. Ask counsel where your data must be hosted under the rules that apply to your sector.
Step 5: Test Every Interface Before the Switch
List the interfaces from step 1: bank links, tax portals, partner connections, warehouse and payroll links. Then test each one on the target with its owner, and confirm the network path from your sites. Each owner signs their own interface off. One untested link is enough to stall a go-live.
Record the test, the date and the owner’s sign-off for each link on one line of the step 1 list.
Step 6: Rehearse the Cutover Until It Fits the Window
Rehearse on a copy of production and time every task against the agreed window. Agree the decision point and the fallback in advance, so nobody argues about them at 2 a.m. Then repeat the rehearsal until a single run fits the window and every interface defect is closed. This plan claims no fixed number of rehearsals.
rehearse on a copy of production.
time every task against the agreed window.
agree the decision point and the fallback in advance.
run again until a single run fits and every interface defect is closed.
Key Takeaway Rehearse until a single run fits the window, with every interface defect closed.
Step 7: Go Live and Watch Closely in Hypercare
After go-live, hypercare means closer watching than normal for an agreed period. We recommend watching the first month-end close in particular. Test recovery as well: how recovery differs from high availability explains why a failover test and a restore test answer different questions. Also, the old systems stay until the business owner signs off.
Four Set-Up Mistakes When You Migrate SAP to Cloud
These four mistakes are easy to make on a first move and costly to fix late.
- Converting and moving in one jump with no decision. Two projects then share one set of defects. Record the choice from the S/4HANA section first.
- An interface list built from memory. The link nobody listed fails at cutover. Build the list from step 1 and walk it with each owner.
- One rehearsal on the weekend of the move. A single run shows the window is too short only when it is too late to change it.
- No named sign-off per step. Without a name, a step closes when people stop asking about it.
What This Plan to Migrate SAP to Cloud Leaves Out
This plan covers the order of the move and nothing else. These topics sit elsewhere:
- Scored readiness checks: set out in a mark by mark check before an SAP move goes ahead.
- Choosing between AWS and Azure: a separate topic.
- Product-specific tool paths: each SAP product has its own, and this plan names none.
- Moving any application: the general method for moving any application covers it.
Get help when interfaces are not mapped, when no basis lead is in place, or when a conversion and a move are planned together. How Signisys plans an SAP move around your landscape and downtime window covers how we run such a move.
Signisys provides our cloud migration and modernization solution and our team for cloud platform work. A consultation reads your systems, interfaces and downtime window against the seven steps. The review does not promise a result. No charge, with a fixed scope.
How to Migrate SAP to Cloud: FAQ
How many cutover rehearsals does an SAP move need?
Who should sign off before production moves?
What if the rehearsal runs longer than the agreed downtime window?
Does the date SAP supports ECC change the order of the move?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.