By published estimates, most software in service is legacy, and in banking and healthcare systems written decades ago still carry the transactions and the patient records. This film explains why modernising them by hand costs more than anyone will approve, and how GreenCode turns the work into a pipeline that maps, documents and tests the code before refactoring it.
Read the full page Watch on YouTube
Most software in service is already old, and in banking and healthcare the systems written decades ago still carry the transactions and the patient records. They cannot be switched off, and nobody wants to touch them. The reason is structural. Who can safely change this system? One with no documentation, no test coverage, no sponsor, no visible feature to show for the work, and an energy bill nobody in the room is accountable for. Behind it sit the transactions it carries, and the records it holds.
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 has a cost per line, and clearing it has its own price list: the quality assessment, the refactoring itself, the re-testing, the management and contingency on top. For a large open-source database, the estimate comes to a number of developer-years that no organisation funds and no community project has. So the work is not delayed. It is never done. Automating it changes the arithmetic.
GreenCode treats modernisation as a pipeline rather than a project. It accepts a working codebase and first maps it, giving 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. Only then does it refactor: rationalising dead and duplicated logic, replacing deprecated dependencies, porting obsolete languages into supported ones. Every change comes back as a documented pull request with the reasoning attached, so the maintaining team approves the work rather than inheriting it.
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 usually the easiest gain in an estate to find. The same work pays twice: lighter software demands less of the machine underneath it, and a modernised system is 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 goes to the pipeline and the understanding stays in house, because the documentation and the training material are derived from their own code. Automated modernisation of old codebases is one of the deliverables GreenCode will bring out of the project. Reach out to us with the legacy system nobody wants to touch, and we will help you understand how GreenCode can modernise it without a rewrite.
Benefit film
The cost of inefficient software is spread across many budgets, from hosting and energy to incidents, security and lost productivity, so no single line ever shows it.
Benefit film
The ICT sector's emissions are already comparable to aviation's, and they are projected to keep rising.
Benefit film
Every line of code that runs costs electricity, and a computer or server can only be as energy efficient as its software allows.
