Lift and shift, or modernize in place?

Most mainframe modernization programs begin with a question that has already narrowed the answer. Someone asks whether to move off the platform or stay on it, and from that point the conversation is about destination rather than about the problem anyone was trying to solve.

Slowing down at that point is worth the delay, because the two paths fail for completely different reasons, and the failure modes are not symmetrical.

What the two words actually mean

Lift and shift, properly called rehosting, means moving the workload off z/OS onto commodity infrastructure without rewriting the business logic. The COBOL is still COBOL. It runs under an emulation layer or a recompiled runtime on Linux, usually in a cloud account. Data moves from VSAM and DB2 for z/OS into something else. Schedulers, security, print and file transfer all get replacement components.

Modernizing in place means leaving the workload on z/OS and changing the way it is built and released. Source control moves from a legacy SCM to Git. Builds and deployments run through a pipeline. Test coverage gets created where there was none. Observability arrives. The code is refactored where refactoring earns its cost, and left alone where it does not.

These are two of a larger set. Replatforming, full rewrite, replacement with a package, and encapsulation behind APIs are all live options, and most real programs end up combining several. But these two are where the argument usually happens, so they are the two worth being precise about.

---

The case for lift and shift

It attacks the line item the CFO can see

Mainframe software is licensed against capacity. That cost is visible, recurring, and easy to point at in a budget review. No amount of improved release velocity shows up in the same place on the same page. If the pressure driving your program is financial, rehosting is the only one of the two options that directly addresses it.

The business logic survives

This is the genuine appeal, and it is often underrated by people who dislike the approach. Decades of encoded rules, edge cases and regulatory behavior do not have to be rediscovered and rewritten. The thing that took thirty years to get right keeps running.

The operational talent pool widens

Once the workload runs on Linux in a cloud account, the people who keep it running are drawn from a much larger market than the one for z/OS systems programmers. That is a real and durable advantage, and it gets more valuable every year.

It ends a vendor relationship

For some organizations this is the actual objective and everything else is justification. It is a legitimate goal. It is just worth being honest internally that it is the goal, because it changes how you should evaluate the result.

The case against

You have changed the floor, not the house

After a successful rehost you have the same application, with the same structure, the same undocumented behavior and the same release process, running somewhere else. If the complaint that started the program was that releases take a quarter, that complaint survives the move intact. Nothing about running on Linux makes a codebase easier to change.

Proving equivalence is the actual project

The migration is not the hard part. Proving that the new system does exactly what the old one did, across every path that matters, is the hard part. Most estates of this age have thin automated test coverage, so the evidence has to be built before it can be used. Teams that skip this discover the gaps in production, which is the most expensive place to find them.

The dependencies are not in the application

The COBOL is rarely what stops a rehost. The scheduler is. So are the security model, the file transfer estate, the print subsystem, the reporting chain, the disaster recovery arrangement, and the two interfaces nobody documented because the person who built them retired. Every one of those needs a replacement, a test and an owner.

Performance behaves differently

Mainframes are built around I/O throughput and transaction integrity in ways that do not transfer automatically. Workloads that were comfortable inside an overnight batch window can become uncomfortable, and the discovery usually happens late, during parallel running, when the program is already committed.

Lock-in can simply change shape

An emulation runtime is a dependency too. Some organizations exit a mainframe vendor relationship and acquire one that is smaller, less mature and harder to leave. That is not an argument against rehosting. It is an argument for reading the second contract as carefully as you read the first.

The risk is concentrated

Incremental delivery is difficult here. At some point a cutover happens, and the amount of change landing at that moment is enormous. Good programs mitigate this with long parallel runs, which are expensive, because for that period you are paying for both platforms at once.

---

The case for modernizing in place

It fixes the complaint people actually have

Ask a CIO what is wrong with the mainframe and the answer is rarely about the mainframe. It is that a change takes a quarter, that testing is manual, that nobody finds out what broke until production. Those are properties of the process, not the platform, and they can be fixed without moving anything.

Risk stays incremental

There is no cutover event. Each release train moves to the new way of working on its own schedule. If something is wrong, the blast radius is one application, and the previous approach is still there. A program that has to be paused for two quarters because of a merger or an audit can be paused without losing what it built.

You keep what the platform is good at

Transaction integrity, I/O throughput and availability are not incidental features of z/OS. Organizations that stay have usually concluded that reproducing those characteristics elsewhere costs more than the license they were trying to avoid.

Nothing needs re-certifying

In a regulated environment the runtime, the controls and the evidence chain stay as they are. Your auditors are looking at the same platform they signed off last year. That is worth a great deal, and it is usually absent from the business case for moving.

It makes the platform hireable again

Engineers do not refuse to work on mainframes. They refuse to work with a legacy SCM, manual promotion and no test feedback. Put the work behind Git and a pipeline and the job becomes recognizable to someone who has never seen a green screen.

The case against

The license bill does not move

This is the honest limitation. Capacity costs continue. If your program exists because of that number, in-place work will not satisfy the person who commissioned it, however much better the delivery gets.

You still need mainframe people

A smaller number of them, working in better conditions, but the dependency remains and the market for those skills keeps tightening. In-place modernization improves your position without removing the exposure.

It is a quiet answer to a loud question

A board that has approved a transformation program wants a headline. "We kept the mainframe and improved the pipeline" is harder to present than "we moved to the cloud", even when it is the better decision and the cheaper one. This is a real political cost and pretending otherwise helps nobody.

If the plan is to leave, spend needs framing carefully

Investment in a platform you intend to exit invites the question of whether it was wasted. It is not, for reasons the next section covers, but the question will be asked and the answer should be ready before it is.

---

The thing that resolves most of this

The two approaches are usually presented as alternatives. In practice, the in-place work is a prerequisite for doing the other one safely.

Consider what a rehost requires. A complete inventory of what you have. A dependency map showing what breaks if a component moves. Automated tests that can prove the new system matches the old. A repeatable build and deploy. Observability good enough to compare two systems running in parallel.

Every one of those is exactly what in-place modernization produces. An organization that has done the in-place work can evaluate a move on evidence rather than on a vendor's estimate, and can execute it with a fraction of the risk. An organization that has not done it is being asked to migrate an estate it cannot fully describe, and to prove equivalence it has no way to measure.

You cannot safely move what you cannot inventory, and you cannot prove a migration worked without the tests you never wrote.

This reframes the sequencing question. It is not whether to modernize in place or lift and shift. It is whether to do the first before deciding on the second, and the answer is almost always yes, because the work is not wasted in either outcome.

Four questions that decide it

• What is the pressure? Cost, delivery speed, operational risk, or skills availability. Each points somewhere different, and programs that cannot answer this cleanly tend to drift toward whichever option the loudest vendor is selling.
• What does the business case assume? Look for the emulation license, the parallel running period, the test estate that has to be built, and the replacement components for scheduling, security and file transfer. If those are missing, the number is not a number yet.
• Can you describe the estate today? If nobody can produce a current inventory and dependency map, that is the first project regardless of which path you take.
• What is the reversal cost? For in-place work it is close to zero and the artifacts stay useful either way. For a rehost it is very high after cutover. That asymmetry should weigh more heavily in the decision than it usually does.

Where we land

We work on both, and we have no incentive to prefer one, because we do not resell platforms or runtimes.

What we would say is this. The industry has spent years framing the decision as a destination, and destinations make poor first questions. The organizations that get the best outcomes start by making their current estate legible and their current delivery fast, then decide where it should run with far better information than they had at the start. Some of them move. Some of them find that the reason they wanted to move has gone away. Both are good results.

The bad result is committing to a two year migration on the strength of a business case nobody could verify, and discovering in month fourteen which of its assumptions were wrong.