- Are a set of 6 different strategies of migrating systems into the cloud
- Starting point of a migration is the discover, assess and prioritize all the applications to migrate
- Once we have done this, there are 6 different ways of doing migrations:
- Rehosting: lif and shift
- Replatforming: lift and shift with optimizations
- Repurchase: migrate the application while using something newer, example SaaS
- Refactoring / Re-architecting: take advantage of the feature offered by the cloud
- Retire: dump the applications which are no longer needed
- Retain: do not migrate the application, not worth the time and money or it is too scary to migrate
- Lift and shift or migrate as is: move the application with the least amount of changes into the cloud
- Generally used with legacy or monolithic applications
- Reasons to do application rehosting:
- Reduce admin overhead using IaaS
- Potentially easier to optimize the application when is running in the cloud compared to working with legacy tooling
- Cost savings, consuming a certain type of instances
- Negatives:
- We wont be able to take advantage of the full Cloud offerings
- Potentially "kicking the can down the road" - delaying what we can do today until tomorrow
- For doing rehosting we can use VM Import/Export tools and Server Migration Service
- Similar to rehosting with the addition of applying certain optimizations to the applications as part of the migration process
- We might decide to use RDS instead of self-managed database instances
- We might use ELBs instead of self managed load balancers
- We might use S3 as a backup or media storage
- Replatforming approach brings no real negatives but also no world-changing benefits
- Potential benefits of migration:
- Admin overhead reduction
- Performance benefits
- More effective backups
- Improved HA/FT
- Unless we have a reason to use self-managed application, we would rather use XaaS (Anything as a Service) products
- Examples of this kind of migrations:
- MS Exchange => Microsoft 365
- Self managed CRM => SalesForce
- Self managed payroll => Xero
- Using a managed service reduces admin overhead, costs and risks. Almost always a preferred option
- Requires a full review of the architecture of an application
- The aim is to adopt cloud-native architecture and products
- We might look at adopting service-origin and microservice based architectures
- We might adopt a more API based architecture, event-driven architecture or serverless architecture
- This approach is initially very expensive and time-consuming
- In the long term it does offer the best benefits compared to other types of migrations
- Running a cloud-native application is often cheaper, much more scalable, has better HA/FT, costs are aligned with app usage
- Systems are often running for no reasons
- Auditing their usage is often more work than leaving them to run
- A migration is perfect time to re-evaluate the usefulness of an application. If we don't need it, we should switch if off
- Often saves 10% to 20% cost in case of large scale migration
- Essentially do nothing
- For some application the usage is uncertain with some complicating factors against being able to retire it or migrate it to the cloud
- In other cases some old applications might have some usage, but it wont worth the effort to move them to the cloud
- Or we might have a complex application - leave it till later
- Super-import application - risky to move
- The best advice is to complete the migration of other applications and swing back to focus on the left-overs
