Skip to content
CodeHero

dozens of migrations

Java, Python, COBOL and VB6 rewritten into Go, Rust and TypeScript in 30 days

Not only the mainframe. A Java monolith spread over eight servers, Python that ran into the GIL, a Node service that eats memory faster than it serves requests — those become Go and Rust, and the infrastructure bill drops with them. COBOL on z/OS, RPG on the AS/400, VB6 and Delphi on the desktop, ColdFusion and PHP on the web, Perl, PL/SQL, Fortran and ABAP as well. Our platform reads the whole codebase and rewrites it, our engineers take the parts where being wrong is expensive, and the old system keeps running the entire time.

Get a quoteTalk to an engineer

Four screens, about ten minutes. An engineer reads it and comes back with a scope, a date and a price — no demo, no sales sequence.

30
days, the ceiling on any project
20
legacy stacks we migrate
10+
years inside other people's systems
1M+
lines in a single rebuild

Every system we take off life support

Dozens of migrations, across every stack below — from a Java monolith burning eight servers to COBOL nobody has compiled since 2011. Every one of them ships inside thirty days. Pick yours and see what the move involves.

One real dependency graph

This is a Go service running in production, with the package names replaced by M01 to M45 and the structure left exactly as it is. Drag the scrubber to run it from how the code sits today to how it comes apart along domain boundaries. The class on each node comes out of the graph itself: a module that lives inside one domain gets rewritten mechanically, and one that four domains hold on to needs an engineer to cut the boundary by hand.

As it sits today

Mechanical rewrite60%

Boundary cut by an engineer29%

Deletion candidate11%

45 modules, 167 dependencies and 45,990 lines across 7 domains. Real graph from a service in production, package names removed, no other edits. The three classes are counted from the structure of the graph itself.
The same graph as a table
Sorted by size. A module is mechanical when it sits inside one domain, it goes to an engineer when three or more domains depend on it or it sits in a cycle, and it becomes a deletion candidate when nothing imports it and it is not an entry point.
ModuleLinesImported byImportsDomainClass
M01326loc010S01Mechanical rewrite
M02142loc03S02Mechanical rewrite
M0355loc03S02Mechanical rewrite
M0489loc03S02Mechanical rewrite
M055,194loc315S03Boundary cut by an engineer
M06239loc51S03Boundary cut by an engineer
M07884loc200S03Boundary cut by an engineer
M08485loc46S03Mechanical rewrite
M099,835loc47S03Boundary cut by an engineer
M10514loc20S03Mechanical rewrite
M11677loc15S03Mechanical rewrite
M12236loc411S03Boundary cut by an engineer
M13187loc33S04Boundary cut by an engineer
M14454loc11S05Mechanical rewrite
M1558loc31S05Mechanical rewrite
M16356loc42S05Mechanical rewrite
M17247loc42S05Mechanical rewrite
M1859loc31S04Boundary cut by an engineer
M19139loc00S04Deletion candidate
M20330loc132S04Boundary cut by an engineer
M21414loc11S06Mechanical rewrite
M221,670loc33S06Mechanical rewrite
M231,218loc180S06Boundary cut by an engineer
M242,574loc153S06Boundary cut by an engineer
M25163loc41S04Boundary cut by an engineer
M26251loc25S04Mechanical rewrite
M27161loc12S04Mechanical rewrite
M2899loc20S04Mechanical rewrite
M2945loc00S04Deletion candidate
M3025loc00S04Deletion candidate
M311,417loc240S04Boundary cut by an engineer
M3282loc10S04Mechanical rewrite
M3330loc41S04Boundary cut by an engineer
M34141loc31S03Mechanical rewrite
M3579loc11S03Mechanical rewrite
M363,036loc310S03Mechanical rewrite
M37173loc11S03Mechanical rewrite
M382,501loc19S03Mechanical rewrite
M391,452loc34S03Mechanical rewrite
M4050loc11S03Mechanical rewrite
M412,148loc09S01Deletion candidate
M42167loc01S01Deletion candidate
M434,873loc215S07Mechanical rewrite
M442,241loc110S07Mechanical rewrite
M45474loc213S07Mechanical rewrite

under the hood

A million lines is the normal size of the job

Our platform reads the whole codebase at once — every language in the tree, in parallel — and rebuilds it as a modern system rather than a transliteration of the old one. Behaviour is held to the original and checked against your own recorded traffic. Architecture is not: you get services, a real schema and a deploy that fits how software is written now.

  • Every language in the tree, at once

    Systems are never one language. COBOL calls JCL, JCL drives a C utility, a Perl script fixes the file before PL/SQL loads it. The platform parses all of it in parallel and holds one graph across the whole thing, which is why nothing falls out at the seams between languages.

  • Fewer machines for the same load

    A Java or Python service rewritten in Go usually needs a fraction of the memory and a fraction of the instances, and a Rust kernel turns a batch window into a coffee break. That is the whole reason to move code that is not broken: the same behaviour on a smaller bill, and headroom you no longer have to buy.

  • A million lines and up

    That is the size we plan around, not the ceiling. Above it we split the estimate and price the first part on its own. Scale is a scheduling question here, not a feasibility one.

  • Same behaviour, new architecture

    A parity harness replays your recorded production traffic against old and new and compares to the cent. What changes is the shape: services with owners, a schema you can read, tests that came with the code, and a deploy that does not need a change window.

  • Air-gapped, on your hardware or ours

    For regulated work the models come from us and run inside your perimeter with no outbound connection at all. If you do not have machines that can carry them, we rent you ours and they sit on your floor. Nothing about your code has to leave the building.

Your cloud, your data centre, a client VPN, or a room with no network at all — every one of these has a working setup, and the specifics go into the contract.

What we take on

Eight pages, because this work gets bought under eight different names. We take all of them, and the job underneath is the same one.

How the work runs

Four stages, the same on a million lines of COBOL as on a PHP monolith. The first two are the assessment, and the map is yours either way.
  1. 01

    Read access

    A read-only copy of the repository, the build scripts, and whatever runbooks survived. We sign your NDA first if that is how your company works.

  2. 02

    The map

    The platform parses all of it and reports what is actually there: modules and their dependencies, code nothing calls any more, scheduled jobs nobody documented, and the place where the build only works on one machine. This lands before any rewriting starts.

  3. 03

    Rewrite in slices

    One bounded module at a time, with tests written against the behaviour of the original. Old and new run on the same inputs until the outputs match, then traffic moves. Nothing gets switched over on a single date.

  4. 04

    Handover

    Your engineers get the repository, the tests written along the way, and the map kept current. We answer questions afterwards, and we hold no keys you cannot revoke.

Ask for the map first

The map is the cheapest thing we sell and the only sound basis for pricing the rest. Tell us what you are running and we come back with what is inside it, what a rewrite takes and what it costs.

The form goes to us, not into a sales sequence. You do not have to sit through a demo to get an answer.

Get a quote