Practical steps when planning a cloud migration project

In our previous post, we covered the first steps for migrating SAP, including why companies are moving to the cloud, and some practical considerations. In this post - which is a little more technical - we take a deeper dive and look at guidelines that should be applied to all SAP migration projects, regardless of complexity. We include practical experience from successful migrations on client projects. These are generic enough to be applicable to any SAP cloud migration project. Additional steps may be needed if you combine a technical migration project with a functional upgrade, like S/4HANA, and the sequence of steps will also differ based on specific project requirements.

Download this Migration Preparation Checklist which gives you a general sequence of important steps and checkpoints for a cloud migration project.

1. Plan. Begin with a sandbox that is representative of production. This may be a recent system copy of a production system with masked data. Speak to us about our data masking capabilities with Data Sync Manager. Our recommendation is not to time-slice this system, as it will be used it to simulate the future production upgrade and should be as similar as possible to an actual production system. Run this sandbox through the migration process end-to-end, and document all steps and run times. Typically, this system is a standalone system that is not highly integrated with connected systems. The purpose of this run is to document the process and run times of long running phases. Plan sufficient time for this first execution, because there are ample learning opportunities and potential trial and error in this phase. It’s often necessary to repeat this phase after all sequencing and discovery has been confirmed. Document, document, document!
2. Discover. Basis team will perform connectivity testing and sanity checks before functional teams perform their discovery of the impact of the migration on their critical processes. This migrated sandbox should be a platform that will answer the inevitable slew of questions that functional SME’s have been asking since early planning phases. How will the new platform affect me and my users? Will any of my processes be broken? This phase should be long enough to answer all of these questions without time pressures that could lead to hasty decisions - ideally some months before the project swings into actual realization.
3. Realize. When migrating development, you’ll need to make a choice.
   1. The traditional approach would be to migrate the existing development system. This is another opportunity to rehearse the production migration.
      Figure1: Traditional migration methodology
      
      
   2. However, we have found that customers can benefit from rebuilding development from the already migrated sandbox because:
      1. The migrated sandbox has a repository of the production system it was created from. This is an opportunity to dump the old development system (with potentially years of abandoned development that was never moved to production).
      2. The migrated sandbox has good data in it. This is rare in a development system. Consider creating a small data client that can be refreshed in future rather than the full (large) production client. The quality of transports released from development can be greatly improved if changes can be tested before transports are released.
      3. Post-copy you can migrate development history from the old development system to the newly created system. Details in SAP note 130906 (requires SAP login).
      4. Much faster turnaround than migrating another system. Good for time-constrained projects.
         
         Figure 2: Accelerated migration methodology
         
         
   3. Whichever option you choose for the development system, both are possible using a product like our Data Sync Manager.
4. Test. Execute test scripts for important business processes. If you did not create this system from the copied sandbox and have little or no data for testing in this development system, consider using a product like Data Sync Manager to provision test data for this testing.
5. For the QA system you have the same choices as development (item 3 above); rebuild afresh from the sandbox (potentially with a much smaller, sliced data client) or copy the existing QA system from customer datacenter to hosted partner.
6. You have a choice to perform integration testing either at this stage, or after the production test migration. If integration testing is not in scope at this phase, include some testing that was perhaps not possible in the previous testing phase. This QA system should be more integrated than development and presents an opportunity for testing cross-system business processes and interfaces.
7. Perform a test migration of production. This is required by SAP and cannot be skipped. This is your final opportunity to test the migration document with a full-sized production copy. Finalize the document including run times.
8. Final integration testing. Last testing opportunity. End-to-end testing of all business processes and interfaces.
9. Production copy using tried and trusted migration document. Includes timelines and detailed step by step instructions, touch points with other teams and smooth handovers between teams.
10. Resume normal production support processes such as backups and monitoring. Hypercare support process should be in place for immediate response to any issues until the migrated systems have been running for a predetermined period that includes coverage for scheduled critical processes such as month-end processing.

Naturally this is a simplified high level plan, but the general approach has proven successful for a number of larger projects.

There are several compelling reasons why we use Data Sync Manager ourselves for as many of these processes as possible:

• Reduce system size by excluding redundant historical transactions when creating new clients
• Refresh clients quickly and independently of other clients on the same SAP system, including but not limited to refreshing a small data client on development
• Scramble sensitive data for all copies originating from production
• Reduce cycle times and post-processing effort for each of the copy steps
• Easily create repository-only empty system shells, or customizing-only clients and selectively copy only desired data into them for leaner, high quality clients

If you’d like assistance with any planned migration, upgrade or conversion projects, please get in contact with us. We would be happy to plan, execute, advise, QA or even just chat about your requirements.