Lift and shift preserves the problem. Re-architecture can create a new one.
Vendors selling migration services have a default answer to the lift versus re-architect question, and it is usually whichever one they are better staffed to deliver. I have sat through enough portfolio reviews, including one that walked an entire Oracle Fusion Cloud ERP migration through exactly this question, to know the honest answer depends on a short list of factors specific to each application, not a blanket policy applied across the whole portfolio.
Treating this as an all or nothing decision wastes money in both directions. Re-architecting a system that has eighteen months of useful life left burns budget that will never be recovered. Lifting and shifting a system that will run for the next decade just moves on-premises inefficiency onto a more expensive monthly bill, and nobody notices until the first full year of invoices lands on the CFO’s desk.
1. Remaining useful life of the application
Before anything else, I ask how long this system is expected to exist in its current form. An application with twelve months left before a planned replacement is rarely worth re-architecting, no matter how clean the target design looks on a whiteboard. A system that will anchor the business for the next five to ten years almost always justifies the investment. On the ERP side, this question alone killed three proposed microservice extractions during planning, because the modules in question were already scheduled for retirement once the new financial reporting module went live.
2. How much the current inefficiency actually costs
Lift and shift preserves whatever inefficiency already exists on-premises, and the cloud bill reflects that honestly. An oversized virtual machine running at ten percent utilization costs real money every month once it moves to a pay as you go model. I pull the actual CPU and memory utilization numbers, usually thirty to ninety days of them, before deciding anything, because the case for re-architecting is much stronger when the inefficiency is measured in specific dollars rather than assumed from a hunch in a steering committee meeting.
3. Dependencies and integration complexity
A system that talks to a dozen other internal applications through tightly coupled, undocumented interfaces is a poor first candidate for re-architecture. The risk of breaking something downstream is high, and the effort to map every dependency before touching the code often exceeds the effort of the rewrite itself. I lift and shift these systems first, then revisit re-architecture once the dependencies are documented and the team has more confidence in the new environment. An ERP integration layer feeding payroll, asset management, and a handful of satellite reporting tools is a textbook case: moving it unchanged and stabilizing it first beats a rewrite that risks breaking payroll in week two.
4. Team capacity and available skill
Re-architecting toward containers or serverless patterns requires a team that already knows those patterns or has real time to learn them. I have seen organizations commit to a re-architecture timeline based on the technology alone, without accounting for the learning curve their own staff would face. A team that is strong in Azure but has never run a Kubernetes cluster in production needs either a CKA-certified hire, a managed service that trades some control for a flatter curve, or three extra months nobody budgeted for. Matching the approach to the team you actually have, not the team the roadmap wishes you had, saves the schedule.
5. Compliance and data residency constraints
Some systems carry regulatory or contractual constraints that limit which cloud services are even available, regardless of technical preference. Public sector and transportation workloads in particular often carry data residency rules that rule out certain managed services outright. I confirm which managed services meet the compliance bar before assuming re-architecture is possible at all. This step belongs early in the decision, not as an afterthought once the technical design is already drafted and the team is emotionally attached to it.
A simple way to decide
When I walk a leadership team through this decision, I score each application against the five factors above on a simple scale. Systems that score high on remaining useful life, measurable inefficiency, and team readiness get prioritized for re-architecture. Systems that score high on integration complexity or carry open compliance questions get lifted and shifted first, with re-architecture revisited later once the dust settles. This is not a sophisticated model. It is deliberately simple, because the goal is to force the conversation to happen application by application instead of as a single portfolio wide mandate handed down from a slide deck, which is where most migration budgets actually go wrong. A system that scores high on both useful life and integration complexity, the hardest case in practice, gets lifted and shifted on a fixed timeline with a re-architecture review date already booked on the calendar, so the deferral never quietly becomes permanent.
Leave a Reply