You run a bank or insurer and hit the same bind. Product and operations need a modern loan or policy status experience in the digital channel. The core system of record still holds the official balances, history, and compliance logic.
Service teams still pull every update from that core. Continuity of those transaction workloads is non-negotiable. Business continuity for overnight processing is part of the same constraint. A full rewrite of the core is not on this quarter’s agenda.
You do not need to replace the whole platform to move. One clear capability next to the core is enough: status lookup, case updates, or service workflows that today live in older screens, overnight file dumps, or knowledge only a few people hold. The core keeps the transactions and compliance logic it already owns. The new capability owns a defined business process with acceptance criteria operations can verify against what the core already shows.
That loan-status pattern is how most mainframe modernization programs should start. Decades of business logic, compliance rules, and transaction history sit inside the core systems your operations team depends on every day{1} (often built on COBOL, Assembler, or PL/I on z/OS and related mainframe platforms, with pockets of Java on surrounding services, and sometimes IBM i in midrange estates). This is a core-platform decision about official records on mission-critical systems, not generic legacy modernization, and not the same modernize-versus-rebuild call you make for ordinary applications or other legacy systems.
Skills gaps on these platforms are real. Specialists{1} are scarce. Overnight processing windows cannot slip. New work has to match live results. Those constraints force path and commercial structure to lock together around a named capability next to the core, not a vague “modernization program.”
Example: Loan Status Without Rewriting the Core
Loan status is that finish line in practice: a named capability next to the core, not a platform rewrite. When “done” is measurable, that scope belongs in fixed-fee territory.
Write the finish line in three lines operations can check:
- Which status views must work
- Which data must match what the core shows
- Which production behavior proves the capability is live without breaking overnight processing or day-to-day control
unosquare locks that scope, price, and definition of done before build begins, then delivers a working prototype in week one under the same 8–12 week outcome-based model. The broader roadmap can wait.
One owned status capability your team can run without the partner in the room beats waiting for permission to replace the whole core.
Loan status is one slice. The same three-line structure applies to any capability next to the core. It only holds when the path matches how much of the core can move.
Choosing the Right Path: A Business View
The loan-status finish line only works when the path matches three constraints:
- Which transaction workloads move first
- How much day-to-day disruption the core can absorb
- How much control you keep while the core stays in the loop
A core system that holds official records does not get a generic “modernize or rebuild” answer. Match the path to those business priorities first, then choose who will execute it.
| Path | In plain terms | Disruption | Timeline feel | When a CEO picks it |
|---|---|---|---|---|
| Rehost | Move workloads as-is to a modern cloud host without rewriting how the business rules work | Low | Shortest first move | Continuity of the core matters most, and new capabilities can wait |
| Replatform | Keep the same core logic, but run it with cleaner connections for new work next to it | Moderate | Moderate | You need the core and new work to coexist, with better deployment options, without a full rewrite |
| Refactor | Improve the structure of selected modules while behavior for the business must stay the same | Medium to high | Longer | You want modern structure for selected modules without rebuilding the whole core |
| Rebuild | Replace selected workloads with new software designed for how the process should run now | High | Longest for that slice | Selected workloads can leave the core, and you need room to redesign the process |
| In-place / phased | Wrap the core and replace modules in stages while the core stays live | Variable by phase | Phased | A full switch of the core is not feasible; each phase needs its own acceptance gate and budget gate |
Use this table as a business filter for path selection, not a technical mandate. A loan-status capability next to the core usually starts with a lift, replatform, or in-place/phased move. Rebuild enters only when a selected workload can leave the core entirely.
Hybrid architectures are common here: the core stays where it is, while APIs and microservices expose status without a full rewrite. Hybrid cloud integration connects those services to the core. Some teams also evaluate AWS Mainframe Modernization tooling, Microsoft Azure, or a Google Cloud landing zone as hosting options; others run container platforms such as OpenShift next to the core. Those are environment choices, not the finish line.
Board and private equity mandates create real deadlines around risk, cost optimization, and control of the core. Digital transformation pressure shows up the same way: a named channel capability, not a multi-year core rewrite. Contracts that pay for defined results meet that pressure with accountability that holds even when timelines need adjustment.
Choose the path. Settle price, scope, and what “done” means before the build begins.
When that choice is still unclear for loan status, week one proves the path against the core.
Not Sure Which Path Fits? Week One Answers That.
Path, price, and “done” only lock when the chosen approach survives contact with your actual core. A working prototype in week one, built against your actual core workloads, confirms the choice before you commit build budget. For loan status, that prototype shows status lookup and case updates matching the core without a rewrite.
What Outcome-Based Contracts Actually Settle
After week one proves the path, the contract still has to buy that loan-status outcome, not hours near the core. Commercial structure must match what the path means for the core. Moving overnight processing to a new host is not the same “done” as shipping a loan-status workflow next to it. Restructuring a module is not the same acceptance bar as rebuilding a selected workload.
Paying for defined results changes accountability. The partner is accountable for production-ready software that meets objective acceptance criteria against the core. Payment releases only when a phase deliverable is accepted, not when the calendar turns.
unosquare structures modernization work in four phases. The loan-status example is the proof pattern running through each one. This is mainframe modernization as a scoped outcome, not a staffing or managed services retainer around the core.
Week 1 (Discovery): Choose the path next to the core
Discovery maps which workloads stay on the core and which capability moves first, then delivers a working prototype against your actual core system. For loan status, that prototype shows status lookup and case updates matching the core without a rewrite.
Where COBOL modules must keep the same business behavior, discovery names that constraint in plain language. Generative AI can help inventory those modules and surface automated refactoring candidates; any code conversion still has to meet the same-behavior bar operations can verify against the core. Estates still running under Micro Focus or similar COBOL tooling follow the same finish-line test.
You leave week one with three usable outputs:
- A path recommendation executives can review with operations
- Draft acceptance criteria tied to outcomes the core can prove
- A risk list for overnight processing windows and match checks against live results
No build commitment is required. The question is which path fits this workload and what “done” looks like for the capability next to the core.
If cloud computing options are on the table (including AWS for a rehosted slice, or Linux and Kubernetes for services that sit beside the core), they appear as hosting choices inside the path recommendation, not as the outcome itself.
Week 2 (Solution Architecture): Settle path, price, and “done”
Path, design, and fixed fee lock together before the build begins. The statement of work names the status views or workflows in scope, how data must match the core, and which FORGE decisions are already written into acceptance language. Scope changes move through a formal change order before they touch core workloads.
unosquare writes price, scope, and definition of done into the same document so both sides sign the same finish line. Builds start as low as $100K, scoped before code is written.
Weeks 3 to 11 (Build): Prove results match at each gate
Working software arrives on a steady release schedule. Each milestone validates behavior against criteria tied to the core, not just a cleaner interface: match reports, overnight-processing compatibility checks, and live demonstrations operations can sign off.
Progress stays tied to the path chosen in week two. If a loan-status view must match core balances and history, that match proof is part of the accepted deliverable at each gate, not a final-week surprise.
Week 12 (Deploy and Handoff): Own the outcome your team runs
Handoff is a defined transfer event. You receive full source code and ownership of where that code lives, operating guides your team can follow, test materials that prove results match the core, and access credentials for the modernized capability. Control of remaining core workloads stays with you throughout.
Where security and compliance requirements apply, the accepted deliverable set includes penetration testing (a security test of the system), SOC 2 aligned controls (independent security and process checks), and compliance deliverables. Your team can run, update, and extend the modernized capability without calling the partner back. If a fixed-fee build takes longer, that cost remains with unosquare.
Those four phases stay predictable only when FORGE is settled before money moves. That is the loan-status finish line, written into the contract.
FORGE: Five Points to Settle Before You Build
The loan-status path only stays honest when five decisions are settled before anyone writes code against the core. Each letter keeps path, price, scope, and “done” aligned for the capability next to the core, not for a platform-wide switch.
Run them in the same conversation as path selection and the loan-status prototype review, while acceptance language is still being written.
unosquare settles each point before build begins.
| Letter | Checkpoint | What gets settled |
|---|---|---|
| F | Finish defined | Objective, testable “done” for the chosen path, not progress language |
| O | Ownership transfer | Legal and day-to-day control of modernized components; core stays with you |
| R | Release on acceptance | Payment follows verified deliverables, not calendar time |
| G | Genuine production readiness | Volume, coexistence, and security proof next to the core |
| E | Evidence of delivery | Named track record for comparable work next to the core |
Choose the path, settle these five, and the engagement stops reading like a multi-year program with no finish line. Start with finish defined: what “done” means for loan status against the core.
F: Finish Defined
For the loan-status slice, name four things ops can verify before the build starts:
- The status views in scope
- Proof that status matches the core
- Overnight-processing behavior that must hold
- Who signs acceptance
unosquare writes those measurable acceptance criteria into the statement of work before build begins, including same-behavior language for converted modules, named sign-off authority, and the APIs the status views depend on. Once finish is defined, the next question is who runs that capability after handoff while the core stays yours.
O: Ownership Transfer
A finished loan-status capability that only the partner can run is not a finished outcome. The contract should name what moves in business-readable terms:
- Software
- Hosting setup
- Credentials
- Operator documentation
- Test materials that prove results match the core
unosquare settles who owns the intellectual property (or holds it in escrow), a documented handover plan, and full disclosure of third-party licenses that could constrain future changes next to the core. Ownership without payment gates still leaves the engagement on calendar time, so release has to follow acceptance against the core.
R: Release on Acceptance
If ownership is settled but payment still follows elapsed weeks, the loan-status finish line softens under schedule pressure. Scope changes move through a formal change order before they touch core workloads.
unosquare ties payment to objective acceptance gates and carries cost if a fixed-fee build runs long. Accepted increments still have to prove production readiness next to the core, not only that the demo looked clean.
G: Genuine Production Readiness
Accepted milestones mean nothing if loan status only works in a walkthrough. For work next to the core, prove three things where they apply: volume thresholds, overnight-processing compatibility, and security testing{2}. A loan-status workflow that works in a demo but breaks status matching under production volume has not met the bar.
unosquare delivers penetration-tested, SOC 2 compliant systems with HIPAA-ready practices (health-data handling standards) where regulated workloads require them, plus a handoff package your team can operate without losing day-to-day control of the core.
Production readiness claims still need evidence of delivery on comparable work next to a core system.
E: Evidence of Delivery
Production readiness next to the core is easier to trust when the partner has shipped comparable slices before. Named case studies, quantified outcomes, and client references in regulated industries make a path decision easier to defend.
unosquare brings sixteen years of engineering discipline, 2,500+ completed projects, and a client NPS in the top 1% of B2B services, with delivery history on scoped 8–12 week engagements comparable to your slice next to the core.
With FORGE settled against a loan-status finish line, the remaining question is whether outcome-based delivery fits your situation.
When Outcome-Based Delivery Fits
FORGE only matters when the outcome next to the core is already nameable. Loan status is the common first move because the acceptance criteria are concrete. If that definition still needs clarity, discovery against the actual core is the right starting point.
It fits when the deadline is real. Boards and private equity sponsors with hard commitments around risk, cost, or control of the core need contractual accountability that holds when timelines slip. Modernization directives with fixed board dates are where this structure creates the most value. Digital transformation mandates that name a channel outcome fit the same pattern.
It fits when internal capacity to manage the build is limited. If you lack the bandwidth or the scarce specialists for core transaction systems, the delivery partner should own delivery and hit defined milestones. You should not have to become a project manager of the core to receive what you paid for.
Mainframe modernization services that sell open-ended managed services around the platform miss that finish-line test; outcome-based delivery buys a named slice you own.
It also fits when a previous program needs a clearer path to finish, or a vendor engagement needs a cleaner restart. An independent review of the current build state, focused discovery to redefine acceptance criteria for the core, and a re-scoped fixed-fee engagement can restore a clear finish line without forcing a complete restart of the core.
Generative AI and agentic AI tooling can accelerate discovery and documentation on COBOL-heavy estates, but they do not replace the FORGE finish line or ownership transfer.
When control of core-backed workloads is the primary concern, ownership of the modernized capability is the strategic argument. Builds start as low as $100K, fixed fee, scoped before code is written. Full code ownership removes ongoing partner dependency on that slice and gives your organization permanent control over the roadmap while the core stays under your governance.
Fit still gets confirmed the same way the path did: against your actual core in week one.
What the Free Prototype Proves for Path Selection
FORGE only holds when week one proves the path against your actual core. The first week of any unosquare engagement produces a working demonstration of the chosen modernization approach, built against your actual workloads and acceptance criteria, before any financial commitment to the build phase.
The prototype gives procurement three things it can use:
- Acceptance criteria for outcomes the core can prove, signed by the right decision-makers
- A baseline assessment of the path next to the core
- A preliminary scoped cost estimate
Those deliverables flow into contract talks. Legal, security, and finance get something concrete to review before a build is approved.
For leaders who need board-level evidence before committing budget against the core, the prototype is that evidence. A scoping call aligns goals and defines prototype scope. The prototype lands in week one. Then you decide whether to proceed to a fixed-fee build.
No build commitment is required at the prototype stage. That is the low-risk next step before path, price, and FORGE lock together.
One Week. A Working Demonstration Against Your Core Workloads.
The prototype is the proof point for path selection next to your core. Before you commit to a build, you can have that working demonstration in hand. Path, scope, price, and what “done” means settle only after it is accepted. See how the week-one prototype works. No commitment required.
Frequently Asked Questions
How is scope settled before code starts, and who owns scope creep risk?
Scope for the chosen path settles in the Solution Architecture phase, after the working prototype is accepted in Discovery. By then, “done” is written as specific deliverables tied to the core, acceptance criteria, and measurable performance conditions, and the fixed fee is tied to that definition.
If scope needs to change after signing, every change is documented, priced, and approved before it touches core workloads or the build. Scope creep risk sits with the delivery partner, not with you.
What makes outcome-based delivery different from a standard outsourcing engagement?
Payment is tied to accepted path deliverables, not to time logged or effort reported near the core. Milestones trigger payment only when specific, agreed deliverables are accepted against criteria tied to the core. The contract defines what “done” means for the chosen path before development begins.
If a fixed-fee build runs long, that cost belongs to the delivery partner. That difference changes who carries the risk on a timeline commitment.
How do we modernize the core without a multi-year program?
Sequence the work. Identify the highest-value core transaction workloads first. Settle a clear path and outcome for each. Put phase gates between them while the core keeps running. A loan-status capability next to the core is often the first clear move. That is still mainframe modernization; it is just bought one owned slice at a time.
Moving workloads as-is can be a short, discrete phase. Improving selected modules or rebuilding them into smaller microservices can be separate, independently scoped engagements next to the core.
Week one produces a working prototype that validates the approach before the build begins. That structure keeps each engagement short, testable, and accountable. Teams evaluating AWS Mainframe Modernization as a host option still settle FORGE the same way: finish defined, ownership transferred, payment on acceptance.
Is 8–12 weeks realistic for a project of our complexity?
For scoped, well-defined core workloads, yes. The 8–12 week window covers the full engagement: week-one prototype, week-two path and price agreement, build through weeks 3–11, and handoff in week 12. It applies when Discovery confirms exactly which slice of the core is being built and on which path.
Lift and replatforming slices can often fit that range. Larger module-improvement or rebuild roadmaps are sequenced as separate, independently scoped engagements so the program does not become one open-ended transformation. The Discovery prototype in week one is the earliest point at which a realistic timeline can be confirmed.
What do we own at the end of the engagement: code, data, infrastructure?
Everything built for the modernized outcome next to the core. At handoff, you receive the full source code, hosting setup, operating guides your team can follow, test materials, and access credentials for that work. Control of remaining workloads on the core stays with you throughout.
There is no SaaS licensing model that keeps the partner in the loop, no ongoing dependency on the vendor to keep the modernized software running, and no restriction on how you extend or modify the codebase. The contract specifies the transfer explicitly. Escrow provisions and automatic transfer triggers protect these assets if the vendor relationship changes before handoff is complete.
That ownership test is what separates outcome-based mainframe modernization from a managed services arrangement that keeps the partner in the loop forever.
If your roadmap needs a clear first move instead of another open-ended transformation program, unosquare can scope the outcome next to the core, prototype the path, and settle FORGE before the build starts. Request a free prototype to see what loan-status or service workflows look like against your actual core systems before you commit to delivery.
References
- English, J. (2024). Modernizing mainframe applications with a boost from generative AI. IBM.
https://www.ibm.com/think/topics/generative-ai-for-mainframes - National Institute of Standards and Technology. (2026-07-08). Recommended minimum standards for vendor or developer verification (testing) of software under Executive Order (EO) 14028 – Background & approach. NIST.
https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/recommended-minimum-standards-vendor-or-0
Our Editorial Standards
unosquare is committed to providing accurate, well-researched B2B software delivery information. Our editorial team reviews all content for accuracy and relies on reputable sources including industry analysts, technology standards bodies, academic institutions, peer-reviewed research, and established enterprise software providers. All references are verified for accessibility and relevance at the time of publication.
We strive for accuracy in everything we publish, but we recognize that mistakes can occur and information can become outdated as delivery models, pricing benchmarks, and technology standards evolve. If you notice an error or outdated information, please contact us so we can review and update our content.
Important Disclaimer
The information provided on this website is for general informational and educational purposes only. It is not intended as, and should not be interpreted as, professional legal, financial, or technical implementation advice. Always consult with qualified technology advisors, legal counsel, or appropriate professionals before making decisions about software investments, vendor selection, or delivery models. unosquare does not assume liability for actions taken based on the information presented on this site.
