Introduction
Organisations undergoing digital transformation are looking for avenues to modernize, innovate, and adapt their application landscapes to the latest technology available on the big public cloud platforms, such as AWS, Azure, and Google Cloud Platform.
Some of the business drivers for moving applications to the cloud are:
- Shifting focus from underlying infrastructure and platforms to application innovation
- Need for hybrid architecture to leverage services that are not available on-premises
- Unmatched availability, scalability, and agility of cloud resources when compared to on-premises deployments
- Alternative solutions to replace end-of-life hardware/software
- On-demand usage pattern and pay-as-you-go cost management offered by cloud
- Effective compliance and security management
To achieve minimal downtime, you need to take a phased approach to cloud migration, in which system by system or application by application will be migrated, rather than an entire data centre at one time.
The amount of effort to be put into a cloud migration depends on the complexity of your IT infrastructure.
Organizations with hundreds if not thousands of applications, databases, and systems need to prepare for a long-term cloud migration effort. In preparation for cloud migration with minimal downtime, there are multiple considerations to take into account
Application discovery and assessment
Find out exactly what is in your applications inventory, and map any dependencies. It will help you identify what you need to migrate, and in what order.
The process of application discovery allows you to get a deep understanding of the current environment and application landscape of the workloads that you are looking to migrate to the cloud.
In this phase of cloud migration, the following steps need to be performed:
- Build a comprehensive inventory of your applications, so that you know what you are dealing with
- Catalogue your applications according to their properties and dependencies, so you know how all your applications are intrinsically linked to each other
- Train and educate your teams, so that they can operate in cloud environments and can adapt to new ways of working
- Build and experiment with a proof of concept in your target cloud vendor(s), so that you are confident with the new environment before you start your migrations
- Calculate the total cost of ownership (TCO) of the target environment, so that you can be clear what the cost implications of moving to the cloud are
- Prioritise the workloads that you want to migrate first so that you can manage your migration successfully
If your current environment is highly dynamic, you should spend effort in automating the inventory creation and maintenance, so you eventually have a consistent view of all the items in your environment at any given time.
Migration Architect role to lead the effort
During a large migration project, many decisions must be made, and technical plans created.
To ensure a successful migration it is important that the following are performed:
- Plan all aspects of migration, so that you can complete the migration according to your predefined plan, within agreed timescales and budget
- Define refactoring required to make migration successful, ensuring that you understand the implications of the different refactoring options
- Design strategies for data migration, and ensure that you stick to them when you migrate
- Define cloud-solution requirements, and have a central repository to capture all of the information you capture
- Determine migration priorities, so that you know which applications to migrate first and which ones should wait until your environment is a bit more mature
- Clarify production switchover mechanisms, so that you understand how you are going to cut over from on-premise infrastructure to cloud-hosted infrastructure
You should consider hiring a migration architect to manage planning, design and execute your migration. That way your operational teams can concentrate on understanding the new environment without having to worry about how the migrations are going to be managed.
Choose a type or combination of Migration Strategies
You will need to choose the best migration strategy, or a combination of strategies, for your workloads
There are various options to consider when migrating workloads to the cloud, and it is important to understand these so that you can decide what is the most suitable option for each workload:
Lift and shift :
One of the easiest and least expensive ways to migrate an existing workload to the cloud is to take the workload as-is and run it on cloud-native resources. Although this is the simplest option, it does not make full use of the native cloud functionality and will be less flexible and more expensive in the long term.
Refactor and rebuild:
In this case, you modify your application during the migration process to take advantage of key cloud capabilities like auto-scaling and dynamic load balancing
Re-Architect and rebuild:
You may choose to re-architect to take advantage of microservices and serverless architecture. Re-architecting can be painful, time-consuming and expensive, but the benefits in terms of cost and scalability, in the long run, cannot be underestimated.
Choose single or multiple cloud strategy
You need to decide to use a single cloud provider or multi-cloud solution.
When cloud first came on the scene, it seemed like using a single cloud provider would meet all of your needs. However, as more and more applications are moved to the cloud, organisations have realised there is often a need to use more than one cloud vendor.
Multi-cloud scenarios arose for many different reasons. For example:
- IT organisations that want to ensure better disaster recovery and avoid vendor lock-in.
- Different departments procuring cloud service independently or each other
- Some organisations pursued a multi-cloud strategy for better cost optimisation
- A merger or acquisition can lead to a single company using multiple clouds
- Once you’ve updated your application to work with only one provider, moving your application to a different provider could require just as much effort as the original cloud migration.
- Having a single provider may negatively impact your ability to re-negotiate.
When planning where to host your applications in the cloud, you may want to consider any of these models:
- One application in one cloud vendor, and another in another cloud vendor
- You can split your application across multiple cloud vendors
- You can build your application to be cloud-agnostic
- You can replicate your application to another cloud vendor to switch over in the event of a disaster
Different organisations have adopted a multi-cloud strategy for different reasons. This means that the term multi-cloud means different things to different companies
Prioritise migration components
Are you migrating entire applications at once or migrating component by component or service by service?
However you are performing your migration, you need to create a plan detailing how best to migrate each application, and this plan must take into consideration any dependencies the application may have.
You will need to assess your application inventory and categorise each application. Applications can be placed under one of the following categories
- Modern applications like micro-services, mobile and cloud-native
- Legacy applications like client-server, mainframe, UNIX-C
- Other applications like Java, java enterprise, .Net, and web applications
The first category is either already cloud-hosted applications or those that can easily be migrated.
Applications in the second category may never go to a cloud because migration is too risky. This category is not where to start, and these applications will need to be completely re-architected and rebuilt before they can be migrated.
The real opportunity lies within the third category. Moving these applications to the right public or private cloud can result in serious savings and will allow you to take full advantage of the benefits of the cloud.
The main goal of this exercise is to migrate applications that are easy to move quickly to cover costs and realise savings.
Refactor applications to take advantage of cloud
It may be cheaper upfront to simply rehost your application and its data as is on the public cloud, but this approach could ultimately cost more than it would to run a cloud-native app instead
A simple lift and shift migration may also introduce performance issues caused by changes in the software architecture, missed software bugs and an inability to properly utilise the cloud vendors native services for monitoring, security and governance.
It is much better to refactor your applications as part of the migration. A migrated application may also benefit from refactoring when costs are unexpectedly high due to application or database inefficiencies or when security vulnerabilities arise because the application cannot be integrated with native security systems
The most important element that you need to consider when refactoring an application is cost. It can be a very expensive process, but the cost, security and performance benefits in the long term cannot be underestimated
Create a data-migration plan
Migrating data is one of the most sensitive parts of cloud migration. The location of your data can significantly impact the performance of your application.
Moving your data to the cloud when the data access methods are still primarily on-premises can significantly impact performance. The same holds true if the data is still on-premise but the service accessing it resides in the cloud.
Various options can be considered when migrating your data to the cloud, including:
- Use a bi-directional syncing mechanism between your on-premise and cloud databases. Once you have moved all consumers of the data to the cloud, you can then remove the on-premise database
- Use an on-premise database with one-way synchronization to a cloud-based database, and allow consumers to connect only to the on-premise version. When you’re ready, disable access to the on-premise version so the cloud-based version becomes the main database, and enable cloud-based consumers to access the new database
- Use a cloud data migration service, such as those available from AWS or Azure
Conclusion
A common misconception about cloud migration is that it will be a one time trip. But the reality is that the process of migrating data infrastructure to the cloud should happen gradually.
A successful migration should feel as seamless as possible to the organization, so day to day activities are not disrupted.
There are some other things you should consider during your cloud migration:
- How to switch over from to production. Are you going to do it once or a little bit at a time?
- How will you establish performance baselines, to determine if its future (post-migration) performance is acceptable?
- How will you measure the performance of your applications and services against your expectations?
- How will you create a safe and secure cloud environment that is compliant?
It is recommended that you establish a Cloud Migration Factory, which will help you to move workloads from an on-premises environment or hosting facility to the public cloud. It aligns your cloud migration project to your business strategy and combines the people, processes and tools to enable you to plan, execute and support your cloud migrations.
