Key steps in preparing for cloud migration

Cloud computing is no longer a new, novel form of technology, but a mainstay of the tech world. (A 2018 study by Cisco predicted that global cloud data center traffic would reach 19.5 zettabytes by 2021. I’ll save you a google search: A zettabyte is one trillion gigabytes. Needless to say, that’s a whole lot of data.)

Here’s the point: The cloud isn’t some up-and-coming technology. It’s the future of data storage and processing, and it’s happening right now. Companies around the world are migrating—or have already migrated—to the cloud. And you should too. 

That being said, you can’t decide to migrate to the cloud one day and be done by the end of the week. Cloud migration is a long, involved process. To ensure everything goes right, you need a plan—you need a cloud migration strategy. That’s where this post comes in. We’ve created a cloud migration checklist to help prepare you for a smooth, successful cloud migration.

How to prepare for a cloud migration

When it comes to cloud migration, preparation is everything. You’ll be moving a lot of data, which introduces a number of business risks—risks that can be easily avoided with proper planning. 

So what does proper cloud migration planning look like? Your cloud migration checklist should touch on a little bit of everything—coding, management structures, and more. 

To get you started, we’ve assembled some crucial pre-migration steps. (Our list is not meant to be exhaustive. Each cloud migration is different, and you may need to add additional steps to your checklist!) 

Establish individual and team responsibilities

Before starting any process, you need to organize the people involved—and cloud migration is no different. The first step on your cloud migration checklist should be establishing and assigning roles and responsibilities. In other words, you should start by organizing a cloud migration team. 

At the head of this team, you’ll need a migration architect. A migration architect plans and strategizes the cloud migration, makes high-level decisions, and determines how and what to refactor for the cloud. The actual refactoring, however, is typically carried out by other system engineers. 

In addition to a cloud architect, you will also want additional specialists on hand to help navigate security, compliance, and other aspects of cloud migration. 

Choose your level of cloud integration

There are two levels of cloud integration: shallow and deep. If you’re familiar with the 6 R’s of cloud migration, you might know them under different names—rehosting (or the lift and shift) and replatforming (or the lift, tinker, and shift), respectively. 

Each level has its own benefits and drawbacks and it’s up to the migration architect to decide which approach to take. It’s a big decision that will significantly impact the timeline of your migration, so let’s take a closer look at each level:

Shallow cloud integration:

Shallow cloud integration refers to moving an on-site application to the cloud with as few changes as possible. Think of it as the quick-and-dirty approach to cloud migration—your goal is to get the application working in the cloud, but that’s about it. 

The main benefit to this approach is that it is fast and cheap. Here’s the catch: Your application will not be optimized for cloud-based operation. With this approach you’ll miss out on cloud-native functions such as auto-scalability and distributed workloads.

Deep cloud integration: 

Deep cloud integration actually includes two of the 6 R’s of cloud migration—replatforming and re-architecting. Both involve rewriting parts (or all) of an application to make it not only cloud-compatible, but cloud-optimized. 

The pros and cons of deep cloud integration are basically the inverse of shallow cloud integration: It’s a longer, more expensive process, but the end product is an application that is equipped to take full advantage of cloud capabilities. 

Choose a single cloud or multi cloud approach

When you migrate to the cloud, you’ll have to choose a cloud provider—or providers. In doing so, you’ll need to choose whether to take a single cloud or multi cloud approach. 

A single cloud approach is pretty straightforward: You select a cloud provider (AWS, for example) and optimize your application to run in that cloud environment. You and your team will only have to learn one application programming interface (API)—as opposed to two or three. 

The downside is vendor lock in. Because you’ve committed to a single cloud provider—and put in work to optimize your app for that provider—you don’t have the option to shop around. You’re basically stuck with whatever prices or limitations that provider throws at you. 

When it comes to multi cloud approaches, there are a few routes you can take. The simplest is using one cloud provider for this application, a different cloud provider for that one. You are running on multiple clouds, sure, but each application is running on a single cloud provider. In this case, it’s fairly simple to optimize each application for its respective cloud environment. 

You also have the option of running a single app across multiple cloud providers. This is where things can get complicated. Say one cloud provider has really great database speeds. You could choose them for your databases, but run other parts of your app through another provider. This approach allows you to get the best features from each provider, but is definitely not for the faint of heart.

As you migrate your apps to the cloud, you also have the option of making them cloud agnostic. Cloud agnostic apps can run in any cloud environment, whether it’s AWS or Microsoft Azure or IBM Cloud. Basically, they’re designed to avoid vendor lock in. 

If you don’t like the provider you’re using, no problem: Just switch over to a new one. By making an application cloud agnostic, you also have to make it somewhat generic. It won’t be optimized to make full use of any specific cloud provider’s features. 

Establish cloud KPIs

Key performance indicators, or KPIs, are crucially for measuring the success of any project—and cloud migration is no different. Before starting your migration, you’ll want to establish your metrics for success. 

How will you know if your cloud migration strategy is successful? Your KPIs should apply to both the migration process (how well is the transition going?) and the state of your application post-migration (now that the migration is complete, how are things working?). 

The migration architect is typically responsible for setting and monitoring KPIs, as well as keeping team members in the loop. This might sound like a lot of work, but it doesn’t have to be! 

By documenting and organizing KPIs on a Lucidspark board, you can record and share any updates with key stakeholders throughout the migration process. Rather than relying on the migration architect for updates, team members can check the group board—accessible from anywhere—to see the team’s progress towards meeting each KPI.

Organize migration components

The task of migrating an on-site application—especially a large, complex one—to the cloud is a daunting task. Here’s the good news: Migration doesn’t have to happen all at once. If needed, you can migrate an application piece by piece, one component or service at a time. 

If you decide to take this approach, you’ll need to organize and prioritize each element of your application. Some application components have dependencies on others—your cloud migration project plan will need to take these dependencies into account. As you begin migration, consider prioritizing elements with the fewest dependencies—they’ll be the most straightforward to relocate to the cloud.

Refactor as needed

Refactoring refers to the process of adapting on-site applications for cloud environments. It’s a big job, so don’t worry if this step takes longer than previous steps. Take your time—it’s worth it to be thorough here.

As you refactor an application, your first concern should be functionality: Will this application run in your chosen cloud environment? Once you’ve hit that baseline, you can turn your attention to optimization. 

In order to take full advantage of cloud capabilities, you’ll want to prepare your application for horizontal scalability. If your application is built to run on a fixed number of servers, make changes to allow for variable server numbers—this way you can make use of the cloud’s auto-scaling features. 

You may also want to break your application down into individual services. This way you can migrate service by service instead of all at once.

Create a data migration plan and switch over production

Data migration is the most delicate aspect of cloud migration. There’s a lot that can go wrong. 

If you’re nervous about this step, there is a good safety option: You can always use a cloud data-migration service to do the legwork for you. (AWS provides one, as do other cloud providers.)

Data migration refers to the process of moving data from your on-site servers into the cloud. Migration is complete when you “pull the plug” on your on-site servers and allow users to connect to the new cloud-based servers. 

When you disconnect your legacy servers, it is crucial that the data they contained has been sent to the cloud. There are two ways to ensure your data is up-to-date when you make the final switch: two-way (or bi-directional) syncing and one-way (or mirrored) syncing. Let’s take a closer look at each:

Two-way data syncing:

In two-way (or bi-directional) data syncing, both of your databases—on-site and cloud-based—push and pull changes. As you gradually move customers to the cloud, any changes they make will be reflected in your on-site databases. Some customers will still be connected to the on-site data—their data will also be pushed to the cloud. Once you’ve pushed all data to the cloud, you can go ahead and pull the plug on your on-site databases. 

One-way data syncing:

Whereas two-way data syncing allows you to gradually transfer customers to the cloud, one-way (or mirrored) data syncing does not. In one-way data syncing, you push data from your on-site databases to the cloud. Once you’ve pushed all of the data, you transfer all of your customers to the cloud and pull the plug on your legacy databases.

One thing is true of both approaches: To properly transfer your data, your team must collaborate and communicate clearly. To keep everyone on the same page, you can document your data migration process with a Lucidspark board. At each step of the process, team members will be able to access the board to see what has been done, what needs to be done, and what their responsibilities are.

Once you’ve successfully migrated your data, it’s time to connect customers to the new database!

Review application resource allocation

So you’ve finished your migration, everything seems to be running smoothly, and you’re operating fully in the cloud. You’ve completed your cloud migration checklist, right? Not quite. 

Before wrapping things up, you’ll want to take the time to review your application’s resource allocation. One of the great advantages of the cloud is that it allows for dynamic resource allocation—you can add and subtract servers as needed. You only pay for what you are using. If your app is optimized to take advantage of this function, that is. 

You should’ve optimized your app during the refactoring process, but it never hurts to double check. As your app runs in the new cloud-based environment, closely monitor its performance to ensure it is running as it should.