There is no universal terminology for such migration strategies and looking at the orthogonal issues, there are certainly more than three.
Before elaborating about the migration strategy, let's just recall that there are 3 main categories of cloud services:
- Infrastructure as a service (IaaS): your systems and applications work as before, but instead of running on servers in the local datacenter, they run on hosted computing resources that can be adapted flexibly to the needs and are operated by a service provider.
- Platform as a a service (PaaS): your systems and application work as before but instead of operating your software platform(s) (e.g. database, containers, etc...) yourself, they are build on the top of platform services in the cloud.
- Software as a service (SaaS): you don't use your own systems & services anymore, but use ready to use, off-the shelf, cloud applications sold as service packages (e.g. user based subscription that covers the use of the application, its maintenance, its operations and perhaps even the support).
This influences the migration strategy, and there are some common patterns that inevitably emerge:
- rehosting, which is indeed also known as lift & shift: here you, you consider cloud essentially in terms of IaaS; you switch from one hosting infrastructure to another.
- replatforming, sometimes called lift & shape: here, you move consider cloud platform and you transform your existing applications to take advantage of cloud platforms. I think, this could correspond to the idea of lift and transform. Ttere are some variants, depending on the degree of transformation: refactoring changes some components to use cloud platforms, re-architecting is a more important changes required to take advantage of cloud platforms, re-building is starting from scratch for adopting a cloud-native design.
- replacing, sometimes called drop & shop: here you consider fully packaged cloud services and you abandon existing legacy applications in favor of SaaS. Note that the packaging may be also service or microservice based (e.g. a service for managing payment transaction) and not solely full applications (e.g. an HR recrutitment software deliverad as a service).
Now there are many more strategies, if we consider orthogonal topics and the resulting combinatorial explosion, for example:
- We've already seen that we have 3 basic patterns. There are 6 if we consider the above-mentioned variants.
- Then we have the chronological aspect: incremental migration, darwinistic (both old and new systems are available at the same time and the best will survive / i.e. in this case, the users will switch progressively), or big bang (all at once).
- Then we have the sourcing strategy (which might also have an impact on the technology): single cloud approach, multi-cloud approach or hybrid