This SAP migration checklist tests an SAP landscape before a cloud cutover with 15 checks in seven areas, each with an owner and evidence. Five of the checks are stop checks: if one is not ready, the cutover waits.
Last reviewed 2026-11-14 by Manish Sharma.
An SAP landscape means the production, test and development systems together with the interfaces that surround them. Also, cutover is the move from the old production system to the new one. The checks below are specific to SAP, so general application checks sit in a separate guide. Then copy the tables into a sheet of your own, as this guide offers no file.
The Fifteen Checks Behind This SAP Migration Checklist
To begin with, the 15 checks fall into seven areas, and the table shows what each area asks. Also, stop checks are 2, 6, 7, 9 and 12.
| Area | Question it asks | Checks |
|---|---|---|
| Landscape and target | Do we know every system and what the target must carry? | 1, 2, 3 |
| Data | Do we know what moves and how we will show it matches? | 4, 5 |
| Downtime | Does the business accept the window, and did a rehearsal fit it? | 6, 7 |
| Interfaces | Does every connected system have an owner and a passed test? | 8, 9 |
| Testing | Did business processes run on the target, and who signed? | 10, 11 |
| Recovery | Can we restore, and who decides to fall back? | 12, 13 |
| Access | Do the right people, and only those, get in on day one? | 14, 15 |
However, some teams call this an SAP cloud migration checklist, and the contents are the same: 15 rows, each answered with a document, a log or a signed note.
A stop check halts the cutover until its evidence is on file. Also, checks 2, 6, 7, 9 and 12 are stop checks.
Owner, Evidence and Label for Every Check
To begin with, every check gets a named owner, the evidence to keep on file and one of three labels. Then ready means the evidence is on file and the test passed. Also, partly ready means some of it is done, or the paper is thin. However, not ready means nothing is on file.
However, a claim without a document, log or signed note behind it counts as not ready. Instead, ask for the document, not the opinion. Then ready is worth 2 points, partly ready 1 and not ready 0, so the maximum is 30.
Before you mark a check, ask to see the log, the document or the signed note. Then mark it only if the owner can show it.
Where a row is irrelevant to this estate, remove it from both totals and note the reason beside it. Also, the scorer, not the owner, picks which systems to read. However, stop checks are read on every production system.
| Check | Owner | Evidence on file | Label |
|---|---|---|---|
| 7. Rehearsal timing log | SAP basis lead | A log with the start time of one rehearsal but no end time | Partly ready |
However, the log shows when the rehearsal started but not when it ended, so nobody can say whether it fit the window. Until the end time is on file, however, that is partly ready.
Before Anything Moves: The SAP Migration Checklist for Landscape, Target and Data
Then the first five checks cover what exists and what moves. Also, mark them before any downtime is booked. Then use this SAP migration checklist section as the first read, as gaps here spread into every later area.
Landscape and Target Records
| Check | Owner | Evidence to keep and its test | What partly ready looks like |
|---|---|---|---|
| 1. System register | SAP basis lead | A register of every system with owner, release, database, size and peak use | Systems listed, owners missing |
| 2. Sizing record (stop check) | SAP basis lead | Measured figures of the current systems, with the target size set against them | Figures estimated, not measured |
| 3. Connection test | Network lead | A recorded test from each site to the target, with backup and access routes written down | Test run from one site only |
Then check 2 is a stop check because a target that is too small shows up on the first busy day, after the switch. Then read the target’s size against what the systems use at peak, not at an average hour. Also, treat any vendor sizing guidance as a starting point, and keep your measured figures as the evidence.
Also, for how Signisys plans the landscape around your systems, see how we plan an SAP move around your systems and downtime window.
Data Inventory and Matching Figures
| Check | Owner | Evidence to keep and its test | What partly ready looks like |
|---|---|---|---|
| 4. Data inventory and cleanup list | Data owner | Volume per system, plus a cleanup list with owner sign-off and before and after size for each item | Volumes known, cleanup unsigned |
| 5. Figures that must match | Finance lead | A signed list of the figures that must match after the move, an owner for each, and one trial comparison result | List written, no trial run |
However, cleanup decisions belong to the data owner, as deleting records is a business call. Also, the figures in check 5 are the ones a finance lead would check first after the switch, such as open balances and stock values. Then a trial comparison now shows whether the list is usable before the real move.
Around the Switch: SAP Migration Checklist Downtime and Interface Checks
To begin with, two areas decide how the switch goes: the window the business accepts and the systems connected to SAP. Also, three of the four checks here are stop checks.
Downtime Window and Rehearsal Log
| Check | Owner | Evidence to keep and its test | What partly ready looks like |
|---|---|---|---|
| 6. Signed window (stop check) | Business owner | A written window signed by the business owner, not IT | Signed by IT only |
| 7. Rehearsal log (stop check) | SAP basis lead | The timing log and run result of one rehearsal | Start time logged, end time missing |
Also, the window is a business decision, as the business bears the loss when the system is down. However, IT supplies the timing, and the business owner signs it. Also, for the order of the move and how a rehearsal is run, read the order of the move and how a rehearsal is run. Then this check asks only for the log and the result.
Interface Owners and Test Records
| Check | Owner | Evidence to keep and its test | What partly ready looks like |
|---|---|---|---|
| 8. Interface inventory | Integration lead | An inventory with a named owner per interface | Interfaces listed, owners missing |
| 9. Interface tests (stop check) | Each interface owner | A test record per interface, signed by its owner on the target and dated after the target build | Tests run on the old system |
The use case page has its own list of interface types, so this guide restates none. Also, a test dated before the target build shows nothing about the target, so check 9 requires the date.
Safety Nets: The SAP Migration Checklist for Testing, Recovery and Access
Finally, the last three areas are the safety nets: proof the systems work, proof you can go back, and proof the right people get in.
Test Plan and Sign-Offs
| Check | Owner | Evidence to keep and its test | What partly ready looks like |
|---|---|---|---|
| 10. Test plan | Test lead | A plan covering business processes, including a period close | Plan covers technical tests only |
| 11. Test sign-off | Process owners | A named sign-off per test area, with the open defect list attached | Sign-off given, defect list missing |
Also, this guide names test types once: technical tests show the system runs, and business process tests show people can do their work. Then check 10 asks for both, with a period close included, as a close reaches across many modules.
Restore Record and Fallback Decision
| Check | Owner | Evidence to keep and its test | What partly ready looks like |
|---|---|---|---|
| 12. Restore record (stop check) | Platform lead | What was restored on the target, how long it took, and who checked it | Restore run, nobody checked the data |
| 13. Fallback decision | IT head | A written decision: who decides, at what point, and a record that the fallback was tried | Plan written, not yet tried |
However, an untested backup is only a hope. Then check 13 sets the point of no return in advance, so nobody argues it at 3 a.m. Also, for the difference between staying online and recovering, see why staying online differs from recovering.
However, a backup that nobody has restored on the target earns no label above Partly ready.
Roles and Cutover Accounts
| Check | Owner | Evidence to keep and its test | What partly ready looks like |
|---|---|---|---|
| 14. Role mapping | Security lead | A role mapping and one trial login per role | Mapping done, logins untested |
| 15. Cutover and support accounts | Security lead | A named list with a second sign-in step and a removal date | Accounts listed, no removal date |
Finally, access follows role-based access control, so each person gets the roles the job needs and nothing extra. Also, the removal date in check 15 matters, as temporary accounts for the switch can outlive it.
Key Takeaway Each of the 15 checks needs an owner, a piece of evidence and one of three labels, but only five can stop the cutover.
Ordering the Fixes After Marking Your SAP Migration Checklist
Fix the stop checks before debating the total. Also, a stop check marked partly ready or not ready stops the cutover until the evidence is on file.
Then read the total by area, lowest first. Then give each gap an owner and a date, and re-mark after each fix, as one gap closed can change another label.
However, we recommend reading the five stop checks as a group first, as they share one question: if this fails on the day, can we still recover? Also, a high total with one stop check not ready is still a no.
Key Takeaway To begin with, read the five stop checks, then the total by area, lowest first.
Where This List Hands Over to Other Guides
Then each line below points to a guide for a different question. Also, this list does not repeat them.
- Dates: the maintenance dates behind the timing.
- Order and method of the move: covered in the downtime section above.
- Choice of cloud: a separate topic.
- Checks for other applications: checks for any application, not only SAP.
- Prices and fees: out of scope.
The software maker publishes its own ERP migration checklist, which covers themes such as cleansing master data and testing small data loads first. Then use the 15 checks here to mark your own evidence against it.
Signisys provides these services: see Signisys cloud migration and modernization services and cloud platform engineering support. A working session reads your evidence against the 15 checks, with no promised result and no price. No charge, with a fixed scope.
SAP Migration Checklist FAQ
What should we do with a “partly ready” label on a stop check?
What should happen to transports and other changes while we mark the SAP migration checklist?
What if the evidence sits with a supplier or interface partner?
What counts as evidence for an interface?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.