How to analyze your applications for a migration to Cloud? - Part One

LePecheOriginel

Thinking about moving an application to Cloud? Your current on-premise data center is shutting down, and you need to move your infrastructure to Cloud quickly? Worried about how to analyze your applications for Cloud dependencies? Here is the silver bullet:

Snowmobile

Just look at that beauté. But, for the rest of us that are not fortunate enough to have access to a Snowmobile (see AWS Snowmobile), we will need to plan a migration. In this post (and some others), I will share my experiences on analyzing a portfolio of applications for a Cloud Migration. Outputs of this analysis will influence your architecture on the Cloud.

Important Disclaimer: This post (and others in the series) is mainly focused on analyzing applications before a full-scale lift and shift Cloud Migration. I want to share my experiences and lessons learned about what to look for in an application before the migration. I will try to steer clear of tasks and planning specifically related to migration (wave planning, service interruptions, etc.) as I can’t cover it sufficiently.

1. The Prerequisites

To analyze your applications properly, there are some prerequisites. Here are some things that are must-do in my experience.

  • Infrastructure Inventory: Like your Application Catalogue, you must have a complete, accurate infrastructure inventory. I will not go into detail but typically, inventories are not kept accurate and require certain effort to bring up to date.

  • Application Dependency Mapping: You must have an application-to-infrastructure mapping that shows the relationship between applications and infrastructure components. Application A runs on VMs B-C-D, database E, uses Load Balancer F, etc.

  • Discovery: The connections to/from your servers. Before any migration activity, it is essential to monitor your environment for dependencies between infrastructure components. This is used to plan the migration, but it is also useful to improve your understanding of your environment. You might be in for a surprise; discovery exercise typically uncovers forgotten code and application on where you least expect.

All right. Now that we have some data let’s move on to the next step.

2. The Catalogue

First of all, build an application catalog if you don’t already have it. You need this to cover all applications and properly analyze them, and this is crucial. You should at least gather below information about each application that you are planning to move to:

  • Application Name: Obvious but important. Make sure the name you get is what your client calls it; you can call it Microsoft Dynamics CRM, but it might be just “CRM” for them, and there might be more than one. Just saying.

  • Application Description: What is it for? What is the purpose of this application? What would the world (of the customer) lose if this application suddenly stopped?

  • Application Module: There might be different owners to these modules. You will need to involve everyone.

  • IT Owner(s): The unsung hero in all of this. As the Accountable in RACI, they will carry the responsibility of a service interruption. They will also run the tests after the cutover.

  • Business Owner(s): As a single point of contact for anything business-related.

  • Hosting Location: The customer might have several DCs or a system room lying in a factory somewhere.

  • Customers: External or internal? Different departments? You are going to go to them for service interruption, so take good note.

  • Involved 3rd Parties: Who is responsible for application development? Operations? Any other required 3rd parties, like IT technicians from the field? You might need them during the migration wave.

  • Current Lifecycle Status: In case an application shuts down before the migration. It happens.

  • Business Criticality: You should know this by heart. Know what you are getting into wave by wave.

  • Known Issues: You can’t capture all defects here (and it’s not necessary), so collect if there is something like a performance issue. You will run into it during your cutover.

  • Preferred Service Interruption Window: This must be clarified again days before the actual migration wave but still.

So, this is not an extensive list, you will probably need to gather more details, but I doubt you will make do with less. Also, migration is an excellent opportunity to enrich your CMDB; you will be collecting a lot of information anyway. You might not get a similar chance again soon.

In the next post, I will focus on the deeper analysis of the Catalogue we build here.

You should also read: