The best approach would probably be determined by other factors.
- Are you going to change any aspect of the source system release, support package stack, EHP, during this migration? If you are not changing anything related to SAP itself, only the OS and DB, then the classic SWPM migration approach would seem appropriate (r3load export/import). This process has been used for years and there is plenty of information/tips in Service Marketplace and on forums about it.
- Using DMO as part of SUM would be applicable if you were bundling in some type of update, then DMO would be best since it combines the update with the migration. This reduces the process to one downtime window and simplifies testing/verification
- As SAP now permits the use of DMO/SUM without applying an update, it still includes many steps from SUM that still makes the process complex. This approach would help if you need to minimize your downtime window since this incorporates a shadow instance, though.
When dealing with relocating an entire SAP landscape, the simplest approach is usually the best.
Hi,
additional information: for DMO-Scenario it's not necessary to have a valid OS/DB-Migration-Certification. If you use "Standard"-OS/DB-Migration with R3load you have to be certified. Using SUM with DMO instead of SWPM allows you to combine Upgrade/Support-Packages and even the Import of Transport-Requests with the OS/DB-Migration Tasks. And finally you have only one downtime, and one project with all the effort included (project management, testing, ...). DMO-Downtime is longer then doing Migration only. Some customers prefer 2 shorter downtimes and simpler projects instead of one "big" project with longer downtime.
BR
Markus
Add comment