"Lift-and-shift" sells itself as the low-risk option. No rewrite, no reverse-engineering, no parallel-run standoff over what "matching" means — just pick the mainframe workload up and set it down on someone else's infrastructure. Same COBOL, same CICS, same VSAM files, same JCL, now running under an emulator or a hosted mainframe-compatible stack instead of on-premise iron. The pitch is speed and safety: you keep the system you already trust, you just stop paying for the box it sits in.
What that pitch quietly skips is the question that actually matters for a buyer: whose problem was the mainframe supposed to solve, and did lift-and-shift solve it? If the goal was "stop running on hardware we own and maintain," lift-and-shift delivers that, cleanly. If the goal was "get off the treatment that made this system expensive and risky to change" — the COBOL nobody can safely touch, the batch windows that don't shrink, the vendor lock on tooling and skills — lift-and-shift delivers none of it. It moves the same constraints to a new landlord and calls the move modernization.
The system you had, now with rent
The technical reality of lift-and-shift is that almost nothing about the application changes. The COBOL is the same COBOL. The copybooks are the same copybooks. The batch dependencies, the JCL quirks, the undocumented interactions between programs that nobody fully understands anymore — all of it survives the move intact, because surviving intact is the entire selling point. What changes is where the cycles are billed from: capital hardware and an in-house or long-term mainframe services contract becomes a recurring MIPS or capacity charge to whichever provider now hosts the emulated environment.
That's not free. Emulated or cloud-hosted mainframe capacity is priced by the people who built the emulator and it is priced knowing you have exactly one exit option, and it's the expensive one: staying. You've converted a fixed, if aging, cost structure into a metered one controlled by a vendor who understands your switching costs better than you do on day one, because they designed the offer around them.
The exit fee nobody prices at signing
Here is the part that a buyer's own team should be pricing before signing, and usually isn't: what does it cost to leave the lift-and-shift platform once you're on it? Not leave the mainframe entirely — leave this specific host. The answer, structurally, is almost always "about what it would have cost to modernize in the first place, plus whatever premium the incumbent can extract for cooperating with the move," because the underlying COBOL is exactly as opaque and exactly as hard to safely touch as it was before you moved it. You haven't reduced the size of the eventual modernization project. You've added a second migration on top of it — off the platform you're on now, before you can even start the one you originally needed.
That's the exit fee. It doesn't show up as a line item in the lift-and-shift contract, because it isn't the lift-and-shift vendor's job to disclose the cost of your next move — it's structurally in their interest that the next move look expensive enough that you don't make it. A hosting arrangement that is cheaper to enter than to leave is not a neutral fact about the market. It is the business model.
What lift-and-shift is honestly good for
None of this means lift-and-shift is always the wrong call — it is a legitimate answer to a narrower question than the one it's usually sold against. If the actual, near-term problem is a hardware end-of-life deadline, a data-center exit, or a capital budget that can't absorb a mainframe refresh, moving the workload to hosted capacity while a real modernization plan gets built is a defensible bridge. The failure mode isn't the bridge — it's calling the bridge the destination, and letting "we modernized" become the internal narrative once the move is done and the underlying COBOL, and every risk that came with it, is still sitting there unexamined.
The tell is whether lift-and-shift is presented as step one of a plan with a named step two, budgeted and scheduled, or as the plan in its entirety. If nobody in the room can describe what happens to the actual application logic after the move — who owns it, how its behavior gets verified, what the path off the emulator eventually looks like — the move bought a change of address and a new invoice, not a reduction in risk.
The question that separates a bridge from a trap
Before signing a lift-and-shift agreement, ask the vendor directly: what does it cost, in time and dollars, to leave your platform once we're running on it — and will you put that answer in writing? A vendor offering an honest bridge will have a real number, because they've thought about your exit as part of the deal. A vendor offering a trap will reframe the question, point back at how much cheaper this is than "a full rewrite," and avoid naming what leaving actually costs. That evasion is the whole tell. Lift-and-shift can be a legitimate first move. It is never, by itself, the modernization — and a contract that doesn't name your way out is a contract that was never designed to let you have one.