Any project to migrate applications from an On-premise environment into your future normal Cloud environment is a challenging one. However, with the right resources and planning, it’s more than manageable.
Having migrated most of the SAP product set, as well as non-SAP applications, into IaaS environments, I’ve certainly learned a few lessons along the way. Here are my top tips for ensuring your migration runs as smoothly as possible.
1) Planning and understanding is everything
The project team must fully understand the landscape in order to deal with the inevitable change of migration priorities. In order to do this, they should have an editable and complete landscape diagram of the logical applications and another with the physical servers. They must understand how things hang together in order to perform a solid migration plan.
2) Map the dependencies between applications
This should be done so that the project team understands the constraints when moving applications. Pick a central application within the landscape as a migration focal point and the plan will practically write itself as each system is planned in relation to its timing and constraints.
3) Test everything you can
Many things won’t work straight away. Some will be fixed easily and others will require a lot of work. Two areas which always seem to trip projects up are 1) printing and 2) external Interfaces. Do not underestimate how important these items are and how high a priority they will escalate to if they are not working post migration. Furthermore, don’t underestimate the lack of support you will get from third parties as quite often testing with third parties is hampered because of commercials or a lack of testing resources.
My advice is give these items an owner early on and make them responsible for follow through.
4) The order of systems in your migration plan will change
This can sometimes happen because of slippage, sometimes because of client needs, and sometimes because of a technical constraint. Change is going to happen and the easiest way to work with this is frequent planning reviews and robust challenges to the reasoning for the change.
5) Client-partner collaboration is key
No-one knows more about the application configuration than the client. And no-one knows more about the migration processes than the partner. It is essential to have both sets of knowledge working together. If the project involves the replacement of a service or support partner then this is a political minefield. Few service providers want to provide another with all the hard won secrets of the client and without clear commercial guidance from the customer, I have been given the run around by some incumbents. Always be professional, develop good relationships with people and be respectful of commercials of each party.
6) Take the opportunity to make some pro-active changes in the landscape
Understand where existing pain-points or broken processes are located. These should be factored in when the design of the new landscape is being approved – as long as they don’t impact the commercials or the timeline that is.
7) Remember that your beautiful, organised, and robust landscape has to live in the real world
It will change and it will undergo DR at some point, so it needs to be as operationally capable as it is functionally capable.
8) Not every application will be capable of being moved into the Cloud
Look at the constraints and critically evaluate the case for moving it. I have used the following classification system for evaluating applications:
- The application is capable of being moved to the Cloud without any changes
- The application is capable of moving to the Cloud but it will require architectural rework and changes in some non-functional capabilities
- The application can be replaced by a hosted software option
- The application cannot be moved into the Cloud.
If it does not suit migration, then bring this to the project board and work through it with them. The constraints may be support related, or they may be latency related for example moving SAP BW into Amazon and leaving ECC On-premise can impact data loads and reporting.
9) The methods used for performing the migrations will not be the same for each application
Migrating ECC is different to migrating BusinessObjects which is different from migrating Web Dispatchers.
10) Each application must have a technical owner responsible for the migration
This is applicable to both the method and the timing of that migration in relation to the others. That is not to say that there is only one person working on that application, it simply means that during the migration phases that person is responsible for the documentation and the task list for the application.
11) Finally one that a lot of people forget about….have fun!
There’s a lot of learn on these projects and a lot of lessons which can be applied from previous ones.
This is not an exhaustive list, nor is it meant to replace a good project management methodology on migrations. These are simply things that I have found to be good and bad during projects, what causes them and how to navigate around them. Hope you find them useful and that they help you avoid some bear traps.