Questions to ask while planning for Cloud Migration

Content paraphrased from the following articles -
App migration checklist: How to decide what to move to cloud first
Choosing your cloud app migration order
Best practices for migrating virtual machines to Compute Engine
* CIO's Guide to Application Migration

How do you decide the order in which you migrate applications into the public cloud?
Consider following migration order for workloads by group:
Tier 1: Opportunistic (especially to maximize ROI)
Tier 2: Minimal risk
Tier 3: Ease of migration
Tier 4: Customizations




To decide if apps qualify as Tier 1: Opportunistic -

  1. Is this application significantly more expensive to run on-prem than it would be to migrate and run in the public cloud?
  2. Will this application require an upcoming hardware refresh, making it more attractive to move to the public cloud sooner rather than later?
  3. Are there services (or regions/instances, etc.) in the cloud that would make this application perform significantly better?
  4. Do these applications require any licensed software? How much will that cost and is it available in the cloud?

To decide if apps qualify as Tier 2: Minimal risk -
  1. What is the business criticality of this application?
  2. How many users (employees and/or customers) depend on this application?
  3. What is the production level of this application (development vs. production)?
  4. How many dependencies and/or integrations does this application have?
  5. What is my IT team’s understanding of this application?
  6. Does my IT team have proper, up-to-date, thorough documentation for this application and its architecture?
  7. What are the operational requirements (SLAs) for this application?
  8. What are the legal or governmental compliance requirements for this application?
  9. What are the downtime and/or latency sensitivities for this application?
  10. Are there line-of-business owners eager and willing to migrate their apps early?
To decide if apps qualify as Tier 3: Ease of migration -
  1. How new is this application, and was it designed to run on-prem or in the public cloud?
  2. Can this application be migrated using straightforward approaches like lift-and-shift?
  3. Is this application standardized for one OS type, or does it have flexible requirements?
  4. Does this application (or its data) have regulatory, compliance, or SLA-based requirements to run on-prem?
To decide if apps qualify as Tier 4: Custom applications
  1. Was this application built specifically for its current hardware? For on-prem?
  2. Do we have proper comments in the code to help us re-architect for the cloud if needed?
  3. How is this application intertwined within our total application landscape?
  4. Do we have the in-house expertise to migrate this application to the cloud successfully?
  5. Other questions that can help decide what to move to cloud first
What’s the application status?

1. What is the criticality of this application?
  • For example: How many users depend on it? What is the downtime sensitivity?
  • Tier 1 (highly important, 24x7 mission-critical)
  • Tier 2 (moderately important)
  • Tier 3 (low importance, dev/test)

2. What is the production level of this application?
  • In production
  • In staging
  • In development
  • In testing

3. What are the data considerations for this app?
  • Stateful data
  • Stateless data
  • Other systems reliant on this data set

4. How was this application developed?
  • Third-party purchase from major vendor (still in business?)
  • Third-party purchase from minor vendor (still in business?)
  • Written in-house (author still at company?)
  • Written by a partner (still in business? still a partner?)

5. What are this application’s operational standards?
  • For example: what organizational, business, or technological considerations exist?
  • Defined maintenance windows?
  • Defined SLAs?
  • Uptime-sensitive?
  • Latency-sensitive?
  • Accessed globally or regionally?
  • Deployed manually or via automation?
Guidance: Avoiding sensitive apps is often most desirable for a first migration.

6. What are the specific compliance or regulatory requirements?
  • ISO 27000?
  • PCI/DSS?
  • HIPAA?
  • EU Personal Data Protection?
  • GDPR?
Guidance: The fewer compliance or regulatory requirements, the better for a first migration.

7. What kind of documentation is readily available, and is it up-to-date?
  • System diagram?
  • Network diagram?
  • Data flow diagram?
  • Build/deploy docs?
  • Ongoing maintenance docs?
Guidance: The more docs that exist, the better!

8. What are the migration implications?
  • Easy to lift-and-shift as-is into the cloud
  • May require some refactoring
  • Need to modernize before migrating
  • Can wait to modernize after migrating
  • Need to rewrite in the cloud from scratch

9. Any business considerations?
  1. Is this system used year-round or seasonally?
  2. Is there a supportive line-of-business owner?
  3. Does this app support an edge case or general use case?
  4. Is this app managed by a central IT team or another team?
  5. Would a downtime window be acceptable for this app?
Guidance: having more supportive owners and stakeholders is always crucial to the success of initial migrations.

What are the app integrations and dependencies?
This is hugely important, since you might want to group applications into the same migration sprint if they’re coupled together tightly through integrations or dependencies.

10. What are the interdependent applications?
  1. SAP?
  2. Citrix?
  3. Custom or in-house apps?
  4. databases
  5. message brokers
  6. configuration storage systems
In other words, the full application stack
Guidance: Fewer dependencies are ideal.

11. What are the interdependent workflows?
  1. Messaging?
  2. Monitoring?
  3. Maintenance/management?
  4. Analytics?
  5. Services supporting your application (e.g. source repositories, continuous integration (CI) tools, and artifact repositories)
  6. Will the migration require changes to how to authenticate and authorize user access?
Guidance: Fewer dependencies are ideal.

12. Where is the database and storage located?
  1. Separate servers?
  2. Co-located servers?
  3. Is storage block- or file-level?
  4. Any other services to analyze?

13. Web services?
  1. RPC used either inbound or outbound?
  2. Backup services (and locations) in effect?
  3. Guidance: None of these are more or less ideal, simply something to be aware of.

14. Other questions to ask:
  1. Unique dependencies?
  2. Manual processes required?
  3. Synchronized downtime/uptime (with other apps)?
  4. Source code locations and whether you are able to 1) modify the source code and/or 2) rebuild the application
  5.  Deployment methods for the workload in a runtime environment. (e.g. whether you use an automated deployment pipeline or a manual one)
  6. What are the Security requirements?
  7. Are there any critical performance requirements?
  8. Are the components of my application stack virtualized or virtualizable?
  9. Can my application stack run in a cloud environment while still supporting any and all licensing, security, privacy, and compliance requirements?
  10. Can all application dependencies (e.g. 3rd party languages, frameworks, libraries, etc.) be supported in the cloud?
Guidance: The goal for first apps to migrate is to minimize complexity and labor.

15. Network related questions:
  1. Will you have one network for each application or for each environment?
  2. How will your applications access shared services?
  3. Will you employ a hub-and-spoke model of networks, or a full network mesh?
  4. How will you connect the various networks?
  5. Will you use a VPN connection between them or use a cross-project network?
  6. Are there any network restrictions?

16. What are the key cloud migration KPIs?
Some cloud migration KPIs you might select include:
  1. Page load times
  2. Response times
  3. Availability
  4. CPU usage
  5. Memory usage
  6. Conversion rates

17. Inflection points?
The most common inflection point is when the existing datacenter infrastructure is out of capacity or end of life. It is crucially important to target these inflection points because trying to convince a company to undertake a transformation project (to migrate to Azure) when their existing datacenter solution is perceived to be fit for purpose is much harder.
Therefore, key aspects to consider are:
  1. What are strategic objectives for the partner - e.g.: business model transformation, customer and revenue growth, moving away from additional capital investment?
  2. What are the business drivers for migration to Azure?
  3. What is the budgeting cycle in the company and who approves projects?
  4. When are the inflection points? This could include expiring colo/maintenance contracts, hardware depreciation/refresh cycle, end of support, existing hardware reaching capacity, customer expansion/growth in newer geographies
  5. Existing contractual arrangements? Who owns the existing infrastructure and maintenance, timelines, break-points, dependencies.
  6. What is the detailed financial breakdown for the as-is on-premise hosting versus the Azure migration? How long will it take to ROI?

Other references:
Cloud migration checklist: 5 steps to a successful journey - IBM, April, 2019
Preparing to Adopt the Cloud: A 10-Step Cloud Migration Checklist - New Relic, June, 2018

Comments