9 steps to build a successful cloud migration plan 

Cloud migrations aligned to key business outcomes are more likely to see success than siloed projects driven solely by the IT department. 

Outline why you are migrating and modernising. Define the business outcomes that you want to achieve and your motivations. Are you looking to exit your Data Center? Increase cost savings? Gain new features? Improve performance and end-user experience? Leverage real-time data and analytics? Achieve greater scalability with IT resources on-demand?

The priority of your objectives will shape multiple choices in the later stages of the cloud migration process as you decide on the kind of cloud platforms, deployment models, applications, and resources you’ll need to navigate a successful shift. 

You have to know where your starting point is in order to get to where you want to go. So it’s important to inventory and assess your existing on-prem infrastructure.

An assessment will dive into not just what technology your business uses but also give you insights into how your organisation uses it. This will help both IT and non-technical teams to develop a clear picture of current business operations and provide insights into how you can transition to new systems and processes seamlessly.

As you evaluate your existing system landscape, keep these questions in mind:

• Which applications are you currently using?
• What hardware and infrastructure (servers, databases, and storage) are you relying on?
• What are the technologies being used in your application portfolio?
• Which elements stand to benefit from cloud migration, and which either are not deemed feasible to migrate or likely to perform better on an on-premise infrastructure?
• What is your current level of investment in on-premise servers (licensing, hardware resource consumption, and support infrastructure costs)?
• Do you have data that needs to be resynced regularly, or specific data compliance requirements to meet?

Set baseline metrics for your IT infrastructure to map workloads to your assets and applications. Baselining essentially refers to measurement of current (pre-migration) performance of your IT infrastructure in order to validate post-migration performance improvements you expected.

Having a baseline understanding of where you currently stand is critical to understand key pain points in your legacy infrastructure. Once you have an understanding of the specific aspects where you’re underperforming, your migration teams can focus on them for future attention. 

You need to identify some of your most significant KPIs, such as page load times, response times, availability, CPU usage, memory usage, and conversion rates, and set a baseline performance range for each. This will show how your in-progress migration is doing, and most importantly, help you understand and determine when the migration is complete and successful.

A comprehensive analysis of your existing architecture and applications will reveal answers to these key questions:

Can an application function optimally in the cloud?

Not every application is cloud friendly. In some cases, it doesn’t make sense to move older applications built on legacy OSes to the cloud.

In contrast, it’s easy to assume that compatibility and performance won't be an issue for newer applications that run on top of modern OSes since most cloud platforms allow you to allocate resources based on an as-required model.

Is any refactoring required before you migrate an application?

You may need to perform refactoring to optimise your applications for the cloud environment. Such refactoring will ensure they can make the most of dynamic cloud capabilities, potentially offering the flexibility for better resource utilisation and saving money on cloud service costs.

What is the cost involved?

While cloud migrations often do end up minimising costs, the financial benefits ultimately depend on the specific migration being executed.

For instance, legacy applications might become more expensive to run in the cloud because they are made up of chatty components. This means during a typical function, they end up calling other services to fulfil requests. Such an architecture can therefore get quite costly to run in cloud environments.

Are there any security considerations that need to be addressed?

Mission-critical and sensitive workloads like financial data may not be ideal for public cloud environments. 

Private or hybrid cloud (combination of private and public cloud infrastructures that lets workloads move between the two interconnected environments) is a better place for sensitive data as they can offer the scalability of the cloud, without the risk of compromising mission-critical information.

You need to choose the most suitable cloud service provider (like AWS or Microsoft Azure ) for your organisation. Your choice will largely depend on your objectives, the architecture of the applications that must be migrated to the cloud, integrations, and other factors.

Adaptavist is an AWS Advanced Consulting Partner, which means if you choose AWS, we’re perfectly positioned to deploy, run, and manage every aspect of your cloud experience. We can also support other cloud hosting options to help you meet your specific goals. Cloud migration is complex, but we can confidently help you move your applications and data to AWS.

You’ll also need to pick the right deployment model for your workloads and decide whether public, private, hybrid, or multi-cloud environments best suit your specific requirements.

Public cloud offers a scalable environment on a pay-per-usage basis and can be tremendously beneficial for applications that experience unpredictable demands.

However, as discussed earlier, public cloud may not be ideal for mission-critical workloads. In such cases, private data centres or hybrid cloud environments are better options since they offer additional security and control.

On the other hand, multi-cloud environments make sense when you want to avoid vendor lock-in and ensure the flexibility to pick and choose from multiple cloud platforms. But, optimising your application to work with various cloud providers is relatively complex and calls for a wide range of skill sets.

Want to find out more about cloud migration with Adaptavist and AWS?

Discover our AWS services

When you move an application from an on-premises data center to the cloud, there are two typical migration models: lift and shift (rehost) and rearchitect (refactor). 

Rehosting is basically moving an application to the cloud “as is” with no—or limited—changes. Any modification is just enough to get it to run in the cloud environment. 

Whereas refactoring involves making changes to the application architecture to take advantage of cloud capabilities. This might be limited to using auto-scaling and dynamic load balancing, or it might be as advanced as using serverless computing capabilities such as AWS Lambda for parts of the application.

Refactoring can require a lot of time and a wide range of skill sets from staff, so advanced planning is crucial. This process can also rack up upfront costs, especially for highly customised or legacy applications, but helps slash ongoing costs.

Data integrity is critical in any type of legacy migration process. If your data becomes inaccessible to users during a migration, you risk disrupting your normal operations. A robust data migration plan will play an important role in ensuring proper data governance and quality through continuous tracking and monitoring. 

Extreme care must be taken to ensure any data blocks are not missed or deleted. We recommend backing up your data before embarking on a data migration and thorough testing at each step to identify unexpected issues and address concerns. You’ll also need to be careful as you sync and update your systems after the initial migration is carried out. 

The other issue would be damage caused as a result of changes in data security levels. This can lead to access of sensitive data by unauthorised persons. 

Databases are typically encrypted, so you need to pay careful attention to encryption and decryption aspects. The migration of encrypted databases, if not properly handled, would result in data loss. And this might also introduce security vulnerabilities in the system.

As a best practice, we also advise implementing automated test framework that has a full stack security testing measures to check and fix vulnerabilities on a timely basis.

Once you have a clear sense of what is moving, where it’s going, and how it will work when it gets there, your migration activities are ready to begin. It goes without saying that the more complicated your architecture, the more careful you need to be.

The best practice is to start the process by migrating the least complex applications first, leaving any mission-critical applications for later in the cycle to help minimise downtime. However, some organisations opt for a parallel operation model (using both cloud-based and on-premise applications) first before fully transferring to the ported applications.