The Cloud Migration Gotchas..

All leading cloud providers have a well defined Cloud Adoption Framework that will help you shape up your cloud migration strategy. Customers would eventually end up with one of the 5 'R's of rationalization - Rehost(Lift&shift) , Refactor, Rearchitect, Rebuild or Replace.  Once you have identified the approach , next steps would be planning and execution. However the best  plans laid out by  a professional services team can be driven off the track by  customer specific environment challenges. If you are helping customers with cloud migration, here are few things that you might want to think through again and prepare for before you go all in .

1.Start with stakeholder buy in

The first step called out in Azure Cloud Adoption Framework is Strategy or rather the motivation of the organization to move to cloud. Though this would usually be done in the presales phase and might have the buy in of the C-Suite, it is very important that this acceptance trickles down to stakeholders of respective application. There could be resistances in terms of adopting new technology i.e. fear of the unknown. Most often this can be traced back to lack of skill up efforts . Ensure that you factor in Skill development efforts during the plan phase . Remember,  you might be an expert in the cloud but for the customer it could be all very new and scary. It is important to give confidence to customer stakeholders that you will not just help them cross the bridge to cloud, but also help them survive there. It could be through extended support after migration , trainings or engagement with support team for ongoing support.

2. DevOps is  not just for software development

Be agile in your cloud migration plan, learn from your mistakes and continuously optimize . The waterfall approach of completing the planning of entire suite of applications before migration will impact your migration timelines. Integrate  DevOps culture and agile methodologies in your migration process. For eg:  leverage IAC for idempotency of  base infrastructure. Identify and automate all migration patterns as much as possible. The success of a migration projects  depends on the cohesiveness of teams involved, be it the migration team, application team, infra team and the stakeholders. The culture shift to DevOps helps where responsibilities are equally owned by everyone involved

3.Assumptions can be dangerous

While working as a service provider helping customers with cloud migration, it is important to reach a common understanding on  the scope of migration. To be more direct - don't assume that scope of work is crystal clear for everyone involved just because there is a document that is signed off on the same. It is prudent to have  a scope discussion during initial phase of migration with stake holders so that everyone is clear on  roles and responsibilities. If there are any add-ons in your agreement with the customer, for eg: enabling monitoring, backup , DR etc.. ensure that there are no grey areas on the same.   For eg; enabling DR once the application is migrated to cloud can become a project in itself . The activities that will be done post migration for DR has to be clearly defined and agreed with customer to avoid scope creep during execution. Be customer centric, but keep the expectations very realistic and get buy in from stakeholders.

4. When in doubt do a POC

In case of complex system migrations, factor in time and effort to do a Proof-of-Concept( POC) before touching the production systems. This could be  a separate environment in itself or one of the non-prod environments of the applications. Especially when you are integrating new cloud native services in your architecture, doing a POC is inevitable irrespective of whether you had done individual component testing independently. This could delay your migration timelines, but its worth the wait than resorting to firefighting post migration. 

5. Take Legacy systems with a pinch of salt

Often customers  prefer Lift & Shift of legacy workloads to cloud. There could be multiple factors contributing to this - unknown dependencies, efforts required to refactor , application sunset being planned in the long term etc. You can use tools like Azure Service map to detect dependencies to an extend. However its always better to err on the side of caution and factor in buffer time to mitigate any blockers that could crop up due to legacy components. As discussed in the previous case this could be one of those scenarios where a POC might be required before the migration if feasible.

Read more about Microsoft Cloud Adoption framework that is designed to provide end to end guidance for customers on the adoption strategies best suited for your business scenarios here :https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/