Olaf Zimmermann and Mirko Stocker
Olaf Zimmermann and Mirko Stocker Co-authors of MAP, DPR, IRC

Questions to Ask when Migrating to the Cloud

(Updated: )
Reading time: 5 minutes
Questions to Ask when Migrating to the Cloud

Content Outline

Cloud-Native Application (CNA) has been a trending buzzword in blogs, books and articles for several years now. But what about migrating an application to the cloud? How to find out whether one is ready to move, and what needs to be done to make it fit (for) the cloud?

We collect 18 questions here that can be asked in early cloud migration meetings—or even earlier when planning migration projects and estimating their effort. They cover six topic areas: migration goals, interfaces with other systems, data management, user management, deployment and systems management as well as cloud status and directions.

We deliberately limit the number of questions to three per area; of course there is a lot more worth finding out, but these 18 get us going pretty well.

Migration Goals and Requirements

No journey without a destination! 🎯

  1. What are the business objectives of and expectations for the envisioned cloud migration?1 What are the most important and/or representative use cases of application functionality that should be migrated?
  2. What are the non-functional requirements that are met, or not met, by the existing system, including desired qualities and constraints? Which properties should be preserved and which ones should improve during the migration?2
  3. Which architectural decisions made for the existing system can be revisited and possibly changed when migrating to the cloud? Which ones are seen to be too costly or too risky to revise?3

Interfaces with Other Systems

Context matters! ✨

  • What are the inbound and outbound interfaces of the system?4
  • Where are the consumers and/or providers of the external interfaces located?5
  • Which integration styles, API design patterns and communication protocols are used to provide and/or consume the interfaces?6

Data Management

When it comes to data storage and retrieval, location is just one of many important concerns. 🏠

  1. What are the data access profiles (by user group, by channel type)?
  2. Which persistence paradigms and technologies are used? Is data stored redundantly, possibly in a distributed fashion (sharding, partitioning)?
  3. How are the backup-and-restore requirements satisfied? For instance, do disaster recovery procedures exist?7

User Management

Never forget the people that work with an application to be updated! 👪

  1. How are users registered? Are there delegation models (users registering users)?
  2. How is access controlled (authentication, authorization)?
  3. Is multi tenancy supported?8

Deployment and Systems Management

It is essential to find out what the application-specific management concerns are and how the entire system is operated today. 🔧

  1. How do the network topology and security architecture look like (load balancing, fail over, gateways, directories)? How is the application monitored?9
  2. What amount of automation exists (including CI/CD pipelines)? How are container and cluster management technologies such as Docker and Kubernetes used?
  3. What is the current workload on/of the existing system in terms of local I/O, network traffic, storage usage, CPU consumption (in normal operations, under peak load, in error cases)? Can workload patterns be observed?10

Cloud Status and Directions

We need to know what has been discussed or even decided already — so that we do not assume a green field implicitly. 👓

  1. Have a cloud deployment model and service model already been chosen, or does a short list of cloud offerings exist?11 Should the migrated application be cloud agnostic?
  2. Are other applications (see “Interfaces with Other Systems”) already running in the same or another cloud? If so, are synergies possible?
  3. Does the team that develops and operates the existing system already have experience with the chosen or shortlisted cloud technologies?

How to Use the Questions

Exercise: Ask and answer these 6*3=18 questions for the system you currently work on, even if it is not going to be migrated to a cloud any time soon. Struggling? Here are some hints.

Use common sense. Listing questions is one thing, but how to ask them properly?

  1. Customize. Most of the questions can be asked in any fitness assessment or evolution planning effort. We made a few cloud-specific adjustments only; feel free to fine tune further.
  2. Prioritize. Not all questions always are equally important. If in doubt, leave some out — and come back to them later as needed.12
  3. Ask openly. Open questions (such as most of those in this post) stimulate discussions. Answers to them help make informed decisions later in the cloud migration or unveil that deeper investigations are needed.

Both the current situation (“as is”) and the envisioned state and its value/benefits (“to be”) are of interest; sometimes, you even might want to understand how the current situation came to be. Hence, you can ask all these questions in “yesterday”, “today” or “tomorrow” modes. The questions may also serve as checklists to make sure that important tasks are not forgotten.

Ask in style. Take all this with a grain of salt, and adjust to your needs:

  • Explain why you ask and be happy to provide examples that illustrate what you are looking for. You do not want to come across as a stiff “cloud authority” but as empathic.
  • Friendly, factual questions lead to answers of a similar kind usually; questions that contain opinions (or accusations) cause defensive ones (or counterattacks). It is perfectly fine to agree or disagree if this leads to fruitful discussions.
  • Do not confuse or mix cloud migration and other re-engineering work, otherwise, you lose the baseline for effort-benefit comparisons (for advice about interface refactoring, go here).
  • Looking at the design decision and options, shared services have advantages and disadvantages. For instance, a unified monitoring service makes it possible to compare and correlate events and saves some effort, but updates to it must be coordinated (at least those that change the interface and the service levels).
  • Metering and billing might already be in place for the application and/or the services that it uses. If so, the current Pricing Plan requires attention, for instance in terms of its granularity.

If the external dependencies are part of systems you control, you might want to repeat the cloud migration readiness analysis for each of them.

What’s next? If you have already decided on a cloud provider, make sure to check out their respective cloud migration guidelines. For example:

Wrap up. We are glad you made it here despite all the tempting links. 😉

With the questions from this post and the provided background information you should now be ready for a cloud migration readiness assessment. But maybe you do not agree with our question set? What do you ask when migrating applications to the cloud? Let us know.

Happy and safe journey to the clouds!

– Olaf and Mirko

A shortened version of this post is available as a Medium story.

Notes

These notes include possible answers to the questions.

  1. Valid answers include: cut cost, achieve better runtime qualities, find new users. The “Cloud Strategy” book lists these and more reasons to go to the cloud (see a previous post). ↩

  2. Make them SMART and use a standard catalog such as FURPS or the ones from the Software Engineering Institute (see here). ↩

  3. Examples: Programming languages and their versions? Application servers and integration middleware? More recurring decisions are identified in this post. ↩

  4. Both human users and external system integrations are of interest. You may want to come up with a context diagram (architecture modeling activity in DPR, C4 model). ↩

  5. These consumers and providers might already reside in a cloud (so data transfer charges might apply). If so, they may be able to serve as role models. If not, they might have to stay behind. ↩

  6. Not all systems use communication protocols that are suited for the Internet. For example, files might be exchanged through shared network drives at present. Communication using raw sockets might also be restricted, depending on the chosen cloud service offering. ↩

  7. The article “Consistent Disaster Recovery for Microservices: the BAC Theorem” discusses related tradeoffs. ↩

  8. See “Re-Engineering Data-Centric Information Systems for the Cloud – a Method and Architectural Patterns Promoting Multi-Tenancy” for related insights and possible solutions. ↩

  9. Any information about involved staff/roles (including support levels), systems management procedures and tools is useful. Hopefully the “bastard operator from hell” stays in fiction! ↩

  10. The order of magnitude of the current and expected workload are good enough approximations if exact numbers are not available, at least in the early phases (being aware of resource consumption is one of our seven cloud-native traits). ↩

  11. Examples: Public infrastructure-as-a-service (running custom images with all middleware such as messaging system and database installed), platform-as-a-service with its variations; container orchestration; all offerings that form the design/solution space at cloud providers. ↩

  12. This actually is our first rule of method/practice adoption in the Design Practice Repository (DPR). By the way, we violated it somehow here—by squeezing a follow-on question in some of the 6*3. Sorry for that!😉 ↩