Whether you’re interested in testing out the cloud with a few workloads or are executing a full-scale cloud migration, you must determine which workloads will go first. But don’t just randomly pick a few.
Workload Assessment
Before deciding which workloads to move and which will go, inventory and assess them as part of your cloud migration strategy. For each workload, determine the following:
If it’s mission-critical
How often it’s used, who uses it, and what business requirement(s) it meets
If it has any application dependencies
If it has specific performance requirements
If it’s up for a refresh or is approaching retirement
If it involves data bound by regulatory compliance and/or if there are data sensitivity, privacy, or integrity issues
What quantity of CPU, memory, network, and storage will be needed
What specific monitoring or security agents are required
If it experiences periodic or unpredictable traffic spikes
If it needs to scale
In what language it’s written
If it’s web-based or built with a service-oriented architecture (SOA)
If it’s monolithic, two-tier, three-tier or n-tier
How difficult or expensive would it be to refactor it for the cloud
Once you understand your workloads, you can assess their suitability for moving to the cloud, what will be required and which should move first.
Identify What-Not-to-Move Workloads
As you flesh out your cloud migration strategy, it’s important to note that not all workloads can or should be moved to the cloud. Once you’ve determined which ones they are, put them at the bottom of your “move-to-the-cloud” workload list.
Keep in mind that some workloads require modification before they can move if they’re to perform optimally in the cloud and take advantage of what the cloud has to offer. Some require more work than others, so the time and cost of preparing them come into play. Others may not be appropriate for moving at all.
For example, you may have obsolete (or soon will be) applications that should either be retired and/or replaced. Some may be tied to highly customized, internal legacy equipment that would make it difficult for them to move.
Many legacy applications were designed and developed for on-premises infrastructure and aren’t designed to run in a cloud environment. This can lead to compatibility issues when trying to migrate them.
Then there are the workloads with high-performance computing (HPC) demand real-time data processing and heavy computational power with low-latency communication requirements between nodes. They may not perform well in the cloud, and their significant resource requirements can quickly increase costs – canceling out the cost benefits of moving to the cloud.
Data-intensive workloads may not be good candidates either. They tend to generate large amounts of data that are often best analyzed and processed close to where they are generated. This can be difficult to achieve in the cloud, particularly if the data is generated on-premises or in a different cloud region.
Another consideration: cloud service providers (CSPs) usually charge for data egress ─ the transfer of data from the cloud to external systems or networks. Costs can add up for data-intensive workloads that involve transferring large amounts of data between the cloud and on-premises systems or between different cloud regions.
Compliance-driven regulatory workloads may not be optimal for cloud migration in some cases as well. Although CSPs offer robust security measures, some organizations may be more comfortable keeping their data on-premises, where they can have full control over security.
Cloud-ready and Cloud-native Workloads
Cloud-native applications were written for the cloud – no problem there regarding their suitability for moving. But what makes a workload “cloud ready”?
A cloud-ready workload has been modified ─ refactored or re-platformed ─ to run in the cloud. Workloads that will require modification before they can move, particularly if it will be extensive, usually won’t be among the first to move. However, they should still be assessed and prioritized to ensure they’re ready to move when you’re ready to move them.
What Workloads to Move First
Once you know what workloads can, can with some work, can’t, and shouldn’t move to the cloud, you can prioritize them.
Simple apps ─ Tier 1 apps ─ that aren’t mission-critical and have few dependencies move first. This includes workloads that don’t require 24/7 execution, such as seasonal apps. They don’t pose much risk to your operations, including downtime. (These apps are ideal for piloting a cloud migration to see how the process works.)
Tier 2 apps ─ These apps move next. They may have a 24/7 execution period, but they aren’t too critical to disrupt the normal functioning of a company’s infrastructure.
Tier 3 apps ─ They’re mission-critical. Downtime isn’t an option. Move them once you’ve had a chance to see how migration works.
What specific workloads do most companies move first? It varies, but many choose to move backups, disaster recovery, and batch processing workloads first.
Applications used by mobile employees to manage their time and activity and that contribute only limited information to the company’s broad management information databases are also popular choices. Email is a good choice as well. (Surprisingly, many businesses are still utilizing in-house email servers.)
The cloud may also be appropriate for developing, testing, and prototyping application changes, even if the final app will run on your own infrastructure.
Additional Cloud Migration Resources
To learn more about prioritizing workloads to move as part of your cloud migration strategy – and about cloud migration strategies in general, check out these articles below from our blog or visit ourresource centerfor whitepapers, e-books, and more!