This post is a quick summary of 6 common migration strategies that Amazon observes from its customers. You can read the original post here. It's part of a series of posts about cloud migration.
Rehosting does not take advantage of any cloud-native capabilities. It is simply running your existing legacy app on cloud infrastructure. Most rehosting can be done using automated tools, however a manual migration can be useful to learn how to apply the workload in the new cloud environment. Additionally, applications are often easier to optimize or re-architect once they are already running in the cloud. This party because of people, talent, and process and also partly because migration of the application, data, and traffic is already done (the hard part).
Replatforming conserves the core architecture of an application, but leverages some cloud capabilities. An example might be replacing a database instance in your data center with a database-as-a-service platform that handles some of the operational load. Another example might be replacing queue or pub/sub service with AWS SQS.
This strategy is when companies move to a SaaS platform. Common examples are moving your CMR to Salesforce or an HR system to Workday.
This strategy is a full blown re-imagination of the applications core architecture. It's usually driven by business needs for new features, scale, or performance that are not feasible on-premise. It can also be part of a larger strategic initiative like shifting towards portable workloads (containers), container management platforms such as Kubernetes (I like to think of them as abstracted-compute platforms), and multi-cloud or multi-data center postures.
Sometimes it's the better business decision to shut down an application entirely. The resources (people, money, compute) freed up from this can be put to better use.
Randy Pausch said "Never make a decision until you have to." If an application does not meet the bar for taking action via one of the other five migration strategies, it will be retained.