OneSourceIT / Software modernization

The worst legacy failure isn't downtime. It's the wrong answer nobody catches.

Modernization stalls on one fear: how do you know the new system is right? My method answers it directly. The old system isn't thrown away — it's sworn in. Every component of the legacy estate becomes a witness, and nothing new ships until it agrees with all of them, exactly.

426+ behavioral tests — green in under 2 minutes Public case study — auditable commit by commit Fixed price · no retainer
The problem

What an aging system really costs

Not downtime — distrust. Three taxes every legacy estate quietly collects:

Tax · 01

The convention tax

Two systems give two answers and there's no referee. Reconciling them takes a week, so the report never gets re-run — and the safe behavior becomes using only one system, which means no independent check at all.

In the case study: five research tools, each with its own sign and mirror conventions. Comparing any two took an expert afternoon — so verification was skipped, because it was expensive.
Tax · 02

The install tax

The job that only works on the old server nobody is allowed to reboot. Reproducing it anywhere else is a project, so nobody does — results travel as claims, not as something anyone can re-run.

In the case study: binary-only distributions and gigabyte dependencies — software that ran on the author's machine and almost nowhere else.
Tax · 03

The bus-factor tax

The module everyone routes around, because the person who understood it left. When a number looks wrong, the recourse is an email to someone who may never answer.

In the case study: single-maintainer engines with opaque internals. The support model was, literally, "email the author."

The cure isn't a rewrite-and-pray. It's a method where the old system supervises its own replacement — which is the next section.

The method

Swear in the old system

Seven steps, in order. The validation harness is built before the new code — so there's always something to be wrong against.

01

Inventory the estate

Every existing component on paper: version, license, install reality, and an assigned role — oracle, witness, interop target, or reference-only.

02

Price wrap vs. rebuild, on the record

Adapter contracts and a migration matrix for the wrapper path; a written decision either way. Wrapping is sometimes right — it's a priced decision, never a default.

03

Build the oracle before the engine

Import the known answers, define the validation schema, make validate-by-default the error policy. No new code until there is something to be wrong against.

04

Rebuild incrementally, gate on agreement

Smallest piece first. Promotion requires an exact known-answer match, an independent-implementation match where one exists, and internal consistency checks.

05

Normalize conventions once

Canonical names belong to the domain, not to any tool. Each legacy spelling maps through a single alignment table.

06

Accelerate behind agreement gates

Optimized tiers must reproduce the reference exactly. Missing hardware is a loud error, never a silent fallback.

07

Freeze and ship

Content-hashed, validated exports — so downstream consumers depend on checked data, not on re-running anything.

What I don't do

  • No big-bang cutover without a gold master. The old system is held as the oracle until the new one proves agreement.
  • No unvalidated number, ever. Under the default policy, it raises an error instead of being returned.
  • No silent fallbacks. A degraded path that reports success is treated as a defect.
  • No heuristic shortcuts in the core. Only exact, answer-preserving optimization; the faithful path stays first-class and runnable.
  • No wrapper-as-destination. I'll call a legacy system to check an answer — never to ship its answer as mine, undocumented.
Proof, not promises

The method, carried all the way through — in public

Case study · public repository

Tetradrome: a generation of research tools, rebuilt as one trusted system

Tetradrome is an open-source Python workbench for computational topology: it computes knot invariants — Khovanov homology, the Rasmussen s-invariant, knot Floer homology — that constrain smooth 4-dimensional topology, the class of numbers behind results like the 2020 resolution of the Conway knot. In this domain, the number is the product: a wrong value doesn't crash anything; it propagates silently into work people cite. Swap "invariant" for "price," "dosage," or "invoice line" and it's the failure mode every business system shares — the error that doesn't announce itself.

The capability existed, scattered across a generation of legacy tools: a Java GUI, a C++ engine shipped only as prebuilt binaries, a gigabyte-scale algebra system pulled in for a handful of functions, single-maintainer codebases — none agreeing with the others without expert reconciliation, and the whole estate license-entangled against the project's goals.

I ran the method above, literally. The inventory. The wrap-vs-rebuild decision, priced and rejected in a written decision record, for four named reasons. The validation harness before the engines: a published 12,967-knot reference table as the known-answer oracle, independent implementations as second witnesses, internal mathematical checks backstopping both. Then the rebuild — smallest engine first, each promoted only on exact oracle agreement, acceleration added last behind the same gates.

One trusted number meant three installs and an expert afternoon of reconciling conventions.
Now it's one call, one schema, validation status attached.
Verification was skipped, because it was expensive.
Now it's 426+ behavioral tests, green in under two minutes, run on every change.
"Fast" meant trusting an opaque binary.
Now every accelerated path has proven exact agreement with the faithful reference — speed without a leap of faith.

Public, in production, Apache-2.0. Where most case studies ask for your trust, this one is a repository — every claim on this page is auditable, commit by commit.

426+
Behavioral tests · green in under 2 min
12,967
Known-answer oracle knots × 244 columns
4 witnesses
Oracle + three independent implementations
185 knots
Full-sweep release gate · exact match required
11+
Written architecture decision records
0
Third-party compute on the answer path
For your IT team

The technical detail, when you want it

The architecture before and after, and the validation machinery — for whoever vets this.

Before — one trusted number = an expert afternoon

Java GUI tool
GUI clicks · no automation
Gigabyte-scale CAS
installed for a handful of functions
Binary-wheel C++ engine
installs almost nowhere
Single-maintainer codebases
support model: email the author
Published tables
copy/paste · no cross-check

↓ all of it reconciled by hand, by an expert — each tool with its own sign and mirror conventions

After — the old estate wasn't discarded; it was promoted to the jury

Any input
name · PD · DT · Gauss · braid
Native normalizer
one alignment table for all conventions
5 native engines
shared exact-algebra core · JIT / multicore / GPU tiers, agreement-gated
Result + provenance
method · version · conventions · validation status
Frozen export
content-hashed · validated
The witness ring: the 12,967-knot KnotInfo oracle plus three independent implementations (Szabó's knot Floer calculator, KnotJob, SageMath) — dashed lines pointing inward: validate, never compute. An unvalidated number raises an error instead of being returned.
  • 5 native invariant engines — the Jones polynomial; Khovanov homology over F2 and ℚ; Lee homology; the Rasmussen s-invariant; grid-homology knot Floer (HFK, signed τ, ε, ν, genus, fiberedness) — plus the classical invariants.
  • Validate-by-default policy — every result carries method, version, conventions, raw output and an explicit validation status; unvalidated results raise.
  • Internal consistency checks (d² = 0) backstop both the oracle and the witnesses.
  • Release gate: all 185 knots through ten crossings, every invariant, exact match required — on every release.
  • Acceleration behind gates: JIT, multicore, optional GPU — every tier reproduces the reference bit-for-bit before any benchmark counts; a missing hardware path fails loudly.
  • The health-check deliverable, in public: the component inventory, backend matrix, wrap-vs-rebuild decision record and validation policy all live in the open repository — the same artifacts a client engagement produces, no redaction required.
$ pytest
426 collected · 423 passed · 3 skipped (no GPU present — skipped loudly, not silently) · 84s

Live run output on a clean sandbox machine — no cached state, no special setup.

The artifact · public

Every claim above is auditable

Tetradrome is public and Apache-2.0 licensed. The decision records, the validation policy, the oracle plan, the test suite — the same deliverables a modernization engagement produces for your system, readable in the open.

View Tetradrome on GitHub All open-source work
Fixed-scope offers

Ready-made ways to start

Each is a bounded project with one price, approved before work begins.

01 · start here

Modernization health check

What the case above began with, produced for your system: the component inventory, the priced wrap-vs-rebuild decision, the oracle plan, and the risk register — before anyone rewrites a line. Each finding carries its own fixed quote.

02

Modernization sprint

A focused piece of work that takes the most painful part of your software and makes it safe and easy to change — gated on agreement with the system it replaces.

03

Move an aging app forward

An old app the business still relies on, moved onto a modern, supported foundation — data and daily workflow intact, with the old system held as the oracle until the new one proves itself.

04

Safety-net testing

A behavioral test suite around the parts that matter, so future changes can't quietly break what already works — the 426-test discipline, sized to your system.

Tell me which system everyone's afraid to touch. Get a fixed price back.

A short conversation is enough to scope a health check — and the quote costs nothing.

Get a fixed quote