Legacy software modernization for companies in Germany

When nobody dares to touch the software

Legacy software is software a company depends on and can no longer change with confidence. Its age matters less than what is missing around it: the developer who knew it, tests and documentation. Typical signs:

• A small change takes weeks, because nobody knows what else it touches.
• Updates of the server or the programming language wait, because the software might not run afterwards.
• One person, often outside the company, knows how the system works.
• An AI assistant or a new tool cannot connect, because the software has no API.

How I modernize legacy software

I read before I change. The approach below comes from current client work, in which a monolithic application is replaced piece by piece with AI coding agents under written rules.

The first step is a map. A knowledge graph is built from the code and its documentation, and an agent may change a part only after it has queried the graph for that part. It then knows the callers and the earlier decisions, which a new colleague would ask a teammate about.

Tests come next. They record what the software does today, including the odd cases that users rely on, and they run before each change goes live.

New functions go into an API with a versioned path and a written contract in OpenAPI. The old software hands over one function after another, and your staff keep working in it until a function has moved.

The agents work under the rules the staff follow. Their database role reads and cannot write, the production branch is protected, and a hook checks each tool call before it runs. A production change needs the confirmation of a person, given outside the chat.

The old part goes offline once checks prove that nothing reads or writes it anymore. A table that falls out of use gets a marker in its name and stays in the database until that proof is done.

Five routes for legacy software

The routes I weigh with a client before the first line changes. The third one is the route of the client work described above.

Route	What happens	When it fits	Risk
Document and test	A knowledge graph, documentation and tests go around the existing code, and the code stays	The software works and changes are rare	The old platform ages further and still needs its security updates
API in front	The old system keeps running, and other tools reach it through a new API	Other systems or AI tools need its data	The old code stays behind the API
Replace piece by piece	New parts take over one function at a time until the old system can go offline	The software changes often and the business cannot pause	Two systems run side by side for a while
Rewrite from scratch	A new system is built next to the old one and replaces it on one day	The old software is small, or its purpose has changed	Behavior nobody wrote down gets lost, and new features wait until the switch
Standard software	A product replaces the custom software	Your processes match what the product does	The processes change to fit the product

Developers call the third route the strangler fig pattern, after a fig that grows around a host tree and replaces it over the years.

Who I am

I am Michael Wutzke, based in Frankfurt, with more than twenty years in IT and media. At the Frankfurt-based company Blocksize Capital I took over a running oracle price-data network and its internal documentation as Head of Decentralized Finance and Node Operations, and later became CIO. Before that I programmed front ends and back ends of online shops for Lidl and REWE. I teach at Claude Hacker House and build software with Claude and Codex. I am also interested in open-source AI agents that a company runs on its own servers. Details: Career stages.