So, you’ve decided to move to the cloud. Here’s the first question you’d want to ask: How can I plan a seamless cloud migration?
The good news is that there are many different ways do to it. However, all methods share some common, mandatory, migration steps, which help streamline the entire process.
Thorough assessment and careful planning are crucial to your success. Try not to miss anything and predict what may go wrong. Hope for the best, expect the worst, and be prepared for it. If you carefully design every aspect of your migration, you can be 100% sure of success.
To help you with the planning, we’ve condensed all of the cloud migration planning wisdom into 25 simple steps of a seamless cloud migration. This is an ultimate cheat sheet that points out all the necessary migration details and essential steps. This list will help you create a foolproof plan for a successful and efficient cloud migration. Let’s get started!
1. Cloud readiness
Before you even start planning cloud migration, you need to assess if your organization is ready for the cloud and if migration will be possible.
Not every application is cloud-ready and not every environment can be migrated. It’s not just about hardware and software compatibility. Before you plan anything, think about any the constraints that may slow down or hinder the migration. Talk to business, talk to finances, and lawyers. There may exist some legal constraints that will make the migration (or its parts) impossible. Find out what regulations you must follow to migrate without creating any legal issues.
Finally, evaluate if the migration will be beneficial for your organization.
2. Success criteria
Define criteria for success. Without them, you will never know if the migration went well.
Each organization may have different benchmarks. For some companies, a successful migration will increase cost savings. For others, it will be simplifying processes and procedures that yield time savings.
Talk to the stakeholders to develop an exact definition of ‘success’ that will apply in your case.
3. Demands and limitations
Determine your application’s demands and compare them against what different cloud providers can offer. This exercise will help you to rebuff options that do not meet your requirements.
Some applications may have particular requirements that won’t be matched by all cloud providers. For example, if an application requires GPU, you need to find a provider that is able to provide GPU for instances. You won’t be able to use your application with a provider who doesn’t offer that option.
Note, however, that every cloud has some default limits for multiple services. In AWS for example, there is a default limit of 20 on-demand instances across an instance family per region. For more powerful instances the limits can be stricter. E.g., if you want to deploy a P2 instance, by default, there can be only one for each P2 family. More instances can be requested, but defaults are as they are. You need to estimate how many instances you need and request an upgrade in advance. Remember that some limits may be given per region and others – per account.
Keep the above limitations in mind when you’re investigating the available providers. Make sure that the provider you choose can support the upper bound of your compute, network, and storage throughput.
4. Cost assessment
Do you know the actual costs of running your applications? What is the cost of hardware, software, licenses? What is the upkeep of people, power, and infrastructure? You need to know these values to compare them with the cloud. Find out what they are. Estimate the same for the cloud. Calculate the cloud costs for different options.
IMPORTANT: Keep in mind that it’s not just the Virtual Machine cost we’re talking about! Charges in the cloud are based on storage, geography, data transfer, API calls, etc. Prices may vary in different regions.
Calculate the costs for different environments – prod, pre-prod, test, dev, but don’t think only in terms of money spending! Remember how long it takes to create a test environment for any application?
In the cloud, you can have it within an hour, not weeks. You can also cancel your tests without bearing any costs. Just power off instances, and that’s it – you stop the environment, and you immediately stop paying for it!
When comparing the costs, don’t just collate the overall cost for the project, but the cost per user. Even if the total cost of the cloud may seem higher, the cost per user may turn out to be much lower than your current spending.
5. Existing gaps
While estimating the costs, you may identify some gaps in your organization. These can be the lack of knowledge about costs and KPIs per application or about upkeep for the hardware. There may be other gaps as well. You need to find out what they are and if they will continue to exist after the migration.
Maybe you’re suffering from the lack of automation? Maybe the procedures are so complicated that they slow down the process of creation of new environments?
Moving to the cloud may close some of these gaps, but it may also expose some new ones, like the need for additional training for developers or sysops.
6. Choose the right candidate
You cannot migrate everything at once. Even if you could, it’s always a terrible idea. That is why you should migrate one by one, in the right order.
For the first migration, you have to choose the right candidate for pilot testing.
There are many candidates to consider – applications, workloads, or environment. You can start with Dev & Test, web applications, backups, archival, e-commerce, disaster recovery, production, big data, business intelligence, continuous development… The choice is yours.
The rule of the thumb is to choose an application that is:
- the easiest to migrate,
- the most likely to fulfill the criteria of success,
- and the least prone to failure.
7. Candidate assessment
Once you’ve selected the right candidate, gather all information about its topology, connectivity, usage of resources, and system specific requirements. Get the current design and prepare the new one to be implemented in the cloud. Check the present and historical performance graphs to make sure you provide enough CPU, memory, and IOPS.
- Topology: Decide if you want to keep the current topology or if you need to redesign it. Prepare data flow graphs between your candidate application and cooperating systems. Are they internal or external?
- Segmentation: How do you segment the application? Do you need to use any third-party network virtual devices in your environment?
- Bottlenecks: Consider possible performance bottlenecks. Do you know how to avoid them? If any part of your application is to be kept on premise, this may cause additional latency in communication. Plan how to optimize the environment after the migration.
8. Migration path
If your candidate assessment was positive, it’s time to take the final decision on the migration path you wish to follow:
- Manual or automated lift-and-shift migration
- Lift and reshape the underlying architecture
- Repurchase software and licenses and install them manually
- Redesign the application, architecture, processes
Quite often, the easiest way is to lift and shift, but it’s not always the best and the cheapest option.
Sometimes, as a long-term strategy, the most beneficial solution is to redesign everything and build it from scratch in the cloud. This may take longer, but it can open your application to other cloud native services.
9. Choose the right provider
Go back to your provider shortlist and choose the provider that best meets your application demands and requirements.
Think about the future. Consider other applications that you may want to migrate next, and examine their demands. For example, if you know you will need GPU instances, don’t go for providers who cannot deliver on that. You may consider a dual or multi-vendor environment, but it will be harder to implement and to manage.
10. Hybrid model
You probably do not want to isolate your new cloud environment from your current one. This means that until you migrate everything to the cloud, you will maintain a hybrid model (it can be a temporary state).
There are a few ways to connect the actual on premise environment to the cloud:
- Internet connectivity – using the cloud vendor public IPs
- Point-to-site connectivity – with the secure remote client VPN
- Point-to-point VPN connectivity – with the IPsec tunnel between the cloud and your site; it can be done with a native cloud gateway or with a third-party VPN gateway
- Direct connectivity – a private connection directly to the cloud
Would you like to integrate identity management and directory services and move authentication & authorization to the cloud?
At this point, you should also decide to which services you’d like to connect through VPN, and which will be accessed via the Internet.
You will never succeed without highly-qualified staff. Carefully choose the members of your migration team. They will define new standards and guide your organization through the transition. They’ll have to become familiar with new cloud services. Provide them with any materials and training sessions needed.
You will not only need technical staff like developers or system administrators but also project managers or architects. Each role will require a different approach and tailored training.
After your team gain experience during the first migration, they will become invaluable in the future.
You will have to adapt the existing processes to the cloud, as well as define many new ones.
Your change management, incident management, testing, self-service and other processes will have to change to address the cloud. You will need to develop a process for requesting new resources.
If you don’t have such processes yet, it’s high time to define them at this point.
13. Finances (costs and processing)
Plan how to manage and process future costs. Define a financial processing tree.
- Decide who is going to pay for what.
- Decide if you will manage the costs per project, subscription, team, business unit, etc.
- Define the cost limits.
- How do you want to measure the usage?
- What to do when the costs exceed the limits?
- What limits do you want to set? For whom? Users, teams, departments?
- Do you have procedures on how to process invoices and make payments?
At this point, you need to define all the processes and procedures for the cost management.
Decide how to deploy updated code, data, and configurations to the cloud environment. How to make an initial deployment? Do you want to create your own pre-configured images or configure new images in the cloud? Do you want to convert existing machines to the cloud? Choose the right tools.
Migration is only the beginning. You need to plan how to operate your new cloud environment after the migration. Plan how to monitor and troubleshoot it. Decide how you will perform changes and updates.
Prepare procedures on how to deploy changes to your application.
- Do you need to plan a regular service window?
- What will be the application lifecycle?
- How to upgrade the application?
- How to scale it when needed?
- Do you want to automate the scaling?
Prepare test environments for your critical applications.
Develop a security and compliance plan. Remember about shared responsibility. You are the owner of the data, and you are responsible for their security. Here are the key points to remember about:
- Make sure you follow all the regulations you are required to obey.
- Decide if you want to encrypt data.
- Choose a region where your data will be stored and determine if the data is allowed to be moved to other regions.
- Set granular permissions to specified resources with the role-based access control.
- Provide logging and create procedures on how to manage and view logs.
- Choose management tools.
- Define how to monitor and respond to incidents.
- Decide if you need any third-party security virtual devices to strengthen the security.
- Define the auditing process.
Prepare a cutover strategy and a detailed cutover plan that will answer these fundamental questions:
- Does the cutover need a downtime?
- Should you notify business units and users?
- Do you need any special approval for any part of the process? If so, get all the approvals needed a few weeks before the planned cutover.
- Do you need to synchronize the data before the cutover?
- Do you want to split the migration into smaller parts or migrate everything at once?
Prepare a rollback plan and define the criteria when to roll back. Have a written plan for everything.
Run a pilot trial as a proof of concept. The PoC should take into account all of the concerns mentioned above:
- Set up applications in the cloud.
- Do not prototype on paper.
- Do trial runs.
- Get familiar with the cloud.
- Test the interface, find out the capabilities.
- Find out how to raise a support ticket.
- Test performance with performing benchmarks.
- Set expectations, and find bottlenecks and other possible performance issues.
- Test legacy software in the cloud.
This is the time to spot & report on anything that can fail during a real migration. Take notes and collect data. It will become your lessons learned in the future.
Plan how to send the application to the cloud together with its data. Can you perform an upload? How long will it take?
It may be a challenge to send terabytes of data to the cloud. Consider compressing the data before sending, or using services like Import/Export to physically ship drives to the cloud provider.
Make sure your data is secure during the transit. Define security standards you need to follow at transit. Encrypt data before sending. Find out if there are any official regulations you need to follow for this part.
21. Migrate Virtual Machines
Plan how to move VMs. Lift-and-shift can be very complex as you need to plan storage, networking, and security accordingly. It may be difficult to reflect your actual environment in the cloud, but you may have no option to refactor the application and make it cloud native.
Decide if you want to clone OS, replicate your machine using dedicated tools, convert it or maybe create from scratch.
22. Migrate application
Plan how to migrate your application. You can deploy it directly to the cloud or move with VMs.
Decide what model you’ll use. You can choose between IaaS and PaaS. IaaS has fewer limitations while PaaS has more automation and integration options.
23. Migrate data
Plan how to migrate data. Use these questions to guide you through the process:
- What is the destination resource? It can be a database or object storage.
- If you are migrating a database, will you convert between different database engines?
- Do you need to convert data between types?
- What tools can you use to support migration?
- How big is your data? Is it possible to transfer it over the Internet or a dedicated link?
Same as with distributing applications, you may consider shipping the physical drives to the cloud.
- Make a validation plan to make sure that all migrated resources are reachable.
- Prepare a detailed checklist and assign people who are able to perform a test. Make them responsible for confirming that the application works as desired. Follow that checklist and do not miss any point.
- Prepare a procedure that will specify what to do if any functionalities are down.
- Perform tests from the user’s perspective, as well as from the surrounding services’ and applications’ perspectives.
- Choose a staff member responsible for determining that tests have been completed and successful.
25. Availability (data and management)
Plan how you can check the availability.
- How can you confirm data integrity? Compare the migrated data with the reference sets of data.
- Automate your tests.
- Plan how to confirm that management and monitoring systems are able to reach cloud resources.
- Prepare checklists for everything and choose people responsible for completing them.