Migrate virtual machines:
Moving entire VMs is one way to migrate an application to the cloud. There can be unexpected side effects depending on how the VM was attached to the on-premises network, the domain it was part of, the types of drives used, and more. While a “lift and shift” of VMs often appears to be the easiest route to the cloud, the Active Directory schema must be extended to any new public or private cloud location prior.
Migrate data:
Your data may move to a database-as-a-service environment, or a self-managed database instance. Make sure you know which tools are provided by the vendor, and what limitations exist regarding data volume, or structure. Make sure applications and data are supported in the new location/s.
Migrate applications:
Make sure the application deployment can natively point to cloud infrastructure, containers, or application platforms. It may take some reconfiguration to get your on-premises tools to deploy code to the cloud, or you might evaluate new tools to make the process more seamless.
Recreate metadata:
While assets like virtual machines and application code can move relatively freely between clouds, environment metadata is often very provider-specific. Account structures, users, permissions, policies, load balancers, and the like vary from cloud to cloud. Make sure you know how to set up the supporting configurations for your particular cloud destination.
Migration:
With proper upfront planning, the migration itself should be uneventful. For large data sets, however, you might be incurring significant bandwidth charges from your ISP provider and long transfer times. In those cases, it’s better to either (a) compress the data or copy it to a staging location in the target cloud before transferring it to the final destination, or (b) physically ship drives to the cloud location.