While the public cloud can help an organization shed the long-term, costly demands of a local data center, it isn't the best hosting environment for all enterprise workloads.
This makes it critical to carefully assess each application's suitability, requirements and readiness before a cloud migration. Let's take a look at some of the key issues involved in performing a cloud migration assessment, as well as steps and tools that can help teams prepare for a move to cloud.
What primary factors should I consider in a cloud migration assessment?
There are many issues an enterprise needs to evaluate as it assesses which workloads would be a fit for public cloud. Some of the most critical are regulatory requirements, security and performance.
Regulatory
Regulatory governance can impose strict limitations on the physical location of sensitive application data, as well as the physical location of the corresponding application. This means a public cloud migration target may be restricted to provider data center sites that exist within a particular nation's border or other geopolitical boundary. These same limitations can apply to data backups and disaster recovery.
For example, if a cloud provider does not have an availability zone or region within an acceptable geopolitical boundary, an enterprise may not be able to migrate certain sensitive applications. A similar problem can arise when a cloud provider has a presence but lacks key security services.
Security
Before an enterprise moves an app to the public cloud, it must understand the shared responsibility model. While the cloud provider secures and manages the underlying infrastructure and services on which that application will run, the enterprise is still responsible for securing access to its data. This shift in responsibilities can be confusing for new cloud adopters and can sometimes lead to critical lapses in application and data security.
In addition, the cloud provider must offer transparency into its infrastructure and allow enterprises to monitor, log and audit application and user activity. As part of a cloud migration assessment, be sure to look for these tools in a potential provider.
Performance
There is no guarantee that an application will perform as well in the public cloud as it does in a local data center. This can be a serious problem in cloud migration, especially when users depend on the application's performance and availability. Legacy, monolithic applications -- particularly those with strict hardware or complex software dependencies -- experience the most trouble and may perform better on premises. On the other hand, cloud-native apps -- or those designed and coded from the start to run on public cloud instances -- generally yield the best performance and scalability.
Cloud migration assessment tools, including those from public IaaS providers, , as well as third-party tools, can help enterprises evaluate performance issues. However, it's still important to test workloads in proof-of-principle deployments to gather metrics and make migration decisions based on measured performance.
What are the key phases of cloud migration?
Although there are many ways to outline a workload's migration to the cloud, the process generally occurs in three primary phases: planning, deployment and maintenance.
Phase one: Planning
In this phase, identify which workloads should move to the cloud and which should stay on premises. Evaluate the business case for each migration you consider, as well as the intended benefits of the move. The business case should include requirements, goals or metrics that can quantify the effectiveness of the migration. For example, a business goal might be to scale an application to support a larger number of users without increasing investment in the local data center. The measure of success might be to monitor application latency or transactions to ensure workload performance.
Planning also involves app assessments to determine its suitability for migration, as well as an evaluation of potential cloud providers. Enterprises must determine whether the desired workload can be migrated and which provider would best meet its regulatory, security and performance requirements. Ultimately, a successful planning phase will result in the decision to move forward with the migration.
Phase two: Deployment
The next step in workload migration is deployment. In this phase, enterprises need to design, or architect, their cloud deployment, as well as understand which cloud services and instance types their workloads need.
It's rare to migrate production-class workloads outright. Instead, there is a shakedown period, during which an IT team copies the workload to the cloud environment and then tests, optimizes and validates that deployment, while the workload continues to function normally in-house. This gives an enterprise time to address and remedy any migration problems and refine any procedural issues, such as configuring and verifying backups.
Once the workload is validated and stakeholders sign off on the cloud deployment, administrators can cut over to the migrated application. However, it's a good idea to temporarily retain the local workload as well in the event of unforeseen problems.
Phase three: Maintenance
After deployment, cloud applications require ongoing support. Administrators, for example, need to monitor application performance and availability metrics, as well as access logs and trend data for capacity planning.
These applications will also require frequent patches and feature updates as they run in the cloud. Some updates are rather involved -- especially when an application is distributed or clustered among numerous nodes. Finally, application maintenance usually involves some troubleshooting.
What are some cloud migration tools?
There are various tools that can support a cloud migration assessment, as well as help perform and manage the actual migration itself.
There is no single tool that can support all cloud migration projects. Organizations need to select an assessment/migration tool that is best for the intended cloud provider and can accurately map the infrastructure and dependencies related to the target workload. Otherwise, the assessment -- and any resulting migration plan -- may not be successful.
