A COBOL85-to-.NET playbook, driven by GitHub Copilot agents.
From a 31-year-old Unisys core to a modern .NET application. The platform, the archaeology, and the build, with agentic AI carrying the work from first reading to validated code. A 90-minute session, 40 of them on the technical core.
Why a core that works perfectly is the real risk.
Inside a Unisys ClearPath MCP estate, and the COBOL within it.
Intent over syntax. Seven agents, gates and evidence.
Archaeology, architecture, build, evolution, on CIBS.
Data, coexistence, scope, decommissioning.
Part 00 opens with the executive summary and Part 06 closes with the decision; between them, the five technical parts below. Each part carries its own color through the deck. Press O at any time for the full overview, N for speaker notes, F for presenter view.
Three slides for the people who decide. The situation in plain terms, the cost of waiting, and what we recommend. The technical chapters that follow prove every claim made here.
Contoso National Bank runs on a core banking system that has performed flawlessly for three decades. Its reliability is not in question. What is in question is whether the bank can still change it, and for how much longer.
Read those last two numbers together. The system that runs the bank is understood by three people, and the person who understood its database has already left. The risk is not failure. The risk is that the knowledge walks out the door while the platform ages out of support.
Doing nothing is a decision, and it has a price that rises over time. Two separate clocks are running, and they do not stop on their own.
The rules that run the bank live in COBOL written over thirty years, much of it undocumented. Every retirement takes some of that understanding with it. Once the last person who knows why a rule exists is gone, the rule becomes a fact nobody can safely change.
The Unisys ClearPath MCP environment is supported, but the talent pool shrinks every year and the hardware and licensing costs do not. The longer the core stays, the fewer people exist who can operate it and the more it costs to keep running.
The instinct is a big-bang rewrite, and that instinct is how core modernizations fail. Large rewrites of running systems have a long history of overrunning and being cancelled, because a clean cutover of a system this size is close to impossible and the undocumented rules surface only when something breaks. The answer is not a bigger rewrite. It is a smaller unit of change.
A modernization that cannot fail catastrophically, because it never bets the whole system at once. Three principles make it safe, and the rest of this deck shows each one working on the real estate.
Carve the core into domains and modernize one, end to end, before touching the next. The blast radius of any step is a single context, never the bank.
The modern code must reproduce the legacy result exactly on the same accounts, proven before anything is switched. A one-cent difference is a failure.
GitHub Copilot agents do the reading, specifying, and proving, enforced by a spec-driven pipeline. The veterans are amplified, not replaced.
The ask: CAP
CIBS has run since 1994 without losing a cent. And it is the single largest risk on Contoso's technology balance sheet. This is the legacy dilemma.
Contoso National Bank, a United States regional commercial bank founded in 1962. Its Core Information and Banking System, CIBS, in production since 1994. The scenario is fictional; the shape of the pressure is real.
The system runs, but almost no one alive fully knows why it works. That gap, between a system that runs and a team that understands it, is the entire problem.
A legacy system earns trust the slow way, by not failing. The instinct to leave it alone is correct, right up until the day it must change.
A system that runs flawlessly but that only three people can touch is not stable. It is fragile in a way that stays invisible until the day it is not.
You cannot verify a rewrite of a system you never understood. If you do not know what the old program did in a rare case, you cannot confirm the new one does the same. You have traded one black box for another that merely looks modern.
Decades of rules, regulatory tweaks and corner-case fixes live inside the code. A rewrite re-derives a design no one remembers, from code optimized to run, not to be read.
Large all-at-once rewrites consistently overrun or fail outright. The root cause is almost always lost undocumented logic, not the code or data layer itself.
A single undocumented constant, the Basis Factor, has shaped 16 years of interest. A faithful rewrite copies it perfectly, bug and all, and no one would know.
Both are real and sometimes useful. Neither closes the gap between a system that runs and a team that understands it.
Rehost the system as it is on cheaper or cloud infrastructure, unchanged. Valid, sometimes the right first move.
Stalls because: it changes where the system runs, not how well it is understood. The undocumented logic travels with it.
Point a code tool at the COBOL and ask for modern code. The output may even compile.
Stalls because: generated code for behavior you cannot specify is unverifiable, in exactly the corner cases that matter most in banking.
Read and understand the legacy first. Extract rules into reviewable artifacts. Specify, build, and prove behavioral equivalence.
Works because: it operates on intent and structure, which every system has.
The hardest asset to migrate is not the code or the data. It is the knowledge in people's heads, and that is a clock, not a static risk.
Instead of rewriting and hoping the meaning survives, first recover it in a form a human can review and a machine can check. Only then build, in slices, never one risky leap.
Extract business rules into explicit, reviewable artifacts. Catalog what you cannot explain.
A modern specification in EARS that a domain expert can confirm. Each rule traced to a requirement.
Build against the spec. The portable COBOL core converts cleanly; the proprietary surface is re-platformed deliberately.
Run legacy and modern on the same real accounts. The new behavior must match the old, to the cent.
The legacy keeps running the whole time. You replace it in slices, a pattern with a name: the Strangler Fig. This reframe is the spine of the agentic method, and it is why the method moves cleanly from a Natural and Adabas estate to a Unisys one. It operates on intent, not on the syntax of any one language.
You cannot read a building's wiring without knowing the building. The mainframe is a city, your application is one building in it. This part draws that line, then shows that the COBOL inside is still COBOL.
These priorities explain why banks still run them, and why they feel unfamiliar. CIBS mirrors this shape exactly: an online side by day, a batch side by night, a database woven through both.
Uptime measured against decades, not quarters. The machine is engineered to never lose a transaction, and the bank's trust is built on that record.
Huge volumes of transactions during the day, large batch jobs at night. CIBS accrues interest, posts fees and cuts statements for 4.7 million accounts each night.
The data store is a first-class citizen of the operating environment, not bolted on beside it. On MCP that database is DMSII, woven into the platform itself.
Hold that shape. Everything in CIBS, the daytime online path, the nightly batch, and the database between them, follows directly from these three priorities.
The ClearPath family has two separate lineages that share neither operating system, database, nor language dialect. CIBS runs on Libra and MCP, the Burroughs descendant, and this playbook targets it throughout.
Mentioned only so you can recognize it. Its tooling substitutes for the MCP tooling at every turn.
The more COBOL-centric line, with the most mature modernization paths, including published Azure reference architectures.
Both run COBOL, and the COBOL core is standard in both. Everything around it differs entirely. Scoping starts by confirming which line you are on.
MCP is the operating system at the heart of the Libra line. Around it sits a set of system software you will meet in the CIBS estate. You need enough to recognize each one and know which modern capability it maps to.
Four of these you read your application through: DMSII, WFL, COMS, and the compiler. They become a relational database, a job orchestrator, and REST endpoints in the modern target.
A great deal of confusion in mainframe modernization comes from mistaking the city for the building. Draw the line clearly, and you know what is yours.
Your application is almost never the only one on the host. That fact is small now and decisive later: it is why you do not modernize "the whole MCP" at once.
The single most useful lens in the playbook. Unisys COBOL85 is based on the ANSI X3.23-1985 standard. What is proprietary is a finite, bounded set of couplings. Learn to see the seam.
This makes reading faster, estimating more honest, and modernizing tractable. A developer who reads COBOL anywhere can read most of a CIBS program with no Unisys knowledge at all.
One picture of the whole estate. The environment that schedules and connects the work, the database at the boundary, and the COBOL business logic that does what the bank actually does. Modernization moves the logic, replaces the boundary, and retires the city.
The proprietary surface is the city and the boundary: COMS, WFL, the MCP, and the DMSII access verbs. The portable core is the building: the arithmetic and control flow inside these COBOL programs. The seam between them is where the anti-corruption layer goes, and the Interest and Fees slice begins with INTCALC.
The surface is not an open-ended unknown. It is enumerable. You do not guess at it, you map it.
FIND, STORE, MODIFY, LOCK, transaction statements and their ON EXCEPTION handling. Conceptually embedded database access.
Target: relational access through an ORM.
Headers, agendas and message areas the program uses to converse with the online transaction monitor.
Target: an API and application host.
SDF and SDF Plus constructs for manipulating the forms and screens that tellers see.
Target: a web user interface.
Directives at the top of source, written with a leading dollar sign, that control how the program compiles. No standard COBOL equivalent.
Target: build configuration.
Add one environmental fact, not a syntax: data representation. The Burroughs heritage means EBCDIC encoding and a specific way COMP numerics map onto the machine. It rarely changes how you read the logic, but it matters enormously for fidelity when you migrate data and translate calculations.
The yellow lines map to relational access in Parts IV and V. The green lines translate to C# almost line for line. The trap: WS-BASIS-ADJ sits in the portable core, trivial to translate, yet carries the heaviest semantic risk in the estate.
DMSII is the data heart of CIBS, its schema written in a language called DASDL. It does not map cleanly onto the relational model that modern tools assume, and knowing where it resists is half the migration.
A filing cabinet whose folders are pre-threaded together with physical cross-reference strings, versus a spreadsheet that looks relationships up on demand. The DMSII audit trail becomes the bridge during coexistence, in Part 05.
Batch and online are the two ways work reaches a COBOL program on MCP. They are different worlds, and the modern target splits them into two clean responsibilities.
Compiles programs, sequences jobs, and runs the nightly streams. Its role is comparable to JCL on other mainframes. The CIBS end-of-day stream is EODRUN: it runs the COBOL programs in order, including the interest accrual program INTCALC, each reading and updating DMSII. No teller is involved; the bank's books are being closed.
The online transaction monitor. A teller submits a request through an SDF screen, COMS receives it and routes it to the right COBOL program, which reads or updates DMSII and sends a response back. This is the path POSTTRAN takes. COMS manages the message flow through headers and agendas.
WFL is the night-shift run sheet. COMS is the switchboard for daytime calls. Holding the two apart is what lets you modernize each into the right modern shape.
The method operates on intent and structure, which every system has, not on the syntax of any one language. That is why it moves from a Natural and Adabas estate to a Unisys one unchanged.
Translating a novel versus reprinting it in a new font. All three are valid in their place, and a real estate uses a mix. The question is which one each workload deserves.
Lift and shift onto cheaper or virtualized infrastructure, unchanged. The fastest move, lowest risk to behavior.
Changes where it runs. The undocumented logic travels with it untouched.
Automated COBOL-to-C# translation, such as the Avanade AMT path. The portable core converts mechanically.
Changes the language. Stops where domain redesign begins, the rules are still implicit.
Recover the rules, redesign into a modern architecture, and prove equivalence. Intent and structure as the unit of work.
Changes how well it is understood. The only tier that recovers meaning.
Where automated conversion stops, domain redesign begins. CIBS is the strategic core, so it deserves Tier 3. Other workloads on the Contoso host may rightly stay at Tier 1, a scoping decision in Part 05.
Four agents do the core moves; three more harden the highest-risk steps: a specifier that makes the rules explicit, a critic that attacks the plan, and a verifier that proves equivalence. Model routing matches the work: deep reasoning for discovery, design, and critique, fast iteration for build.
Reads COBOL85, DMSII and DASDL, WFL and COMS. Surfaces the business rules and the scars, including the Basis Factor.
Gate: discovery report.
Turns discovered behavior into an explicit EARS spec with an equivalence target, before any code exists.
Human gate 1: spec reviewed.
Carves bounded contexts, designs the modular monolith and the anti-corruption layer, records ADRs.
Gate: design drafted.
Attacks the spec and the design. Demands the proof on risky retirements, cites INC-001 on the Basis Factor.
Human gate 2: design approved.
Generates the .NET 8 code from the approved spec. Fast and cheap; the thinking already happened upstream.
Gate: builds and unit-tests pass.
Proves the modern code matches the legacy to the cent. Eleanor accrues 16.63 on both sides.
Human gate 3: increment accepted.
Captures lessons, runs coexistence with the Strangler Fig and the DMSII audit trail, prepares the next context.
Gate: reconciliation holds.
The three additions are not overhead. The specifier makes the rules explicit so nothing is lost, the critic catches what one model misses, and the verifier proves equivalence. AI amplifies the COBOL and DMSII veterans, it does not replace them.
An executable spec instead of a verbal instruction. The agent executes what is written, not what you imagined. The spec is the handoff artifact between stages.
"Modernize the interest module."
"Reimplement INTCALC's accrual for DDA, SAV and TD."
Formal requirements, acceptance criteria, test contracts, ADRs, each traced to a legacy rule.
The seven agents and their gates. The spec drives execution end to end.
Spec-driven development is a good idea that most teams cannot keep. Specky is the tool that enforces it: a CLI toolkit that installs into GitHub Copilot and turns the method into a state machine the AI cannot shortcut.
Spec-Kit is the open methodology: EARS notation, the gated pipeline, the constitution model. Specky reimplements it as enforceable MCP tools, so the same discipline a human could follow by hand is now checked programmatically, requirement by requirement. Repository: github.com/paulasilvatech/specky.
The AI is the operator. Specky is the engine. The model's reasoning is channeled through a validated pipeline instead of producing unstructured guesswork.
The state machine blocks phase-skipping: you cannot jump from Init to Design without completing Specify. At three points the pipeline pauses for a human to reply LGTM. These are the same three gates the seven-agent method already places.
Every phase produces a traceable artifact. The requirement at Specify maps to the design, to the task, to the test, to the code. Nothing is orphaned, and the audit trail writes itself.
Specky has a modernization path built in, and it maps one to one onto the journey this deck describes. The seven cognitive agents do the thinking; specky enforces the phases and produces the artifacts.
This is why the method is not a slide-ware idea. From the COBOL scan to the pull request, every step is a tool call with a gate, an artifact and a trace back to the legacy rule.
Live, on the real estate. Read the rules, catalog the mystery, carve the contexts, translate the code, and prove it ties out to the cent before anything ships.
Before the demos, one map. The seven agents are the cognitive roles, the way a team divides the thinking. Specky's ten phases are the enforced steps. Each role does its work inside specific phases, so the demos you are about to see are not loose; every one of them lands on this pipeline.
The three LGTM gates fall at Specify, Design, and Tasks, exactly between the roles: the spec is reviewed before the architect designs, the design is approved before the builder builds. The agents do the work; specky decides when a human has to look.
The agent finds what the documentation does not have. The Basis Factor is in no manual, and read-only archaeology surfaces it as a first-class finding before anyone proposes a change.
The signature symbol of undocumented legacy risk. The team is afraid to remove it. The discipline is to trace it fully before you ever cut it, then retire it safely.
A one-line comment dates it to ~2009 and cites a memo nobody can find. No regulatory basis, no documented business reason. It has quietly shaped interest for 16 years.
REQ-CALC-002 retires the buried literal into a versioned, auditable rate-parameter table. The behavior is preserved exactly, then made visible, dated, and reviewable.
The unlabeled wire in an old fuse box. You trace it fully before you cut it. Cataloguing the mystery, rather than guessing past it, is exactly why archaeology is a stage of its own.
Before any code is written, the Basis Factor stops being a line of code and becomes REQ-CALC-002, an explicit requirement with an equivalence target a human can inspect and approve. This is the trust boundary between what was understood and what will be built.
From the extracted rule to a testable spec and a recorded architecture. The Basis Factor stops being a buried literal and becomes a named requirement, REQ-CALC-002, that a domain expert can review.
Every model has blind spots. The critic attacks the spec and the design, and on the Basis Factor it does the one thing that matters: it cites INC-001 and refuses to retire the literal until the equivalence proof exists. It runs on a different model so its blind spots are not the architect's.
Domain-driven design on a core ledger. Each context owns a clear slice of the domain. A modular monolith, not microservices: one deploy, six modules, clean internal boundaries.
Drawing municipal district lines so each service owns its own streets. The boundaries come from the rules the archaeologist extracted, not from the legacy program structure, which is exactly how you avoid the distributed-monolith trap.
The CIBSDB schema does not map one-to-one onto tables. Four structures need deliberate handling, and numeric fidelity is non-negotiable in a ledger.
The direct case. Each DMSII data set becomes a relational table with typed columns and a primary key.
An embedded data set, a record nested inside another, becomes a child table with a foreign key to its parent.
DMSII sets and subsets are access paths. They become indexes, and pointer navigation becomes set-based queries.
Variable-format records that change shape by record type are split into a table per type, preserving every variant.
Fidelity. COMP numerics and EBCDIC encoding must carry over exactly. Eleanor's balance and accrued interest are computed and stored so that the legacy and modern systems agree to the cent. Rebuilding a hand-threaded filing system as indexed tables, without losing a single cross-reference.
Code generated from the spec, looping with the tests until the equivalence test passes. The old and new calculator must agree, to the cent, on the same receipt. The Basis Factor becomes a test, not a production surprise.
Behavioral equivalence is the heart of the method, and the verifier owns it. The modern service must reproduce the legacy result to the cent on the same accounts. Eleanor accrues the identical 16.63 on both sides, the edge cases hold, and only then can the literal be retired.
No big bang. Scaffolding a building while the tenants keep living in it, with both floors always in sync. The DMSII audit trail and a change-data-capture feed keep the legacy and modern systems consistent through coexistence.
A clean .NET build is not the finish line. Data migration, coexistence, honest scope, and a decommissioning path are what carry a real bank project from a working slice to a retired mainframe.
What decides whether a real bank project survives contact with reality. Schema modernization and data migration are distinct, and coexistence keeps the legacy and modern systems consistent the whole time.
Derive the relational model from DASDL: data sets to tables, embedded to child tables, sets to indexes, variable-format to table-per-type. This is design work, done once, reviewed in ADRs.
Databridge and the DMSII audit trail feed a change-data-capture pipeline, for example Azure Data Factory. The legacy keeps writing; the modern store stays current. Validate equivalence at full volume, not on a sample.
Scaffolding a building while the tenants keep living in it. Coexistence is not a phase to rush; it is the safety mechanism that lets you replace the core without a single risky leap.
CIBS is the strategic core inside a larger Contoso MCP estate. You do not modernize the whole host at once. You place each workload on the right tier and sequence the portfolio.
CIBS. Recover rules, redesign, prove equivalence. Where the differentiating value and the worst undocumented risk live.
Rehost or convert workloads that work and rarely change. Move them off the platform without a full redesign.
Some workloads stay on MCP until their slice is ready. The host keeps serving the tenants you have not moved yet.
Only when the final workload has a proven replacement does the mainframe switch off. The end state, not the opening move.
Renovating one strategic building while the rest of the block stays occupied and serviced. Treating "the mainframe" as synonymous with "my application" leads to wildly wrong scope. The application estate and the whole MCP environment are two different things, and only one of them is your project this year.
The portfolio is sequenced, not attempted at once. Each wave is chosen so that the riskiest, highest-value knowledge is captured first, and every wave reuses the pattern the previous one proved.
The context that holds the Basis Factor. Highest knowledge risk, clearest equivalence target, bounded scope. Proving Eleanor's 16.63 here proves the whole method.
High volume, well understood, and downstream of interest. With the pattern proven, these scale the approach and build the team's fluency with it.
The system of record, modernized last because it is the most connected and the least urgent to change. By now the anti-corruption layer and the coexistence pattern are routine.
Some workloads on the Contoso host, the rarely-changed regulatory reports and the loan origination module, may rightly stay where they are at a lower tier. Modernization is not a mandate to move everything; it is a discipline for moving what matters, in order.
The method is proven on the page. What remains is a decision: where to start, what it takes, and what we need from you to begin.
The first slice is not chosen for ease. It is chosen because it retires the most dangerous knowledge risk while being small enough to prove completely.
This sequence means the bank is never exposed to a big-bang cutover, and the hardest-to-recover knowledge is captured as an explicit, tested specification first.
The figures below describe the shape of the investment, not a quote. They are the kind of commitment a single bounded context requires, sized to be approved and delivered inside a normal planning cycle.
A small team pairing the COBOL and DMSII veterans with .NET engineers, the GitHub Copilot and specky pipeline, and a quarter per context. The veterans are essential, not optional; the agents amplify them and capture what they know as specifications.
For each wave: a context retired from the mainframe, its rules captured as tested specifications, the platform and licensing cost for that workload removed, and an audit trail that proves the modern behavior matches the legacy to the cent.
The return compounds. The first wave is the most expensive because it builds the pattern, the anti-corruption layer, and the team's fluency. Every wave after reuses all three.
Nothing here requires betting the bank. It requires committing to a first slice and to the discipline that makes it safe.
Approve these three and the first discovery run can start this quarter. The deck you have just seen is the method; this is the beginning of the work.
Recover the intent, specify it, build against it, and tie out to the cent. The platform changes; the discipline does not.
The honest answer to both questions is the same: do not trust the model, trust the gates and the proof.
Performance and cost are measured per wave, before cutover, never promised on a slide.
Waiting is not neutral. It is the most expensive option on the table, paid invisibly.