Why we started Stratamend
Stratamend was founded in Singapore in January 2026 around a simple observation: the systems that move money, pay claims and run public services are some of the oldest software still in production, and the people who can safely change them are getting harder to find every year.
Reuters estimated in 2017 that around 220 billion lines of COBOL were still in use. Much of that code sits next to Java applications written in the Java 5 and Java 6 era, wrapped in integration layers that nobody wants to touch. These systems are not broken. They are reliable precisely because they have been left alone. The problem is that leaving them alone is no longer an option when regulators, customers and product teams all expect change.
Why modernization keeps failing
Most organizations we talk to have already tried at least one modernization approach. The patterns repeat:
- Big-bang rewrites take years, freeze new features and often fail to reproduce what the old system actually did. The specification was the code, and the rewrite team did not have time to read all of it.
- Automated transpilers produce code that compiles but that nobody wants to maintain. COBOL translated line by line into Java is still COBOL, just harder to read.
- Lift-and-shift moves the problem to new infrastructure without changing who can maintain the code.
The underlying issue is the same each time. Modernization is a very long chain of reading, understanding, changing and verifying, and every step needs care. Humans do it well but slowly. Tools do it quickly but without understanding.
Why now
Coding agents changed the economics of that chain. An agent such as Claude Code can read a large repository, edit many files, run the build and the test suite, read the failures and try again, without a person approving every keystroke. That loop is exactly what migration work consists of.
What agents do not have on their own is a safe environment to work in. Turn an agent loose on a core banking system and you will get changes nobody can verify. The interesting engineering problem, and the one we started Stratamend to solve, is building that environment: tests that pin down the legacy behaviour, boundaries that keep agents in scope, and a review process that leaves people in charge of every merge.
What we are building
Our plan has three phases, and we intend to ship them in order with design partners:
- Atlas and test harness. Map the codebase, find the business rules buried in it and record what the system actually does as golden-master tests.
- Supervised migration. One Claude Code agent migrates one module at a time and opens a pull request only when every golden test passes.
- Parallel fleet. Many agents working in isolated git worktrees, with audit logs that a risk team can read.
What we will not do
We will not ask anyone to trust an agent blindly. No agent we build will be able to merge code. Every change will come with the evidence behind it: the tests it ran, the diff, the reasoning and the session log. And we are designing the platform to run inside our customers’ own cloud accounts, because for a regulated institution, sending source code to a third party is often a non-starter.
We are an early-stage company, and we will use these notes to share what we learn as we build. If you have a legacy system you want to modernize, we would like to hear from you.