Cloud Migration Strategy:
Rehost, Replatform, Rearchitect

We’ve written extensively about the “joys” of cloud migration and cloud migration strategy. We even provide a number of downloadable resources to help the aspirational transition from on-premises hosting to the cloud. A recent project at Webapper brought us back to three cornerstones of cloud migration strategy: rehost, replatform, rearchitect. In this case, a complex, monolithic SaaS application needs to be moved from a data center to AWS. In the near term, the goal is to rehost the application, a lift-and-shift migration to improve performance and set the stage for long-term, sustainable growth. But the roadmap is never a straight line. We’ll be using a combination of cloud migration methods to get the best value and outcome.

When to Rehost

As we described in our “lift & shift” article, often the easiest path is simply to rehost applications. If your application has a decent lifespan ahead, meaning it won’t be retired within a year, it’s a good candidate for rehosting. You move your on-premises applications to the cloud, without making changes. Obviously you won’t be leveraging the full range of cloud benefits, but you’ll be positioned to do so. A key factor on the negative side is potential costs. If you already own your computing equipment, you’ll probably be incurring initially higher costs when you life & shift. Or if you’re leasing, it may be similar.

When to Replatform

Replatforming — “lift-tinker-and-shift” — means moving parts of the application with only minor changes. The application benefits from the new cloud environment and can deliver a better user experience. The “tinkering” involves rewriting some of the application to leverage the cloud better (e.g., databases, scaling). Its important to manage the scope of any development — like a home remodeling project, you can go too far! All changes can impact the user experience (for good or bad), so rigorous regression testing is essential.

When to Rearchitect

Rearchitecting involves revamping old monolithic applications, migrating them to a modern architecture. Legacy applications can be expensive to run and maintain, so rearchitecting can eliminate the time and costs needed to keep them alive. With rearchitecting, large code segments will be rewritten to take advantage of cloud-based features and the flexibility they bring. Refactoring is complex, a resource-intensive process that requires time to complete. When considering all factors, however, cloud-native can enable much lower total cost of ownership. We’ve shared our belief in the strangler pattern, which offers a framework for a gradual approach to rearchitecting a monolithic system. You don’t have to eat the entire frog for breakfast, although eventually you’ll want to finish your meal…

Rehost, Replatform, Rearchitect

Choosing to rehost, replatform, or rearchitect comes after careful evaluation of the lifespan, underlying technology, resources, budget, and timeline. We typically start by classifying the workloads to migrate and identifying dependencies. We must review application source code, have conversations with stakeholders, and discuss issues with developers before we make any assessments. In the end, it becomes a decision between costs and benefits. Can we live with it “as is”? Does a more cloud native approach deliver long-term benefits to justify costs? Or is it somewhere in the middle? Despite our fanaticism for cloud computing, we never force any of these decisions. It’s up to stakeholders to weigh in and then engineers to deliver the solution.