A cloud migration checklist: The lowdown on integration and architecture

Kevin Downs is a solutions strategy director at New Relic. Kevin has deep knowledge of IT Operations, the cloud industry, and works with customers and partners to assist in their cloud adoption journeys. He’s been in the enterprise software industry for over 20 years and has spent 12 years as a customer-facing solutions architect, selling enterprise software solutions to all verticals. He’s worked on public cloud solutions since 2009 and has passed five cloud certifications

IT executives often face struggles or experience limited success in their cloud migration, but this is no reason to give up. They use the lessons learned to improve results in subsequent attempts. So here is a checklist of the major areas organisations looking to modernise mission-critical applications should consider to avoid repeating mistakes.

Designating a migration architect

Every cloud migration project should establish a migration-architect role, right from the start, to lead the effort. This would be a system architect-level position and the individual is responsible for planning and completing all aspects of cloud adoption. The role is responsible for defining the necessary refactoring required for a successful migration, designing strategies for data migration, outlining cloud-solution requirements, and determining priorities, as well as production switchover mechanisms.

With so many cogs spinning in a wheel during the large migration project, there are many critical decisions and technical plans that must be made. The migration architect oversees everything and will be responsible for all aspects of the migration – this is essential to the success of the project.

Cloud integration

There are two ways that organisations can move an application from an on-premises data center to the cloud – either via shallow cloud integration or deep cloud integration.

Shallow cloud integration is also known as “lift-and-shift”, whereby IT teams move the on-premises application to the cloud and make no — or limited — changes to the servers instantiated in the cloud for the purpose of running the application. This is quick and easy as minor application changes are just enough to get it to run in the new environment, cloud-unique services are not needed. This approach is sometimes called lift and shift because the application is lifted “as is” and then moved, or shifted, to the cloud intact.

Whereas, deep cloud integration requires modifying applications to leverage key cloud capabilities such as auto-scaling and dynamic load balancing, or serverless computing abilities including AWS Lambda for portions of the application. This model might also involve using a cloud-specific data store like Amazon S3 or DynamoDB.

Single cloud vs. multi-cloud

At the start of the cloud migration journey, IT leaders need to decide whether the organisation is to use a single cloud provider – migrating an application so it runs optimised for that single environment – or multiple cloud providers?

Ensuring application optimisation works with a specific cloud provider is relatively straightforward. Developers have a single set of cloud APIs to learn and the application can benefit from everything the chosen cloud provider offers.

However, users will experience vendor lock-in. This means that once developer teams have updated the application to work with only that one provider, future plans to switch providers could require just as much effort as the original cloud migration. Another aspect to consider is that having a single cloud provider restricts the organisation’s ability to negotiate important terms, such as pricing and SLAs with the cloud provider.

Additionally, there are also several different models for using multiple cloud providers:

  • One application per cloud – The simplest multi-cloud approach is to run one set of applications in one cloud provider and another set in a different cloud. This allows organisations to increase business leverage with multiple providers, as well as flexibility for future application allocation. Plus, developers can optimise each application for the provider on which it runs
  • Application across multiple cloud providers – It is possible to split parts of an application between one cloud provider and other parts in another. In this way, IT teams can maximise on key advantages each provider offers. For instance, one provider might have enhanced AI capabilities and another might be better for its database speed. The risk here is that an application is tied to the performance of both providers, and any problem with either provider could impact the application’s customer experience
  • Cloud-agnostic application – Some companies build their applications to run on any cloud provider, so an application can operate simultaneously on multiple providers or it can be split across them. This approach offers exceptional flexibility in vendor negotiations as it makes shifting loads from one cloud provider to another much simpler. However, developer teams may encounter difficulties using the key capabilities of each cloud provider, therefore minimising the benefits of hosting an application in the cloud

This checklist is not definitive as there is no “right way” to achieving success in a cloud migration, there are of course other methods IT leaders can consider. No matter which approach to cloud migration an organisation chooses, it is critical to always nurture a safe and secure cloud environment.

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.

Similar Posts