Cloud Migration(Lift-and-Shift): My Notes From the Ground
Notes from the experienced tech leader, who led the team to migrate a complex on-prem private monolithic stack (OpenStack) to the public cloud(AWS).
Join the DZone community and get the full member experience.Join For Free
Here are my notes based on my experience of moving the complex on-prem(private cloud) stack to the public cloud. It needs a lion's heart to 'Lift-and-Shift' a complex application generating millions in revenue. If it's a public company, then double that.
What Is Lift-and-Shift?
Lift-and-shift is the process of migrating your SaaS application from On-prem/Data-center to the public cloud (AWS/GCP/Azure), without changing the core functionality of your application.
Why Not Rewrite? Why Lift-and-Shift?
Rewriting the code of an active-production complex system to modern architecture is a big engineering undertaking. It's a 'big bang' approach, fraught with execution risks, with too many unknowns. Lift-and-Shift eliminates most of the unknowns and provides an easier path to migration from on-prem to cloud. It further
- Enhances scalability, security and improves MTTR/RTO (quick operational wins).
- Leverages working modules/applications.
- Buys time for business as well as engineering to re-architect.
- Helps set priorities in terms of rewriting the modules/components for the next-gen platform.
'Customer-first approach, without sacrificing the speed.'
Phase 1: Preparation and Planning
- Define clear business objectives and scope.
- On-board all engineering teams. You need them!
- List all the compliance and various internal/3rd party API security requirements.
- Build teams for automating:
- Infrastructure orchestration.
- Application refactoring.
- QA and Stress testing.
- Data migration.
- Plan to bundle Infrastructure code along with applications for future releases.
- Know your baselines to compare:
- SLO for services.
- Stress metrics.
- Synthetic checks.
'Most well thought plans will have some surprises in store.'
Phase 2: Execution
- The project plan should have clear measurable milestones.
- Have room to rewrite some portions of code for cloud adaptability. It should not change the core functionality. it should be either an on-prem component swap or an improvement to meet your security/compliance requirements.
- Add in test cases to validate migration scripts (eg. look out for hardcoded user-data and API reference changes).
- Start load testing as soon as you have an MVP on the cloud. (fail fast.)
- Change management is done through automated release cycles.
'People with stellar reverse engineering skills are great assets to the team.'
Phase 3: Migration
- Test your automation scripts and validate the data.
- Stress-test results for synthetic checks should be on par or better when compared to active customers of on-prem.
- Plan for canary deployments. (Identify your early adopters for the pilot program.)
'Collaborate, Monitor, Migrate.'
Published at DZone with permission of Shankar Muniyappa. See the original article here.
Opinions expressed by DZone contributors are their own.