Migralith //

A modernization service, not a tool. Four gated stages, fixed price each.

How an engagement runs

SOC 2 Type II · ISO 27001 · On-prem & air-gapped

Nobody left understands
the mainframe.
We map it, then move it.

Migralith modernizes systems that have outlived the people who built them. Deterministic analysis for ground truth, agents for the volume, and senior engineers for everything a tool cannot infer.

30 minutes with the engineer who would run it. No deck, no discovery questionnaire.

Which one is yours?

Pick the one that keeps you awake and we will say what an Assessment looks at first.

Reads — COBOL · JCL · PL/I · .NET · Java · Kotlin · TypeScript · Terraform

A developer reading through an unfamiliar source file
ASSESSMENTpayments-core Resolving cross-repo dependencies
Symbols92%
Call graph78%
Subsystems64%
Settlement rule duplicated in 3 services apis/settlement.go · 2 callers outside the module
Needs SME
0.0M symbols resolved · 6 repositories
Deployed where modernization is hardest

The offering

Where we come in

Three engagements, scoped to the places modernization usually fails. Each one opens with an Assessment that fixes the scope, the risks and the success criteria before anyone touches code.

A team gathered around one laptop, working through a problem together
Tuesday, 2:14 AMThe deploy nobody
wanted to approve.

Why this work is hard

Every legacy system has a room
like this one.

Four people awake because a change to a batch job might touch something in a module written before any of them joined. Nobody can say for certain. The person who could left in 2019.

That is the actual problem — not the language, not the framework. The knowledge that would make the change safe was never written down, and no amount of tooling invents it.

  • Undocumented rules recovered from the people who still hold them
  • Blast radius sized before the change, not discovered after it
  • Evidence attached to every stage, so approval is a decision not a gamble

How we do it

Three layers, working together

Static analysis alone misses intent. Models alone invent. Consultants alone do not scale. All three run on every engagement, in that order.

Ground truth

We read the code before anyone touches it.

Our own engine walks every repository and records what is actually there — dependencies, entry points, data flows, dead code, and the relationships that cross repository boundaries. Run it twice on the same commit and the map comes back the same, which is what makes it checkable rather than impressive.

  • 01Dependency and call-path mapping across repositories
  • 02Entry points and data flows traced end to end
  • 03Dead code and duplication identified, not estimated
  • 04Validated with your engineers before anything is proposed
Volume

Models do the repetition, anchored to something that cannot drift.

Agents apply patterns that have already been verified, across however much code the engagement covers. Because they work from the analysis rather than from a sample of the source, the thing that normally breaks at scale — a confident guess about code the model never read — has nowhere to start.

  • 01Verified patterns applied repository-wide
  • 02Every action traceable to the analysis behind it
  • 03One shared system context, not a guess per session
  • 04Progress visible in your workspace as it happens
Judgement

Nothing ships on a best-effort basis.

Engineers who have done this before review what comes out, add the knowledge that was never written down anywhere, and catch the cases no tool can infer. This is the step automated modernization skips, and it is why the output survives contact with the people who own the system.

  • 01Human review on every deliverable
  • 02Undocumented rules captured from the people who hold them
  • 03Edge cases automated analysis cannot reach
  • 04Validation evidence attached to each stage

Engagement model

Modernization without the all-in bet

Four stages, each priced up front, each gated on the evidence from the one before.

  1. 01

    Assessment

    A read on the stack and how well it suits modernization, a scoped plan, the risk list and the success criteria. Useful on its own even if you stop here.

  2. 02

    Specification

    The rules, flows and behaviour your engineers and your agents need in order to change the code safely, extracted and written down properly.

  3. 03

    Modernization

    The scoped change itself — code, services, APIs or migrated work — delivered in stages you can watch rather than wait for.

  4. 04

    Enablement

    Playbooks, training, test suites and a queryable knowledge base, so the system keeps moving after we are gone.

See how each stage is priced

Who you actually work with

Three people, named before you sign

You will know who is on your engagement before the contract does. The same people stay on it through handover.

Three colleagues working through a problem at one laptop
Your engagement teamThe same people, from the
first call to handover.
PE

Principal engineer

Named, not pooled

Owns the engagement end to end and is in the room from the first call. Not a handover from a salesperson to a delivery team you have never met.

AL

Analysis lead

Runs the engine

Drives the deterministic pass, validates the map against your system, and is the person who tells you when the output disagrees with the architecture diagram.

SME

Domain specialist

Mainframe, .NET, Java

Brought in for the stack you actually have. Reads COBOL copybooks or framework-era .NET the way your longest-serving engineer does.

In their words

What the engineers said afterwards

They handed us a map of the application and our own analysts checked it line by line. It held up. Every detail the business side had been asking for was in there.
ED

Executive Director
Mainframe platform, top-five US bank

0M+Lines of code put through the analysis engine
0Gated stages, each priced up front and each useful alone
0Certifications held: SOC 2 Type II and ISO 27001
Sam Davis, Founder & CEO of Migralith

From the founder

We kept walking into the same room: a system everyone depended on, and nobody left who understood it. That is not a staffing problem.

Migralith started because the tools we were handed kept answering confidently and wrongly on exactly the code that mattered most. So we built the analysis first, and only then let the models near it. Every engagement since has been shaped by the engineers who have to live with the result after we leave.

Sam Davis Founder & CEO, Migralith
Connect on LinkedIn

Questions

What teams ask before the first call

A service, delivered by our team. A product powers the analysis and the scale, but what you buy is the outcome — working APIs, a validated knowledge base or migrated code, handed over with evidence. There is nothing for your team to license or adopt.
The deterministic engine maps entry points, data flows and cross-repository relationships before anything changes. That shows where logic actually lives rather than where the architecture diagram says it should, and your engineers validate the map before extraction starts.
It never works from a sample of the source. Agents apply patterns verified against the static analysis, and senior engineers review the output before it ships. Nothing goes out on a best-effort basis.
Fixed price per stage, across four stages, with validation evidence delivered at each one. No open-ended time and materials, and no scope discovered halfway through.
Yes. On-premise deployment is supported, including air-gapped environments, and you can point the engagement at your own managed LLM endpoints. SOC 2 and ISO 27001 apply either way.
That is the Enablement stage. Playbooks, training, test suites and a queryable knowledge base go to your team so the system keeps evolving without us. We are not trying to become permanent furniture.

Start with one codebase

Hand us the application you have been wrestling with

Thirty minutes with the people who would actually run the work. We will tell you which step produces evidence soonest — or that you do not need us.

Book a scoping call