Pillar · the framework
The Exit Doctrine
The 7 Rs tell you what you could do. A doctrine tells you what to do, in what order, and what you must never skip.
PalmDigitalz Research · 18 min read · July 2026
Every mainframe modernization conversation eventually arrives at the Rs. Rehost or refactor. Replatform or replace. Seven options, arranged in a tidy grid, presented as if choosing among them were the hard part.
The framework itself is fine. It descends from a consulting taxonomy popularized in the early 2010s and extended by the cloud providers since, and as a vocabulary it earns its keep: it gives a steering committee seven words instead of seventy slides. The trouble is that a vocabulary is not a strategy. The Rs name destinations. They say nothing about sequence, nothing about preconditions, and nothing about the one question that decides whether any of them can work. That is what a doctrine is for.
A doctrine, in the military sense the word comes from, is not a plan. It is the set of principles that generates good plans under varying conditions — what you do in order, and what you never do, regardless of terrain. Estates differ: a 900-program insurance core and a 200-job logistics stack will produce very different plans. The doctrine that produces them should not differ, because the physics underneath — unread code, dead scope, undocumented rules, concentrated risk — is the same everywhere.
What follows is ours. It is target-agnostic by construction — nothing in it requires you to buy anything from us, and every tenet can be enforced on any vendor, including PalmDigitalz.
part i
The 7 Rs, honestly
Here is the grid, without a thumb on the scale. Each R is legitimate somewhere. Each one also has a characteristic way of failing — and the failure mode is almost always a missing precondition, not a flaw in the R itself.
| the r | what it is | when it is right | how it fails |
|---|---|---|---|
| retire | Decommission the application. Delete it, archive the data, stop paying. | Nothing depends on it. The function is gone, duplicated, or absorbed elsewhere. | “Nothing depends on it” was an assumption, not a finding — discovered at 2 a.m. on decommission night. |
| retain | Keep it on the mainframe, deliberately, with a review date. | Stable, compliant, cheap where it sits, and not blocking anything downstream. | Becomes the default answer for everything. Deferral compounds: the SME bench shrinks while the decision waits. |
| rehost | Lift-and-shift onto an emulator or cloud infrastructure, code unchanged. | A hard deadline — datacenter exit, contract expiry — where moving the box is genuinely the job. | Relocation gets declared modernization. The COBOL is still COBOL, at a new address, plus emulator licensing. |
| replatform | Recompile or minimally adapt to run on a new platform or middleware. | Meaningful infrastructure savings with a modest appetite for change. | The 80% that recompiles cleanly hides the 20% that does not — and the 20% is where the business logic lives. |
| refactor | Restructure the code itself without changing external behavior. | The application has a future, the language has a future, and the team wants maintainability. | Without a behavioral ground truth there is no baseline to prove equivalence against. “Cleaner” is not “verified.” |
| rearchitect / rewrite | Rebuild the capability on a modern stack from its business rules. | The logic is the asset and the code is the liability — differentiating rules trapped in an aging medium. | Attempted without extracting the rules first. The rewrite transcribes screens and folklore, then meets reality in UAT. |
| replace / repurchase | Move the function to a packaged product, SaaS, or ERP. | The process is commodity. Payroll, ledger, procurement — someone else’s R&D budget maintains it. | Decades of custom rules are discovered during data migration, then rebuilt as “configuration” at consulting rates. |
Notice what the table refuses to say: that any R is simply wrong. Rehost — the option modernization vendors most enjoy sneering at — is sometimes exactly correct; when the datacenter closes in eleven months, physics outranks architecture. What the table does say, seven times over, is that every R fails the same way: it was chosen without the knowledge that makes it safe. The precondition, in every row, is knowing what the code does.
Two of the Rs deserve rescue from their reputations. Retire is the most profitable verb in the table and the least used, because nothing in a program’s incentive structure rewards deletion; nobody was ever promoted for the module they decommissioned. And retain is not surrender — an application that is stable, compliant, and cheap where it sits may be exactly where it belongs for another five years, provided the decision is made on evidence and carries a review date. The failure is not keeping systems on the mainframe. The failure is keeping them there by default, without ever having read them.
The deeper problem is that the grid is usually presented as a menu, and estates do not order like restaurants. The Rs interact. A retire decision changes the dependency surface of everything that touched the retired system. A replace decision for the commodity ledger changes what the rewrite next door must integrate with. Choosing dispositions independently, application by application, without a map of the seams between them produces a portfolio that is locally sensible and globally incoherent — which is why the map comes first.
part ii
The question upstream of the Rs
Ask a simpler question before any of the seven: for how much of your estate could you state, with evidence, what it actually does? Not what the documentation says — the documentation describes the system as it was funded, not as it runs. Not what the SMEs remember — memory is the format with the worst retention policy in the datacenter. What the code, as deployed, does.
You cannot choose a disposition for code you cannot read. A portfolio review that assigns Rs to unread applications is not a strategy session; it is a betting pool with better stationery. And the first thing reading an estate reveals is that a large share of it should never be modernized at all — because nothing runs it.
Analyst estimates commonly put 30 to 40 percent of a typical legacy estate as dead or duplicative — jobs the scheduler retired years ago, copybooks nothing references, whole programs kept alive by habit. Our own numbers agree: Palm Key’s dead-code report cuts modernization scope by 33–40%. Rationalization is the only step in a modernization that pays for itself before the program starts, because every R downstream prices per unit of scope. An estate of 950 inventoried programs and an estate of 631 live ones are two different programs, two different budgets, and two different risk profiles — and only one of them is real.
The second thing reading an estate reveals is where the knowledge actually lives. Documentation drifts from the day it is written; the code does not. Every emergency fix, every regulator-driven patch, every “temporary” workaround from 2004 that became load-bearing — the code holds all of it, and usually holds it nowhere else. The people who could reconcile the two are on a retirement clock that does not pause for procurement cycles. This is the quiet asymmetry of modernization timing: the option value of waiting is negative, because the estate does not merely stay hard to read — it gets harder every year, as the readers leave.
This is why the doctrine below spends its first three tenets before the word “target” appears. The Rs are the fourth decision, not the first.
part iii
The Doctrine
Seven tenets. Each is short enough to survive a steering committee, and each has teeth — a test you can apply to any plan, any vendor, any slide deck, this week.
tenet 01
Understand before you choose.
Map the estate first: every program, job, screen, copybook, and interface, and the dependency web between them. Not sampled, not estimated — enumerated. A disposition assigned to an unread application is a guess wearing a decision’s clothes. The test: if someone proposes an R for an application, ask to see the application’s entry in the estate map. If there is no map, there is no decision — only a preference.
Mapping sounds like a documentation exercise; it is a decision-rights exercise. Once the estate map exists, opinions lose their veto. The application everyone believed was critical shows four callers, two of them dormant. The one everyone forgot sits under the nightly settlement chain. Sequencing arguments that ran for quarters end in an afternoon, because the map is not a viewpoint — it is the terrain.
tenet 02
Rationalize before you count.
Kill dead scope before anyone estimates anything. Every line item priced before the dead-code report exists is inflated by roughly a third, and the inflation compounds through contingency, licensing, and timeline. The test: has a dead-code and duplication analysis been run, and did the scope number change afterward? If the scope survived rationalization untouched, the rationalization did not happen.
Rationalization changes the politics as much as the price. A program scoped at 950 applications is an empire-scale undertaking that attracts empire-scale governance. The same program scoped at 631 live applications is finishable — and finishable programs are staffed differently, gated differently, and believed differently by the board that funds them.
tenet 03
Extract the rules, not the code.
The asset is not the COBOL. The asset is forty years of business decisions encoded in the COBOL — rate logic, eligibility, exceptions, the grandfather clauses nobody wrote down anywhere else. Extract those rules as first-class artifacts, each with provenance back to its source. Translating syntax from one language to another moves the medium and abandons the meaning; a million lines of Java nobody understands is not an improvement on a million lines of COBOL nobody understands. The test: point at any statement of system behavior and ask for the source paragraphs it derives from.
This tenet is where our own conviction runs deepest, so state the standard precisely: an extracted rule is an asset only if it carries provenance — the exact source paragraphs it derives from — and only if extracting it twice yields the same answer. Palm Ark holds both properties by construction. Whatever tooling you use must hold them too, or the rules inventory is just a second document that drifts.
tenet 04
Choose the R per application, not per estate.
“We are a refactor shop” is a vendor’s business model, not your strategy. A real portfolio disposition retires some applications, retains a few, rehosts the deadline-bound, replaces the commodity, and rewrites only what differentiates. One estate, several Rs, each earned by evidence from tenets 01–03. The test: if the disposition matrix assigns the same R to more than about 70 percent of the portfolio, someone chose the answer before reading the question.
Per-application disposition is also what keeps the estate governable mid-flight. When conditions change — a divestiture, a new regulation, a vendor’s product pivot — a portfolio of independent, evidence-backed decisions absorbs the change one application at a time. An estate-wide bet can only be doubled or abandoned.
tenet 05
Never big-bang.
No single date, ever. Move in cohorts, strangle the legacy interface by interface, and run old and new in parallel with reconciliation until the delta is zero — then run it a little longer. Parallel running feels like paying twice; it is the cheapest insurance in the industry, as every entry in our failure library demonstrates from the other side. The test: ask what happens on the day after cutover fails. If the answer involves the word “war room,” the plan is a big bang with extra steps.
The strangler pattern is old advice because it is correct advice: new capability grows around the legacy system interface by interface, and the legacy shrinks until switching it off is an anticlimax. The parallel run is the pattern’s proof obligation — reconciliation reports, not confidence, decide when a cohort is finished.
tenet 06
Keep receipts.
Every extracted rule traceable to its exact source paragraphs. Every transformation logged. Every verification replayable — same input, same output, any day of the week. In a regulated estate the cutover decision does not belong to the engineers or the vendor; it belongs to audit and risk, and they decide on evidence chains, not demos. The test: hand one extracted rule to your audit team and ask them to independently confirm it against source. Time how long it takes. If the answer is “they can’t,” the program has no receipts.
Receipts are also the program’s insurance against its own turnover. Sponsors move on, vendors rotate staff, steering committees forget. A program whose knowledge lives in evidence chains survives its personnel; a program whose knowledge lives in people is one reorganization away from starting over.
tenet 07
The target is a detail.
ERP, cloud-native services, a packaged core, a modern language on commodity infrastructure — all legitimate, and none of them decidable until the rules are on the table. Decide the destination from the extracted rules, per application, and hold it lightly; a rules inventory with lineage survives a change of target, but a target-first program does not survive a change of rules. The test: could you switch targets today without redoing the analysis? If not, the analysis was never yours — it was the vendor’s reference architecture wearing your logo.
Target-agnosticism is a discipline for buyers, not only a property of vendors. The moment a program’s identity fuses with its destination — “the SAP program,” “the cloud migration” — every inconvenient discovery becomes a threat to the program instead of an input to it. Name the program after the exit, not the destination, and the discoveries stay useful.
the doctrine, as a sequence
part iv
Applying it — the first 90 days
The doctrine is deliberately front-loaded: everything that de-risks the program happens before the big contracts are signed. Ninety days is enough to run the first three tenets on a real estate and arrive at the R decision with evidence instead of appetite.
days 1–30
Read
Ingest the estate — programs, copybooks, JCL, screens, schedules — and build the full inventory and dependency graph. No source code leaves your perimeter to do this. The output is the estate map: the first document in the program that describes the system as it runs, not as it was funded.
days 31–60
Rationalize and extract a proof
Run the dead-code and duplication analysis; watch the scope number move. In parallel, pick one program — ideally your gnarliest — and extract its rules with full source lineage. Put the extracted rules in front of your SMEs and your auditors, not your architects. Their verdict is the program’s first real data point.
days 61–90
Decide
Build the disposition matrix — an R per application, each justified by the map, the rationalization, and the extraction evidence. Sequence the cohorts. Only now shortlist targets and vendors, because only now can you evaluate them against your rules instead of their slides.
What to demand from any vendor
Whoever you invite in — integrator, hyperscaler, product vendor, or us — hold them to the doctrine’s tests, in writing, before the PoC:
demand 01 · lineage for any extracted rule, on request, to exact source paragraphs
demand 02 · the determinism check — same program through the pipeline twice, diff the outputs
demand 03 · a dead-code method they will demonstrate, not assert
demand 04 · dispositions per application, each with the evidence that produced it
demand 05 · a phased plan with parallel-run gates — and the rollback that fired last time
A vendor who meets all five will not resent the asking; the asking is how they distinguish themselves from the vendors who cannot. We wrote the full procurement version, ungated, as the Mainframe Modernization RFP Kit — nine RFP sections, forty questions, and a PoC scope template with acceptance criteria written as measurable statements.
Where PalmDigitalz fits, briefly: the platform is the doctrine in tooling form — Palm 360 for the map, Palm Key for the rationalization, Palm Ark for deterministic rule extraction with lineage, Palm Ray for forward engineering into whichever target the rules justify. The method is five stations, in order, every time. But the doctrine stands on its own; enforce it on whoever you hire.
The two standard objections
“This front-loads the program.” Yes — deliberately. Ninety days of reading is the cheapest part of the program doing the job the expensive parts cannot. Every fact the map, the rationalization, and the extraction proof establish up front is a fact that would otherwise be discovered downstream, at delivery rates, with an integrator’s change-order process between you and the correction. Front-loading is not delay; it is buying information at the only point in the program where information is still cheap.
“Our integrator already ran an assessment.” Probably a sampled one, and probably priced to win the build that follows it. Sampling is the tell: an assessment that read 8 percent of the estate has opinions about the other 92. The test is the same one the doctrine applies everywhere else — ask for the lineage. An assessment whose findings cannot be traced to source, program by program, is an opinion with a cover page, and it should carry an opinion’s weight in the disposition matrix.
What the doctrine refuses to promise
No sequencing framework makes a mainframe exit easy, fast, or cheap, and this one does not pretend to. Estates carrying four decades of institutional decisions do not surrender them in a quarter. The claim is narrower, and more defensible: a program run in this order fails early, cheaply, and legibly when it is going to fail — at the map, at the rationalization, at the extraction proof, where stopping costs weeks — instead of failing late and expensively at cutover, where stopping costs careers. The calm way off the mainframe is not the fast way. It is the way that survives contact with your own auditors.
keep reading
tenets 01–03 fit in a six-week proof