Partner guide · SteelFrame Modernization
AI does the work. The client approves every stage. The old system proves the new one. This guide gives you what you need to find the right clients and start the conversation.
If you read only one section, read this one.
SteelFrame modernization moves a company's old business system to a modern platform, and proves that the new system behaves like the old one.
Companies that depend on a mainframe, IBM i or older Windows system and cannot afford to get the change wrong.
A modernization is not one long build. It is a programme of stages. Every stage runs the same five steps: Fable 5.2 drafts the plan, the client approves it, AI agents build and test, the old system proves the new one, and the client signs off. Only then is the next stage planned.
The AI never approves anything. The client does, through named people. And nobody has to take the result on trust: the engine runs the old system, runs the new one, and compares the outputs.
One simple cycle, repeated for every stage. Then eleven stage types, in a fixed order, sized to the client.
SteelFrame runs its own quality check before each client step. That check only decides "ready to show the client". It is never an approval.
Small systems can use a compact plan that joins Framework with Tooling, and Hypercare with Close. No plan removes the client's approval or sign-off.
For every stage: the goal, what the client decides, what the client gets, and who on the client side signs.
Know exactly what the old system is before anything is decided.
Approves the spec: Sponsor, IT architect
Signs off: Sponsor, IT architect; Risk for the data policy
Fix the client's decisions, then build and prove the foundation the converted programs will run on.
Approves the spec: Sponsor, IT architect, Risk
Signs off: IT architect, Risk, Operations
Build what every later stage reuses: converters, comparison tooling, data loaders and test environments.
Approves the spec: Sponsor, IT architect
Signs off: IT architect, Business expert
Prove the whole method on a small, representative slice before the client commits to the rest. Measure the real cost.
Approves the spec: Sponsor, Business expert, IT architect
Signs off: Sponsor (go / no-go), Business expert, IT architect; Risk for regulated clients
Take the next group of programs through the same cycle. Repeat until every program is done.
Approves the spec: Sponsor, Business expert, IT architect
Signs off: Business expert, IT architect; Risk for differences on money fields
Show that the new system meets the client's own speed and resilience targets.
Approves the spec: Sponsor, IT architect, Operations
Signs off: Operations, IT architect
The whole system, accepted by the people who will use it and run it.
Approves the spec: Sponsor, Business expert, Operations
Signs off: Sponsor, Business expert, Operations, Risk
Run old and new on the same real inputs, cycle after cycle, and rehearse the move.
Approves the spec: Sponsor, Operations, Risk
Signs off: Operations, Business expert, Risk
Switch to the new system. The client carries it out. The autopilot never touches the client's production.
Approves the spec: Sponsor, Operations, Risk
Signs off: Sponsor, Operations
Stabilise the new system and transfer knowledge to the client's team.
Approves the spec: Sponsor, Operations
Signs off: Sponsor, Operations
Retire the old system and end the programme.
Approves the spec: Sponsor, Risk
Signs off: Sponsor, Risk
Approvals come from named people in five roles. Help your prospect find these people early.
Business owner or budget holder
Every stage budget. Go or no-go. Stop. The list of stages.
Senior user or analyst
The business rules. Differences on business fields. User acceptance testing.
Lead architect or head of development
Technical choices. The foundation and converters. Whether the code is readable.
Head of operations
Batch runs, performance, operational acceptance, cutover and hypercare.
Risk officer, security officer
The data policy. The security mapping. Differences on money fields. The evidence packs.
How the roles work
One person may hold several roles, unless the client's regulatory regime asks for separation. The client sets how many people sign in each role.
| Stage | Approves the spec and budget | Signs off the result |
|---|---|---|
| 1. Assess | Sponsor, IT architect | Sponsor, IT architect; Risk for the data policy |
| 2. Framework | Sponsor, IT architect, Risk | IT architect, Risk, Operations |
| 3. Tooling | Sponsor, IT architect | IT architect, Business expert |
| 4. Pilot | Sponsor, Business expert, IT architect | Sponsor (go / no-go), Business expert, IT architect; Risk for regulated clients |
| 5. Batches | Sponsor, Business expert, IT architect | Business expert, IT architect; Risk for differences on money fields |
| 6. Performance | Sponsor, IT architect, Operations | Operations, IT architect |
| 7. Acceptance | Sponsor, Business expert, Operations | Sponsor, Business expert, Operations, Risk |
| 8. Parallel run | Sponsor, Operations, Risk | Operations, Business expert, Risk |
| 9. Cutover | Sponsor, Operations, Risk | Sponsor, Operations |
| 10. Hypercare | Sponsor, Operations | Sponsor, Operations |
| 11. Close | Sponsor, Risk | Sponsor, Risk |
Eight principles you can say out loud in a meeting.
A stage starts only when the client approves its spec and budget. It ends only when the client signs off.
Named people approve, signed in, each in their role. An AI model can never approve. SteelFrame alone can never approve. Silence is never approval.
The engine runs the old system, captures its outputs and compares them with the new system's outputs. The engine's comparator gives the verdict. No AI model writes it.
Each approval and sign-off is recorded with the person, role and time, tied to exactly what was signed, and linked to the record before it. The result is evidence an auditor or regulator can review later.
No stage commits the client to the next one. The client may stop at any stage boundary and keep everything delivered.
Nothing irreversible happens without a tested rollback. The old system stays runnable until the client signs the Close stage.
A live watch page shows old and new side by side, with the verdicts. The client's own experts can catch a problem early.
Anything that could not be run or tested, and anything an AI model judged, is labelled in the evidence.
The client never signs a blank cheque. They approve a budget for one stage at a time.
Each stage runs as one job with its own budget ceiling. The client approves that ceiling with the spec.
A budget guard warns early, with a forecast, and stops the job at the ceiling. No stage runs uncapped.
A budget can be raised only through a change request the client approves.
Assess gives a price range. After the Pilot, each next budget is worked out from measured costs. The margin for the unknown shrinks as forecast and actual come together.
At every sign-off the client sees what was forecast and what was spent. It is part of the evidence.
The sponsor decides against criteria written before the Pilot ran. Stop is always allowed, and the client keeps every signed deliverable.
For any change, Fable 5.2 drafts the impact: what must be redone and what it adds to the budget. Only the work that depends on the change is redone. The client approves before anything runs.
While the programme waits for the client, nothing runs and nothing is spent.
Two brands sell the same method. The stages, the approvals and the evidence are identical. Only the kind of old system differs.
Mainframe and IBM i
The full plan, with all eleven stages, for regulated clients. The standard plan leaves out the Parallel run unless the rules require it.
Older Windows systems only
The compact plan by default; the standard plan on request. A Parallel run is usually optional. The rollback test always stays.
English-speaking markets. All material is in English.
Be honest about limits. The Parallel run is required when the client names a regulatory regime or the system handles money. A Performance stage is required when the client sets speed targets or names a regime. For Windows systems, automatic conversion does not get everything right in one pass, so the Pilot measures the result on the client's own code before they commit. If part of an old system cannot be run for comparison, the stage spec says so.
Short answers you can give. If a question goes beyond these, bring SteelFrame in.
No. Fable 5.2 drafts each plan and reviews the work. AI agents build and test. The client approves every stage and signs it off. Whether old and new match is decided by the engine's comparison, not by an AI model.
The engine runs the old system and captures its outputs. It runs the new system on the same inputs and compares the two, field by field. A stage passes only when nothing is different and nothing is missing, apart from differences the client has approved.
The client decides what "the same" means: keep a known bug or fix it. Each intended difference is listed and approved by the client. It is then a changed rule, and it is not presented as proven equal.
There is no single up-front figure. The Assess stage gives a price range. Every stage then has its own budget, approved by the client before it starts. After the Pilot, budgets come from measured costs. The client also chooses the commercial model in the questionnaire: a fixed price per stage, or capped time and materials.
The job stops at the ceiling the client approved. The ceiling can be raised only through a change request that the client approves.
Yes, at any stage boundary. They keep every deliverable they signed off.
It depends on the size of the system and on how fast the client can review and approve. The Assess stage produces the proposed list of stages. Please do not promise dates before that.
Named approvers review a short summary before each stage and the report after it. The business expert confirms the extracted rules. The client's users run acceptance testing. Each stage spec lists the client's duties, with dates. Summaries are written for each role, and Fable 5.2 can answer questions about the evidence.
No. The client supplies source code and sample data. The client carries out the cutover. The autopilot never touches the client's production.
The client signs a data policy in the Assess stage. They choose whether tests use synthetic, masked or real data. They also state where source and data may be processed. The first scan of the system is done by the engine alone. AI models start work only after the data policy is signed. If a prospect has strict rules on this, raise it with SteelFrame early.
No. Each new drop of the old source is scanned again. The changes are listed, and Fable 5.2 drafts a change request with its cost for the client to approve.
The client chooses the target in the questionnaire, from the targets SteelFrame supports at that time. Ask SteelFrame for the current list before you discuss a specific platform.
Do not claim that. Say what the process gives: plans and results approved by named business and IT people, approvers who are separate from the builders, a tested way back, and a full evidence pack. For a client that names a regulatory regime, the evidence pack shows which record answers which requirement. That is evidence a regulator can review.
How to open the conversation, what to ask, and how to tell a good fit.
"You depend on a system that is hard to change and risky to replace. SteelFrame modernizes it in small stages. AI does the heavy work, but your people approve every stage and its budget. Your old system proves the new one: the two are run side by side and the outputs are compared. After a pilot you decide: go, re-scope or stop. You can stop at any stage and keep what was delivered."
A drawn explainer, 2 min 52 s long, with captions. It follows a fictional regional bank's COBOL billing system through the stages. Share it with prospects.
The client in the video is an invented example. No real company is shown.
"Claude Agent Designing Framework for AWS Card Demo Modernization - Part 1", 30 min, on our Steelframe by COBOLStack YouTube channel. Open on YouTube ↗