Before we start Part 2 of 'Cloud Migration Done Right,' we recommend reading Part 1, which covers the prerequisites, analysis, and planning necessary to kick off Cloud migration for your enterprise/application(s). In this blog, we will focus on the next steps, assuming that all the foundational activities have been taken care of.
The next crucial step for the Cloud migration journey is to start Proof of Concept(POC). It is never a good practice to directly begin the full migration without understanding how the Cloud infrastructure will work for your enterprise/application(s) from functional, compatibility, performance, infrastructure flexibility, and cost savings standpoints. Once the POC is done, there will be enough data points to make an informed decision and evaluate if the Cloud infrastructure fits your needs, if so, at what level. Once this evaluation is complete, full migration can be planned and executed.
Proof of Concept Analysis
As part of this phase, lay out what Cloud services you will use, what instances and capacity you would need, and whether any cloud-native offerings would work better for your application(s) needs. It would be best if you also had cost estimates and Reference Architecture ready before sorting out all details of handshakes between on-prem and the Cloud.
1. Cloud Services Mapping
Each hardware and software component your application(s) uses at an on-prem data center, like DNS, Load Balancer, Scheduler, Caching, Virtual Machines, Network Storage, Encryption, Database, App Servers, Messaging, etc., would have a corresponding service on the Cloud. Each provider would have their own terminologies, and it's essential to understand all these services from the Cloud Provider you have chosen. Once you understand these requisites, map each of the services to your current on-prem setup and create a list of Cloud services you would need for your application(s).
2. Capacity Assessment
There could be various components your application(s) relies on, like an Application Server, Database, Web Server, VMs for some third-party software, etc. First, start with your current on-prem production environment and list the capacity of infrastructure it uses for various components. Once you have the current capacity for your production environment, carry out a capacity assessment for the Cloud by working with professional support teams. Note that you can pick whichever environment you think fits your POC purpose. Here, we're referring to a production-like environment to execute performance evaluations as part of the POC.
3. Cloud-Native Offerings Assessment
While evaluating various aspects of the Cloud from an infrastructure standpoint, you will come across various Cloud-native services like Database-as-a-service, App Server-as-a-service, etc. Evaluate if they make sense, are compatible with your application(s) software eco-system, and are supported. Be mindful while planning a lift-and-shift of your current application and reduce variables to the mix. Sticking to the base infrastructure on Cloud makes sense as an initial implementation. Once your application(s) is on Cloud infrastructure, you can always pick each component to move to the Cloud-native offered services easily.
4. Cost Estimates
Once the assessment of cost and Cloud services are in place, it's time to carry out cost estimates of the environment for the POC. While building the POC for the environment, work with the identified Cloud provider to come up with estimates for all the services you would need for the POC. Typically Cloud providers offer POC grants for their infrastructure. Be sure to discuss this with the provider and make it part of the cost estimates.
5. Reference Architecture
In this phase, it's time to put everything together into a reference architecture to get a glimpse of how your application(s) will look and work on the Cloud infrastructure. Once the reference architecture is drafted, review it with all the stakeholders in your organization as well as the vendor partners and Cloud partners, for their feedback. The on-prem data center and Cloud must have secure connectivity, and the providers must also offer services for it. If there are application(s) already on the Cloud at your enterprise, there is a high chance that such connectivity already exists. If not, you need to engage networking and security teams to discuss and establish such connectivity.
6. Data Flow Diagram
It is important to detail the Data Flow diagram for your application(s) and to explicitly call out how the handshakes will happen between on-prem applications and your application(s) on the Cloud. Every aspect of how the data will flow, security standards, encryptions, etc., must be addressed.
Once the POC analysis is in place with all the groundwork done, it's time to execute the POC by setting up a clear plan with objectives. Post the POC execution, compile all the findings and align with the objectives to be presented to all the stakeholders.
1. Setting Objectives
To begin with, set clear objectives for the POC. For instance, you may want to evaluate the performance and cost of Cloud infrastructure for your application(s) without impacting functional output. List out all tests you would like to carry out for such evaluations and the deliverables to be produced.
2. Planning and Execution
Once the objectives for the POC are set, put together a clear execution plan and identify the resource capacity required to perform the POC. Make cost estimates for the support resources from within your enterprise and across vendors and submit them for approval. Once the cost is approved, carry out all the planned POC tests. It won't be a straightforward outcome. You should expect challenges as it's the first time your application(s) will be deployed on the Cloud infrastructure.
3. Evaluate and Compile Benefits
Once the execution of POC tests is complete, compile all results into categories of your previously set objectives. For instance, assemble all the performance results and the actual cost to run the POC tests. Prepare a deck or a document comparing the performance and functional results with an on-prem setup. Include the cost estimates for both on-prem and Cloud infrastructure and the environment capacity.
4. Discuss the POC Results
Engage all stakeholders and discuss the POC results on various parameters. Ensure to include networking, infrastructure, platform, server engineering, business stakeholders, application teams, etc. Stay prepared to resolve multiple queries and know all the details of the POC to be shared with various teams.
Once the POC is successfully executed and the results are socialized with all stakeholders, it's time to start assessing the full migration of your application(s). This part will be simpler than POC as most of the pathway has been laid out in the process.
1. Evaluate POC Results
The POC results could lead to one of these decisions –
a) Migrate all the environments of the application(s) to the Cloud
b) Migrate some of the environments to the Cloud and leave some on-prem
c) Do not migrate to the Cloud; on-prem might still be the best solution
Once a path is chosen and approved, start a detailed assessment. For now, we will go with option (a) where the results clearly favor migrating all environments to the Cloud.
2. Assessment for Full Implementation
Carry out a capacity assessment for each environment to be migrated and all the associated components, including Load Balancer, DNS, LDAP, etc. Once all the components and capacities are assessed, carry out a cost assessment for the Cloud services and the human effort required for the full migration.
3. Hardening Architecture
Revisit the POC's reference architecture and Data Flow diagram and make adjustments as needed. Review the full view of the architecture and design with technical stakeholders from all teams, including networking, server engineering, infrastructure, platform, application teams, etc.
Once the full migration assessment is in place, and the budget is approved, it's time to kick off the planning and execution phase.
1. Implementation Planning
Put together a detailed implementation plan for migrating all the environments to the Cloud from on-prem. It's important to ensure the functional changes and releases planned for the application(s) have minimal impact due to this migration.
2. Implementation Execution
Do not migrate all environments at once, as it poses a risk to the project. It is ideal to start from a lower development environment and move to the QA environment once it's migrated, etc. Once each environment is migrated, ensure all the upstream and downstream applications and the users validate and sign off.
For the final production environment, devise a detailed plan and derive the downtime required to switch. To minimize downtime, build the production environment on the Cloud first and ensure everything is working as expected, including connections, access, etc. It's important to have a thorough backout plan if a rollback is required due to unforeseen situations.
Carry out parallel executions, and keep the data in sync with on-prem production and Cloud by running all the processes and the latest data on the Cloud. Compare results to make sure both are similar. Once the results of the parallel tests are satisfactory, execute cutover, switch completely to a Cloud-based production environment, and shut down on-prem production.
3. Evaluate Benefits and Socialize
Once the cutover to Cloud Migration is complete, keep monitoring for a few weeks and collect all metrics required to support the objectives. For instance, collect all performance metrics of the application(s) for batch, real-time and near-real-time transactions and put together a comparison slide/deck. Similarly, collect the monthly cost associated with the Cloud infrastructure and put together a slide/deck comparing it with on-prem cost. Even though these parameters won't be an apple-to-apple comparison, but it will still give an idea about the benefits of the Cloud apart from the flexibility and maintainability aspects.
Carrying out Cloud Migration is no small feat. Such projects have to go through a lot of pushback in some organizations and not so much in others. Regardless of the acceptance levels of the Cloud, the approach remains the same – sow the idea, educate stakeholders about the benefits, socialize and onboard all teams, work with product and Cloud partners, plan small with a POC and then go for a full migration.