We need to move a large, interdependent on-premises application with a legacy database to the cloud (thinking of a private cloud or hybrid cloud setup) with near-zero downtime. Should we choose Rehost (Lift and Shift) or the more complex Refactor approach? What's the best method to ensure seamless data migration and cutover?
3 answers
For a complex legacy system with strict zero-downtime requirements, the Rehost (Lift and Shift) strategy is typically the safer and faster initial approach, especially when moving to a Private Cloud or a secure Hybrid Cloud environment like VMware Cloud on AWS or Azure Stack. Rehosting minimizes application code changes, which reduces the risk of introducing new bugs and simplifies the testing phase. The most critical part is the data migration for your legacy database. Use a tool that supports continuous data replication (CDC) from your on-premises database to the cloud database instance. This allows you to run the two databases in parallel for a period, ensuring full synchronization. The final cutover then becomes a quick DNS flip and an application restart, significantly reducing the maintenance window and achieving near-zero downtime for your business-critical application.
Is the "Lift and Shift" (Rehost) really viable for massive cost savings and taking advantage of cloud-native services? While it's great for low downtime, doesn't avoiding the Refactor step right now just create technical debt that will cost more to fix later, particularly around future scalability and DevOps integration?
For near-zero downtime migration, go with Rehost first, but utilize a live migration tool (Hypervisor-level lift and shift) if possible. This minimizes disruption. Plan for a post-migration Refactor project to unlock better cloud-native features like auto-scaling and PaaS for long-term optimization.
Absolutely agree! We leveraged Relocate (a variation of Rehost) to move our entire VMware environment to a cloud-based VMware solution. It was the fastest path to the cloud for our legacy applications and kept our old operational skills relevant initially.
James, that’s an excellent point about technical debt and cloud-native adoption. You should definitely view Rehost as Phase 1 (speed and low-risk migration) and Refactor as Phase 2 (optimization). The goal is to move the system off expensive, aging hardware immediately to start saving CapEx, then you can spend the next 12-18 months intelligently refactoring components into microservices or serverless functions using a DevOps pipeline. This phased approach balances the immediate need for migration with the long-term goal of leveraging true cloud benefits like improved scalability and elasticity.