Our recent whitepaper described the various stages of a cloud migration journey. The basic steps were: (1) determine the context, (2) discover the current situation, (3) develop a roadmap and plan, (4) perform the testing and migration tasks, and then finally, (5) monitor and evaluate the results.
There are three pre-requisites for success: knowing where you are starting from (the current situation), understanding the constraints (i.e., the context) on the change process, and knowing where you want to get to (i.e., choosing your destination). There will always be multiple paths, each with pros and cons, that can get you to your destination.
Let’s look at the context and constraints in a little more detail.
Cloud migration is a project!
It’s worth a reminder that cloud migration should be a project – not a never-ending process. Much like any other IT project, the enterprise’s project scoping, planning, designing and managing processes should be used.
However, it is also important to be clear if you are establishing a shareable, greenfield cloud platform or adding to an existing standardized cloud environment. Issues sometimes arise when you are re-using assets that other departments have paid for.
Also, it is very important to be aware of any business policies, governance rules or technical standards that need to be adopted or accommodated. For example, a corporate “cloud first, mobile first, wireless first” strategy could help with the business case for choosing a cloud solution.
Many types of cloud solution
One of the goals of planning is to reduce the range of options to be evaluated during the design process. Cloud computing has increased the “degrees of freedom” available to the solution architect, such as the choice of service provider, use of public vs. private clouds, service level choices, multi-tenancy, different technologies, etc.
With Infrastructure-as-a-Service (IaaS), for example, the compute, storage and network resources could be purely cloud-based, a hybrid (a combination of public and private clouds), or even an assembly of cloud and legacy components.
More choices are available when application development is involved. An existing application may be “lifted and shifted” to an equivalent cloud Platform-as-a-Service (PaaS). Modernizing the application, on the other hand, could involve changing the middleware platform, changing databases, converting to a microservices architecture or even adopting a modern serverless model.
Another option, of course, would be to outsource the application entirely using Software-as-a-Service (SaaS).
Are support services available?
Shared support services are a third area to be addressed in a cloud migration project. Support services include operations management, cloud administration, and security management.
For example, an independent, non-sanctioned “Shadow IT” application might choose the cloud provider’s user interface and access controls, while corporate applications would have to adopt a consistent Identity and Access Management (IAM) system and a standard interface “look and feel.”
Security and privacy are very important considerations in any cloud migration projects, but it is neither reasonable or practical to re-invent the security and privacy control requirements for each project.
Phase 1 of your cloud project establishes the migration parameters and sets the scene for your project. It should provide the guidance and best practices you need to be successful.
Next, you will need to find tools to help you capture the requirements and document the status quo.
This is part 1 of a 2 part series-keep an eye out for the next installment, "Cloud Migration: Tools of the Trade".
Want to learn even more from Don? Join us for a web seminar with him, Thursday April 19th at 2:00 pm EST.
Registration is open here.