Legacy systems are most of the world's software and the hardest to change. GreenCode maps them, generates the tests and documentation they never had, and returns modernised, reviewable code instead of a multi-year rewrite.
Between 60 and 80 per cent of all software in service is legacy code, and the share is highest in sectors such as banking and healthcare, where systems written decades ago still carry the transactions and the patient records. These are the systems that cannot be switched off, and they are the ones nobody wants to touch.
The reason is structural rather than technical. Maintenance is risky, it adds no visible features, and it rarely has a sponsor. A change to a system with incomplete documentation, no test coverage and no living author can break something that matters, so the bare minimum gets done and the rest is deferred. Refactoring purely for sustainability is even harder to justify, because the payback is an energy bill nobody in the room is accountable for. The problem is not that engineers do not want to modernise legacy code. It is that doing it by hand costs more than anyone will approve.
Technical debt in existing systems has been estimated at about $3.61 per line of code, so a million-line application carries roughly $3.61m of it. Clearing that debt manually has its own price list, drawn from CAST's research and other industry estimates: quality assessment at $0.50 to $2.50 a line, the refactoring itself at $3 to $8 a line, re-testing at 10 to 15 per cent of the refactoring cost, and project management and contingency adding another 10 to 20 per cent. Independent measurement of manual refactoring puts it at 3 to 5 euros per line or more, which is the same order of magnitude.
Take a real open-source database of about 7 million lines, running in at least 47,000 known deployments. It carries around $26.5m of technical debt and, at the European grid average, its installed base accounts for roughly 16,000 tonnes of CO2e a year. Clearing the debt by hand would take about 254 developer-years, or 51 developers working for five years. No organisation funds that, and no open-source project has that labour available. The work is therefore not delayed. It is never done.
Automating it changes the arithmetic. Evidence from refactoring studies suggests that about a quarter of a typical codebase undergoes change, and that refactoring for efficiency yields energy improvements of 10 to 30 per cent, with 23 per cent a reasonable central value. Applied to that same database, a 23 per cent saving avoids in the region of 3,700 tonnes of CO2e a year across the installed base, every year, for as long as the improved version is deployed.
View full sizeGreenCode treats modernisation as a pipeline rather than a project. It accepts a working codebase and first maps it, indexing the source line by line into a searchable index, identifying interfaces and endpoints and producing a software bill of materials. That gives a current picture of a system whose documentation stopped being true years ago.
It then fills the gaps. Where unit tests, in-code comments or external documentation are missing, generative AI writes them, so that any later change can be verified rather than hoped over. Static analysis against recognised quality, security and green software criteria produces a machine-readable list of what needs attention, and a measured baseline records how the system behaves and what it costs to run before anything changes.
Only then does it refactor. Specialised models rewrite the code that the analysis and the benchmarks implicate, including outright modernisation: rationalising dead and duplicated logic, replacing deprecated dependencies, and porting code from obsolete languages into currently supported ones. Every change comes back on a branch as a documented, reviewable pull request, with the reasoning attached, so the maintaining team approves the work rather than inheriting it. Quality, security and error-rate scores are re-checked at each pass and must not regress.
Old systems were written when processor time was cheap and energy was invisible. They run continuously, they are replicated across many installations, and nobody has ever profiled them. That combination makes them the largest available pool of avoidable energy use in software, and the reduced energy use that follows is usually the easiest gain in an estate to find.
The same work pays twice. Lighter software demands less of the machine underneath it, which is one of the main levers on device lifetimes and on the embodied carbon of replacing hardware that had nothing wrong with it. A modernised legacy system is also cheaper to change next time, because it arrives with the tests and documentation it should always have had.
For a CTO, modernisation stops being a rewrite proposal that gets refused and becomes routine maintenance with a reviewable output. For the team, the mundane part of the job is automated and the understanding stays in house, because the documentation and training material are derived from their own code. Automated modernisation of legacy codebases is one of the deliverables GreenCode will bring out of the project.
To trial the tools on a legacy system or contribute a use case, get in touch through the contact page.
