ranked #2 worldwide in product strength · second only to ibm · marketsandmarkets 2026

Field guide · the kit

The Mainframe Modernization RFP Kit

Everything procurement needs to run a serious modernization selection — the RFP skeleton, the 40 questions, the PoC scope, the business case, the board deck. No form, no email wall. Copy what you need.

PalmDigitalz Research · 15 min read · July 2026 · ungated

kit contents

01 · the rfp document skeleton
02 · the 40 questions
03 · the poc scope template
04 · the business case skeleton
05 · the board deck outline

A word on why this exists. Most modernization RFPs are written by the vendors who intend to win them — templates arrive attached to a discovery call, and the questions inside are the ones the template’s author can already answer well. This kit is the counterweight: the document skeleton, questions, and acceptance criteria a buyer would write for themselves if they had run a dozen of these selections. Everything below is selectable text on a public page. Take it.

Use it in whatever order procurement reaches for it: the skeleton if you are drafting, the questions if responses just landed, the PoC scope once a shortlist exists, the business case and the deck when the funding conversation starts. Nothing here requires talking to us first — that is the point of ungated.

kit 01 · the rfp document skeleton · 9 sections

Nine sections, in this order. If your draft is missing one, the gap will be filled later by the vendor — on the vendor’s terms.

§1 · background & estate profile

What you run, in numbers: platforms, languages, program and job counts, data stores, integration surface. Precise counts beat adjectives — vendors price adjectives with contingency.

§2 · objectives & non-goals

What the program must achieve, and — just as binding — what it will not attempt. An RFP without non-goals invites scope theater in every response.

§3 · scope of this rfp

Which applications, which phases, and where this procurement stops. State explicitly whether you are buying analysis, extraction, forward engineering, or all three — and that you reserve the right to stop between them.

§4 · mandatory evidence requirements

The non-negotiables: rule-level source lineage, deterministic reprocessing, in-perimeter operation, artifact ownership. Mark each pass/fail. Anything marked “desirable” will be treated as decoration.

§5 · technical response requirements

The 40 questions (kit 02), answered in writing, in order, with no substitution of marketing material for answers. Set page limits per group to force specificity.

§6 · delivery model & team

Named roles, on/off-shore mix, SME time demanded from your side, and knowledge-transfer obligations. Ask who, specifically, has done this before — and for how long they are committed.

§7 · commercial model

Pricing separated by stage (analysis, extraction, build, cutover), outcome-linked where possible, with re-pricing after rationalization built in. Effort-only pricing points the vendor’s incentives at the calendar.

§8 · evaluation criteria & weights

Publish the weights. Evidence and verifiability should outweigh brand and price — a cheap program that cannot pass audit is the most expensive thing you can buy.

§9 · timeline & logistics

Dates, Q&A windows, submission format, and the PoC gate (kit 03) as the final selection stage. The paper round shortlists; the PoC decides.

kit 02 · the 40 questions · grouped · ask them verbatim

These are working questions, not gotchas. A serious vendor can answer all forty; the value is in how specific the answers are, and how quickly the specifics arrive. Score each answer 0–2: zero for marketing, one for a specific written answer, two for an answer demonstrated on artifacts — and publish that scoring rule in §8 of the RFP, so deflection is visibly priced. The groups are ordered by how early the answer matters: provenance failures poison everything downstream, while commercial terms can still be negotiated in the final round.

provenance & auditability · q-01–q-06

q-01For any extracted rule, show the exact source paragraphs it derives from — program, section, and line span.
q-02Walk one rule end to end: source lines, intermediate representation, extracted rule, target artifact.
q-03When a rule is found to be wrong, how is the error traced back — and how do you identify which other rules share the same fault?
q-04What does your evidence package for an auditor contain? Provide a redacted example from a real engagement.
q-05Can our internal audit team independently reproduce your extraction inside our own perimeter?
q-06What fraction of your output carries lineage — and what happens to the fraction that does not?

accuracy & verification · q-07–q-11

q-07Describe your benchmark methodology: the corpus, how ground truth was constructed, who scored it, and what counted as a miss.
q-08State accuracy as a distribution across programs, not a single marketing number. Where were the worst results, and why?
q-09What accuracy will you commit to contractually, and what is the remedy when you miss it?
q-10How is verification performed — human review, replay against production behavior, generated tests — and at what sampling rate?
q-11Show us a failure: a program your tooling handled badly, and what you changed as a result.

determinism vs probabilistic · q-12–q-16

q-12Run the same program through your pipeline twice; diff the outputs in front of us. Explain any delta.
q-13Where exactly in the pipeline do LLMs or other probabilistic components sit, and what bounds their influence?
q-14Can a probabilistic step alter extracted logic, or only annotate it? Demonstrate the boundary.
q-15When your models are updated, does previously produced output change? How are outputs versioned against pipeline versions?
q-16In your architecture, what is deterministic by construction versus deterministic by testing? Name the components in each class.

scope & dead code · q-17–q-21

q-17How do you identify dead and duplicative code, and what evidence accompanies each kill recommendation?
q-18What scope reduction have you delivered on comparable estates — with the method behind the number, not just the number.
q-19How do you treat code that is unreferenced statically but reachable through dynamic calls, schedulers, or external triggers?
q-20Will your commercial proposal be re-priced after rationalization, or is it fixed against gross line counts?
q-21If we stop after the analysis phase, who owns the estate map and the dead-code report, and in what formats do we receive them?

people & knowledge transfer · q-22–q-26

q-22What do you need from our SMEs, in hours per week, for how long — and what happens when that availability slips?
q-23How does the engagement capture knowledge that currently exists only in people’s heads, before it exits through retirement?
q-24What artifacts remain if the program stops at any gate — and can our team use them without your tooling or your people?
q-25How do you train our engineers to operate, maintain, and extend what you deliver?
q-26What is your on/off-shore mix, your named-key-person policy, and your attrition record on multi-year programs?

security & data handling · q-27–q-31

q-27Can the entire pipeline run inside our perimeter, with no source code leaving? If not, name precisely what leaves and why.
q-28If any component calls an external model or service, name the service, the data sent to it, and the retention applied to that data.
q-29Which certifications and audits cover your platform — and which of them cover the specific deployment model you are proposing to us?
q-30How are our source code and extracted rules isolated from your other customers, contractually and technically?
q-31What happens to every copy of our data at termination? Contractual language, not intentions.

commercials & lock-in · q-32–q-36

q-32Price analysis, extraction, and forward engineering separately, so we can stop — or switch — at any stage.
q-33Which deliverables are in open, documented formats, and which require your tooling to read?
q-34If we changed vendors mid-program, what carries over cleanly, and what would have to be redone?
q-35Is your pricing tied to outcomes — rules verified, applications cut over — or to effort? Show the mechanism.
q-36What does year two look like commercially if the program runs long? Who absorbs the overrun?

delivery & cutover · q-37–q-40

q-37Describe your smallest completed cutover: what moved, how long the parallel run lasted, and who signed the gate.
q-38What is your rollback plan when a parallel run disagrees — and show us one occasion on which it fired.
q-39How do you phase an estate: cohort selection, sequencing logic, and the definition of “done” per cohort?
q-40Provide three references from programs that finished — including one chosen by us from your full client list, not from your shortlist.
kit 03 · the poc scope template · 6 weeks · paid

The proof of concept is the real selection round; the paper round only decides who gets to attempt it. Make it paid — typical market investment is in the $50K–$100K range — because a vendor who will not charge for six weeks of genuine analysis is recovering the cost somewhere less visible. Six weeks is enough for one hard program; it is not enough for theater.

inputs you provide

One production program of your choosing — pick the gnarliest, not the cleanest; something in the tens of thousands of lines with real history. Its copybooks, JCL, and schedule context. Representative data profiles or masked samples. SME access capped at 2–4 hours per week. Perimeter access under your security review.

outputs you must receive

A rules inventory in which every rule carries lineage to its source paragraphs. A dead-code and duplication report for the scope, with evidence per finding. A dependency map covering calls, data flow, and job relationships. A rebuilt module with passing tests, if forward engineering is in scope. All artifacts in formats your team can open without the vendor in the room. Insist on interim artifacts weekly rather than a single week-6 reveal — drift you catch in week 2 is a conversation; drift you catch in week 6 is a verdict.

acceptance criteria — written as measurable statements

•  100% of extracted rules carry source lineage to program, section, and line span.

•  Two independent pipeline runs over identical input produce identical rule inventories, demonstrated by diff in our presence.

•  On a random sample of 50 extracted rules, our SMEs confirm at least 45 as correct against source.

•  On a random sample of 20 dead-code findings, at least 18 withstand SME challenge.

•  Zero source code egress from our perimeter, confirmed by our security team’s monitoring, not the vendor’s attestation.

•  Our audit team can trace one rule of their choosing from inventory back to source, unassisted, in under 30 minutes.

the week-by-week shape

week 1 · ingest  →  week 2 · map  →  week 3 · rationalize  →  weeks 4–5 · extract + verify  →  week 6 · evidence review

what a refusal tells you

A vendor who pushes back on this scope is answering your RFP more honestly than their written response did. Refusing the determinism diff means the pipeline cannot pass it. Refusing lineage means the tooling does not produce it. Refusing your program in favor of “a representative sample we prepare” means the demo estate is doing the heavy lifting. Substituting a slide deck for the week-6 evidence review means the evidence would not survive one. Each refusal is data; collect it and move on.

kit 04 · the business case skeleton · three numbers

A modernization business case needs exactly three numbers a CFO will interrogate. Everything else is supporting schedule.

01 · the run-rate

What staying costs per year, fully loaded: MIPS/MSU and software licensing, people, support contracts, and the risk carry — SME retirement exposure, audit findings, the growing cost of every change request. Trend it forward; the line is not flat.

02 · the exit envelope

The all-in cost to leave: analysis, rationalization, extraction, build, parallel run, and decommissioning — priced after the dead-code report, not before, or the envelope inherits a third of phantom scope.

03 · the break-even

The month in which cumulative exit spend crosses cumulative avoided run-rate. State it as a date, phased by cohort — a break-even that only works if everything cuts over at once is a big bang wearing a spreadsheet.

the risk adjustment

Multiply the benefits line by a probability of success, and say so on the slide. Take the base rate seriously — the failure patterns are documented — then show which controls move your probability away from the base rate: rules provenance, scope rationalization, phased cutover with parallel run. A business case that survives its own risk adjustment is rarer, and more fundable, than one that ignores it.

the sensitivity check

Pressure-test the three numbers before the CFO does: run-rate with and without the next licensing renewal; envelope with and without the dead-code cut; break-even at cohort velocities 25 percent slower than planned. If the case only closes under the optimistic triple, it is not a case yet — it is a hope with formatting.

For the raw inputs, start with the Exit Calculator and the cost breakdown in What an exit costs.

kit 05 · the board deck outline · 10 slides

Ten slides, one job each. If a slide is doing two jobs, split it; if it is doing none, cut it.

slide 1the ask — one sentence, one number, one date.
slide 2the run-rate — what staying costs per year, and which direction it is trending.
slide 3the forcing function — SME retirements, vendor deadlines, the ECC 2027 clock; why “later” is a decision too.
slide 4the failure base rate — and our controls against each pattern.
slide 5the doctrine — read → rationalize → extract → choose → phase; the order is the strategy.
slide 6the portfolio — an R per application, sequenced into cohorts, not one verb for the whole estate.
slide 7the numbers — run-rate, exit envelope, break-even, risk-adjusted.
slide 8the risk register — top five, each with a named control and a named owner.
slide 9the 90-day plan — what we will know by day 90 that we do not know today.
slide 10the decision — approve the PoC, not the program; the program earns approval with evidence.

a note on whose kit this is

We wrote the questions we would want to be asked. Ask them of us too — q-12 in particular, since determinism is the claim our entire engagement model stands on. If any vendor’s answers beat ours on your code, hire them; the kit will have done its job either way. Send us the forty questions whenever you are ready.

keep reading

kit 03 is a working scope · we will sign it as written

Start with the six weeks, not the seven figures.