Cloud Computing.com

What is cloud migration? Essential guide to moving to the cloud

By Stephen J. Bigelow

Cloud migration is the process of moving data, applications or other business elements to a cloud computing environment.

There are various types of cloud migrations an enterprise can perform. One common model is to transfer data and applications from a local on-premises data center to the public cloud. However, a cloud migration could also entail moving data and applications from one cloud platform or provider to another; this model is known as cloud-to-cloud (C2C) migration. A third type of migration is a reverse cloud migration, cloud repatriation or cloud exit, where data or applications are moved off of the cloud and back to a local data center.

Why is cloud migration important?

Cloud migration is a process of transition or change. When an organization decides to use a cloud service, the goal is to treat computing as a utility -- like electricity, water or natural gas. The highly scalable, pay-as-you-go nature of the public cloud provides businesses with the flexibility to use only the resources needed, for only as long as needed, and pay only for those resources that are actually consumed. It's an attractive paradigm shift that entices businesses of all sizes and verticals.

But making the choice to run business workloads and host business data in a cloud can be more complicated than it might appear. Not all workloads are suited for the cloud. This can be due to the performance demands, dependencies or design of the workload itself. It can also be complicated by compliance, security and other regulatory guidance that impacts how and where a business can run its computing tasks -- such as the growing requirements surrounding data sovereignty.

Successful cloud migration is an important business process as much as it is a technical process. Any cloud migration must start with clear business use cases and goals. Only then can technical staff chart the tricky course through cloud architecture composition; select data and workload vehicles, such as virtual machines, storage volumes and containers; connect cloud services, such as firewalls, load balancers and even databases; make the actual migrations needed to run the desired workloads in the cloud; and then perform the testing and ongoing monitoring needed to ensure that the workloads in the cloud are secure and performing as needed over time.

Consequently, cloud migration can be challenging for some applications, and migration projects can sometimes fail -- often leading to remediation, such as cloud repatriation. The key here is that cloud migration is not an all-or-nothing deal. Businesses that evaluate and approach cloud migration on an individual workload basis can make cogent decisions about cloud utilization in a way that is most beneficial to the organization. Even a cloud migration that fails for one workload does not preclude successful and beneficial cloud use for countless other workloads.

What are the key benefits of cloud migration?

Many organizations migrate on-premises applications and data from their local data center to public cloud infrastructure to take advantage of benefits such as greater elasticity, self-service provisioning, redundancy and a flexible pay-per-use model.

The general goals or benefits of a cloud migration are essentially the same as the reasons to use the cloud itself: to host applications and data in the most effective IT environment possible, based on factors such as cost, performance and security. The following is a more comprehensive list of specific cloud migration benefits:

• Better agility and flexibility. Clouds are built to deliver almost any amount of resources (computing and storage) and services on demand. This lets organizations deploy and scale workloads immediately without the need to await infrastructure purchases, use the resources as long as needed and pay only for the resources actually consumed.
• Better scalability. When a workload demands more resources to maintain and enhance performance, the cloud can deliver those additional resources immediately without the need to procure and deploy new hardware and platforms, as these are already present and available in the public cloud.
• Ability to innovate. Clouds enable businesses to try new architectural designs and test workloads -- and potentially fail -- without investment or risk in local infrastructure. This can help businesses try new workloads and approaches with less infrastructure investment and corresponding risk.
• Mitigate local resource demands. Clouds take the pressure off costly local data center utilization and expansion demands. The local data center can continue to service critical workloads, while other routine or noncritical workloads can be hosted in the cloud. Businesses can forestall or even cancel data center construction or expansion -- and, in some cases, even reduce local data center footprints.
• Long-term cost management. Clouds are not necessarily less costly than local data centers over time, but the shift from huge capital outlays in a local data center to modest recurring monthly operational expenses in the cloud can help a business better manage project budgets and cost forecasting.
• Better workload performance. Global workloads can suffer latency and other performance limitations when served from a single data center. Public clouds provide many regional data centers in different geopolitical regions around the world. This enables businesses to host workloads closer to their respective users for better performance (lower latency) while observing data sovereignty and other regulatory requirements of those differing regions.

Types of cloud migration strategies

Moving workloads to the cloud requires a well-thought-out strategy that includes a complex combination of management and technology challenges, as well as staff and resource realignment. There are choices in the type of migration to perform as well as the type of data that should move. It's important to consider the following cloud migration checklist before taking action.

There are three fundamental strategies for migrating an enterprise workload from the local data center to a cloud provider's infrastructure:

• Lift and shift. This strategy -- also called rehosting -- is the most direct approach, where a local workload and its data are basically moved (rehosted) to corresponding compute and storage resources within a cloud provider's infrastructure. For example, a workload in a virtual machine (VM) and its storage volume can be redeployed to the cloud with relative ease and speed when there are few dependencies and minor business impact.
• Re-platform. Not all workloads can accommodate simple rehosting. Many enterprise workloads can be complex with numerous dependencies, and a business might choose to make some changes to the workload's deployment schema to improve its performance in a public cloud environment. If a workload requires a database, for example, the business can use a compatible database service already hosted and available through the cloud provider rather than deploying a copy of the corresponding database. Re-platforming a workload can be more difficult and time-consuming -- and require more testing and validation -- than rehosting.
• Refactor. This type of cloud migration involves a fundamental redesign of the workload itself in order to optimize its use of cloud resources and improve its performance in the cloud. For example, consider a single monolithic workload deployed as a large and unwieldly VM that is difficult to scale. This workload can be redesigned as a container-based, Kubernetes-powered microservices application capable of automatically scaling different microservices components in order to enhance performance while minimizing the use of cloud services. Refactoring a workload is often the most time-consuming and complex type of cloud migration project, which is usually reserved for businesses with cloud-first workload design and deployment strategies.

In terms of the actual migration approach or process, every company has a different reason to move a workload to the cloud, and goals for each organization will vary. The first step is to identify the application or workload to move to the cloud. Next, figure out how much data needs to be moved, how quickly the work needs to be done and how to migrate that data. Take inventory of data and applications, and look for dependencies and how those will be replicated in the cloud or possibly rearchitected to accommodate numerous cloud service options.

Remember that not every application should leave the enterprise data center. Among those that should stay are applications that are business-critical, have high throughput, require low latency or have strict geographic stewardship requirements such as GDPR.

Lastly, consider the costs. An organization might have steep investments in hardware infrastructure and software licensing. If so, weigh whether it's worth it to migrate the workload. After a cloud migration, IT staff will focus on data performance, usage and stability, so be sure to budget for tools that support these functions.

Cloud migration deployment models

Enterprises today have more than one cloud model from which to choose:

• Public. The public cloud lets many users access compute resources through the internet or dedicated connections.
• Private. A private cloud keeps data within the data center and uses a proprietary architecture.
• Hybrid. The hybrid cloud model mixes public and private cloud models and transfers data between the two.
• Multi-cloud. In a multi-cloud scenario, a business uses IaaS options from more than one public cloud provider.

Beyond this initial choice of cloud model, there are three major cloud categories that should be considered for cloud deployments:

• Infrastructure as a service. IaaS is the classic "utility computing" model where computing, storage and services such as firewalls and load balancers are made available to users who select and compose the cloud infrastructure in a way that is best suited for the workload being deployed to the cloud.
• Platform as a service. Platforms are cloud offerings designed to provide specific or highly integrated capabilities that alleviate the need for users to deploy and maintain such capabilities themselves. PaaS examples include a cloud-based software development platform or a container deployment/management platform.
• Software as a service. In the SaaS category, the cloud service provides users with access to one or more specific workloads, such as productivity applications like Microsoft's Office 365 or Concur for employee expense reporting and reimbursement. Using SaaS eliminates the need for a business to deploy and maintain that application -- instead leaving the development, operation and maintenance of the application to the provider.

It's important to note that all three cloud categories can be used concurrently in any combination that suits the needs of the particular business.

When determining where the application should live, consider how well it will perform once it's migrated. Ensure there is adequate bandwidth for optimal application performance. Also, determine whether an application's dependencies could complicate a migration.

Review what's in the stack of the application that will make the move. Local applications might contain a lot of features that go unused, and it is wasteful to pay to migrate and support those nonessential items. Stale data is another concern with cloud migration. Without a good reason, it's probably unwise to move historical data to the cloud, which typically incurs costs for retrieval.

While examining the application, it can be prudent to reconsider its strategic architecture to set it up for what could potentially be a longer life. A handful of platforms support hybrid and multi-cloud environments, including the following:

• Microsoft Azure Stack.
• Google Cloud Anthos.
• AWS Outposts.
• VMware Cloud on AWS.
• Container-based PaaS, such as Cloud Foundry or Red Hat OpenShift.

How does the cloud migration process work?

The cloud migration steps or processes an enterprise follows will vary based on factors such as the type of migration it wants to perform and the specific resources it wants to move. That said, common elements of a cloud migration strategy include the following:

1. Understand the purpose. This is the "why" of any cloud migration. Every cloud migration should start by defining tangible business purposes for the migration and set clear expectations from the migration project. If the business cannot identify at least one tangible or measurable reason for a migration, it's often best to pause the project early on.
2. Determine the target application(s). This is the "what" of the cloud migration project, where business, technical and compliance leaders assess the local environment and identify potential candidates for a cloud migration. Not every workload is suited to the cloud because of performance, security, compliance or other issues, so deciding what workload(s) should be included in a migration is a vital step forward. In addition, a migration is not an all-or-nothing process. It's often advisable to migrate workloads as individual projects rather than epic all-encompassing transformations. Start small with simple, low-priority workloads with few -- if any -- dependencies and gain experience with the migration process and pitfalls before tackling more complex or critical workloads. Migrations must include all dependencies, such as related databases, in the migration project.
3. Choose the cloud target. This is the "where" of a cloud migration project. Once an application is selected for a cloud migration, the business can select the cloud deployment model -- such as public, private, hybrid or multi-cloud, as well as IaaS, PaaS or SaaS -- that is best suited as the destination. For example, a simple migration using a SaaS offering to replace an aging local workload might involve a leading SaaS provider, while an advanced business transformation strategy might involve creating a private cloud, establishing a hybrid cloud and then making the migration.
4. Select a proven cloud partner. It's important to consider cloud targets carefully to ensure that the provider has a proven track record and will be in business for the foreseeable future. This might seem like an excessive precaution, but provenance is everything in cloud computing. The most disruptive event for a business is finding that a vital provider is closing its doors, forcing businesses to scramble to find alternative providers -- often with undesirable outcomes.
5. Evaluate migration costs and needs. A cloud costs money, and any migration project must consider the costs of migration. This typically includes per-month fees for a SaaS, per-user fees for a PaaS and the various costs of IaaS resources and services. Since cloud costs are recurring, businesses will need to budget appropriate funds for migration and ongoing support. Similarly, understand the performance requirements and expectations from the workload once the migration is complete, and be prepared to establish metrics and KPIs for ongoing workload performance monitoring and reporting.
6. Choose the appropriate architecture. While PaaS and SaaS architectures are largely set and their costs are relatively straightforward to determine, composing an architecture for a workload within an IaaS cloud environment can be challenging -- especially for highly scalable architectures. It requires the efforts of a skilled cloud architect with expertise in the chosen cloud target to compose an environment with the reliability, security, monitoring and performance to meet the workload's needs. Cost data from IaaS architectural designs should loop back to refine the cost analysis and budgeting for the workload.
7. Create the migration plan. This is both the "when" and "how" of the cloud migration, enabling a business to outline its approach and timeline for the actual migration. The plan should include provisions for detailed data migration; testing and validating dependencies first, such as the required databases; moving the intended target workload; and then performing all final testing and validation. Only then should there be a clear cutover process to turn the local workload off and turn the newly migrated cloud workload on. Finally, there should be consideration of rollback processes for failed or problematic migrations. Any migration testing should include detailed attention to access and security.
8. Perform the migration. With all the pieces and plans in place, the business can migrate data and workloads in accordance with its migration plan. This is where all of the movement and detailed testing takes place. Business and technology leaders -- and often workload owners -- should see initial performance reporting to ensure adequate performance and security under full load. Cautious migration plans might run the cloud and local workloads concurrently for a short time, syncing data and opening the cloud workload to systematically more users until the cloud deployment is fully validated and cutover.
9. Follow monitoring and reporting. Cloud workloads are typically instrumented with performance monitoring services to track workload availability, access, health and performance as it runs in the cloud. Stakeholders should verify that reporting is available and KPIs meet expectations.
10. Follow-up and organizational changes. There might be some aftermath to a cloud migration. At the technical level, the local resources -- such as servers and storage -- previously utilized by the local workload might be freed for reuse or decommissioned to save power and cooling costs for the business. At the business or organizational level, the movement of a workload into the cloud might result in some staff reassignment. For example, moving a custom workload to a SaaS offering could free developers to work on other projects.

At the same time, be prepared to address several common challenges during a cloud migration:

• Interoperability.
• Data and application portability.
• Data integrity and security.
• Business continuity.

Without proper planning, a migration could degrade workload performance and lead to higher IT costs -- thereby negating some of the main benefits of cloud computing.

Moving workloads. Depending on the details of the migration, an enterprise might choose to move an application directly from local servers to its new hosting environment in the cloud without any modifications; this model is sometimes referred to as a lift-and-shift migration. This is essentially a one-to-one move done primarily as a short-term fix to save on infrastructure costs.

In other cases, it might be more beneficial to change an application's code or architecture. This process is known as refactoring an application or rearchitecting it. This can be done in advance of a cloud migration or retroactively once it is clear that a lift and shift has reduced an application's performance.

IT management should consider whether refactoring an application makes financial sense. Calculate cost, performance and security when analyzing the ROI. An application likely will require at least some refactoring whether the transformation is minimal or comprehensive.

Moving data. Enterprises have several choices when it comes to transferring data from a local data center to the public cloud. The type of data migration an enterprise chooses depends on the amount and type of data it wants to move, as well as how fast it needs to complete the migration.

One way to migrate data and apps to the cloud is through the public internet or a private/dedicated network connection. With this method, be sure to calculate and provide the necessary bandwidth. For significant volumes of data, it might be unrealistic to sideline your internet connection, so make sure to plan accordingly to avoid lengthy downtime during the cloud migration.

Another option is an offline transfer. With this, an organization uploads its local data onto an appliance and then physically ships that appliance to a public cloud provider, which then uploads the data to the cloud.

In some cases, it might make more sense simply to use a truck to transfer large volumes of data. Major providers -- Microsoft, AWS, Google and IBM -- all offer services for offline data shipping. Physical shipment might not eliminate the need for additional syncing, but it can cut the time and expense required to move the data.

Cloud migration testing. Before the workload moves to production, it should be stress tested and optimized to deliver acceptable performance. It's also important to test failure conditions as well as redundant systems. You shouldn't try to test every possible app function, but you do need to establish a solid understanding of several aspects of application performance before and after it goes to the cloud. Form a cloud migration testing strategy to confirm an application's baseline performance before and after the move -- including application start times and response times -- as well as establishing proper security and access and successful integrations with other services. Proper testing requires suitable tools along with well-considered policies and practices for testing and validation.

Cloud migration security. There are special considerations for the new security realities during a cloud migration. Migrating data or apps through a network potentially opens up vectors to various types of attacks, including stealing credentials and VM snapshots, installing malware or a thrashing persistent denial-of-service attack that forces repeated migrations and consumes system resources.

First and foremost, organizations should understand their cloud provider's shared responsibility model, which outlines the areas for which the organization and the provider are responsible. For users, typically this means everything above the underlying infrastructure, including data, access and governance. It's important to establish rules and structures around governance, access management and monitoring. Legal and compliance teams should have a role in cloud migration decisions to help ensure proper adherence to compliance requirements for workloads and data.

Changing IT staff roles. Once the cloud migration is complete, staff will shift their focus to data performance, usage and stability. There is some reduction in overall hardware support. However, cloud workloads must be managed, so consider adding some cloud management training classes for the team.

Best practices to ensure cloud migration success

There are many reasons why an organization chooses to migrate an app or workload to the cloud, and each project will be unique depending on resource allocations, integrations with other services and multiple other factors. Here are some general guidelines for a cloud migration that streamline the process and improve changes for success:

• Get organizational buy-in. The transition is much smoother when all stakeholders are on board and know their roles, from management to technical practitioners to end users.
• Define cloud roles and ownership. Determine upfront who is responsible for managing various aspects of the cloud workload. Is it a shared environment? How is identity confirmed and access granted, or limited? If problems arise, who handles help and troubleshooting? This includes proper documentation of setups and processes.
• Pick the right cloud services. Cloud providers have a vast menu of services to pick from. Be clear with which ones your workload will tap into, or you risk running extraneous services -- some of which can be costly, interdependent and problematic to manage.
• Understand security risks. Cloud environments can be susceptible to mischief from internet attacks. Misconfigurations are arguably a bigger problem, given the complexity of cloud environments. Establish security policies for cloud deployments, ensure those policies are followed and perform comprehensive security testing to identify potential vulnerabilities.
• Calculate cloud costs. The cloud's pay-as-you-go model might seem attractive and simpler to organizations used to large infrastructure investments. But it's a double-edged sword: Pay close attention to service selections and usage or you'll get a shock at the end of the month. Look for unused resources and services -- known as cloud sprawl -- and work to eliminate unneeded costs.
• Devise a long-term cloud roadmap. If a cloud migration is successful, organizations likely will look to replicate that success for other workloads. Identify the criteria to follow, from project timelines to different deployment options, such as a hybrid cloud setup.

What are the challenges of a cloud migration?

As with any major technical endeavor, the business faces potential problems and challenges during and after the application migration process. A solid strategy won't completely eliminate all the hurdles and potential problems with a cloud migration. These challenges can include the following:

• Uncertain and excessive cloud costs. A traditional data center represents a mainly fixed cost for the business, enabling workloads to operate with a high degree of cost confidence. Clouds are more like other utilities where pay-per-use cost models can result in radically different costs to operate a workload. Unexpectedly high service utilization, such as API calls, or unplanned application growth that uses scalability to drive more resources to the workload can result in unexpected cloud costs that a business is not prepared for. Cost planning is a core part of cloud architecture and benefits from the experience of a professional cloud architect to implement a sound design and place guardrails around scalability to help prevent cloud sticker shock.
• Lack of cloud strategy. Too many organizations choose cloud migration because it's mistakenly seen as a transformative exercise -- and business leaders are just following the hype. Simply choosing to migrate to a cloud is not business transformation; the transformation is not in using the cloud, but rather in how the cloud is used to help benefit and improve the business. It's all in the cloud strategy. A poorly conceived or absent cloud strategy can doom a cloud migration. Good cloud strategies must focus on mastering the current infrastructure and target cloud, anticipating migration bottlenecks, creating remediation contingencies and so on. The goal is to plan: why do it, what to do, how to do it, what can go wrong and what to do when things go wrong.
• Application performance in the cloud. Sometimes IT leaders discover that their applications don't work as well in the cloud as they did on premises. They need to determine the reasons for the cloud migration failure; it could be poor latency, concerns about security or perhaps compliance challenges. Often, the cloud-deployed application has a higher cost than anticipated or it does not work as well as originally anticipated. This is typically not a failure of the application nor the cloud but simply a reality that some traditional application architectures are not optimized for the computing, storage, networking and ancillary services of a public cloud.
• Application suitability for the cloud. There's another reality to acknowledge: Not every application is a good fit for the cloud. Managers must scrutinize their on-premises applications when they make their initial choice about which should move to a cloud environment. Choices for migration candidates are varied and can be based on both business and technical criteria. For example, a mission-critical workload with sensitive data might be left on premises because that's the overriding choice for business issues such as compliance and data sovereignty.
• No cloud exit strategy. An often-overlooked aspect of a cloud migration plan is to have a solid cloud exit -- or repatriation -- strategy, where the apps and data move out of the cloud and are returned to their original state on premises or to a private cloud. IT managers must consider where the data will go, how to manage the technical transition and how to address any business or legal issues that might arise. Be sure to test the app before and after the repatriation, just as with the initial migration. If the app was altered to accommodate specific cloud benefits, such as horizontal scaling, those benefits would be lost when the app comes back on premises.
• Failure is not permanent. Many cloud migrations that fail are reversed only temporarily. They can be reassessed and possibly rearchitected, rather than a lift-and-shift rehosting, and then sent back into the cloud with higher probability of success. Consider the changes made prior to moving the application to the cloud. Moving the app back to its original platform might be one option. In other cases, applications that are re-platformed or refactored specifically for the cloud might even face trouble moving back to traditional on-premises infrastructures. The best option there might be to try migrating to a different cloud or patching/updating to overcome any problems before attempting the migration again at a later date.
• Poor infrastructure design or provisioning. Optimal application performance and availability requires an optimal cloud infrastructure design with the proper resources and services provisioned to the workload, such as virtual compute instances, storage volumes, networking elements and supporting services. Missing or inadequate design will adversely impact the workload in the cloud and can lead to migration failure. For example, a common mistake made by cloud administrators is setting up the wrong instance type. Be sure to select the right amount of CPU and memory resources, as well as enough network connectivity for the chosen storage and app data transmission. Cloud migrations often require the work of well-trained and experienced cloud architects and engineers that can understand workload needs and architect the best cloud components to host the migrated workload.
• Inadequate or ill-trained staff. Don't underestimate proper staff training. Managing apps in the cloud is unlike working with local data centers and routine virtualized resources, and thus requires a different set of IT and management skills. In particular, data security requires a different approach in the cloud than on premises. Staff training needs to be a priority. Consider employee skill sets, and make sure everyone is properly trained on how to control and manage the relevant services. If staff cannot be trained prior to a cloud migration, it makes sense to hire an experienced AWS partner to manage the project.

Cloud migration tools and services

Workload management alters significantly when an application moves to the cloud. Enterprises should calculate the cost of a cloud configuration before a migration to avoid unexpected surprises. IT staff needs to change their management processes to work as well in the cloud as they do locally. This can be achieved by any number of services and tools.

The big IaaS providers -- AWS, Microsoft and Google -- offer various cloud migration services as well as free tiers. Here are a few examples:

	AWS	Azure	Google Cloud
Database migration	AWS Database Migration Service	Azure Database Migration Service	Database Migration Service (preview)
Data transfer appliance	Snow Family	Data Box	Transfer Appliance
Disaster recovery	CloudEndure Disaster Recovery	Azure Site Recovery	N/A
Online data transfer	AWS DataSync, AWS Transfer Family	Azure File Sync	BigQuery Data Transfer Service, Cloud Data Transfer
On-premises application analysis	AWS Application Discovery Service, Migration Evaluator	Azure Migrate, Movere, Azure Resource Mover	N/A
On-premises and cloud storage integration	Storage Gateway	StorSimple	N/A (offered by partner Cloudian)
Migration tracker	AWS Migration Hub	Azure Migrate	N/A
Server migration	AWS App2Container, AWS Server Migration Service, CloudEndure Migration	Azure Migrate	Migrate for Anthos, Migrate for Compute Engine, VM migration

Cloud cost calculators and estimation tools help enterprises determine the cost of a cloud configuration before the team makes the migration. Cloud optimization tools can offer recommendations for a particular cloud environment in areas such as cost, performance and security.

There are a few automation options for lift-and-shift migrations, but what's most important is understanding app performance and resource requirements prior to the move. The migration of composite apps that rely on databases or other important dependencies can be partially automated, but users will have to manually fix database migration problems that could arise. Dependencies might need to be migrated to the cloud or enabled as cloud-native services as one or more precursor migration projects before the actual intended workload migration takes place.

Cloud migration trends

A number of factors influence an organization's decision to consider if an app or workload should move to the cloud.

Broadly, the cloud plays a central role in most digital transformation initiatives. Big data analytics is an attractive lure of cloud platforms, offering scale and computing resources unattainable by most on-premises systems. This is most evident today in machine learning and artificial intelligence platforms. And as enterprises expand their use of cloud-native technologies, they seek more standard template-driven processes rather than relying on assumptions and a small core of developers and architects.

The COVID-19 pandemic spurred many businesses to speed up their plans to move to the cloud, particularly with increased remote work requirements. At the same time, workers and consumers now want better user experiences in all aspects of their digital lives. The scalability and global availability of the public cloud can play a central role in enhancing workload performance and improving those user experiences. Single cloud deployments are shifting to hybrid and multi-cloud strategies intended to allow businesses to benefit from the unique strengths of different providers while meeting specific business needs.

Other emerging cloud migration trends to watch include adoption of financial ops, or FinOps, to understand cloud cost considerations and an embrace of sustainability initiatives and social issues -- such as the cloud providers' use of renewable or green, or low-carbon-footprint, energy sources -- that are increasingly popular with consumers and employees.

Ready to migrate to the cloud? Answer these questions

Cloud computing ultimately frees an enterprise IT team from the burden of managing infrastructure and uptime. Placing an application in the cloud is often the most logical step for growth. A positive answer to some or all of these questions could indicate your company's readiness to move an app to the cloud.

Should your application stay or go? The public cloud is often well suited to noncritical routine, experimental or temporary workloads. Legacy applications, or workloads that require low latency or higher security and control, probably should stay on premises or move to a private cloud.

What's the cost to run an application in the cloud? One of the primary benefits of a cloud migration is workload flexibility. If a workload suddenly needs more resources to maintain performance, its cost to run could escalate quickly. Good cloud management is critical to finding and eliminating cloud sprawl, while policies and cost guardrails can help mitigate cloud spend.

Which cloud model fits best? Public cloud provides scalability through a pay-per-usage model. Private or on-premises cloud provides extra control and security. A hybrid cloud model provides the best of both, although performance and connectivity might suffer. The choice of IaaS, PaaS and SaaS will further help identify the best cloud environment for each workload.

How do I choose the right cloud provider? The top three cloud providers -- AWS, Microsoft and Google -- generally offer comparable services to run all kinds of workloads in the cloud, as well as tools to help efficiently move apps there. Also, remember that similar services are not necessarily interoperable services, and it can be hard to move a workload once the migration is complete. Gauge your specific needs for availability, support, pricing, and security and compliance to find the best fit. A hybrid or multi-cloud strategy might offer more versatility for the business.