How we rebuilt a 30-year-old maintenance system without stopping the old one

Who our client is, and who they sell to

Our client is an EU-based software company. Their product is bought by factories and industrial groups, and since the 1990s it has been the system those plants use to keep their equipment serviced.

Picture a plant with two hundred machines. One needs its oil changed every five hundred operating hours. Another is due for a quarterly inspection. A third depends on a spare part that has to be on the shelf before it fails. Miss one of those and a line stops in the middle of a shift. Our client's product is what keeps that from happening: it holds the structure of halls, lines and machines, plans the recurring jobs, issues the work orders the technicians carry out, tracks spare parts, and reads the counters — operating hours, kilometres — that decide when a job comes due.

The plants that buy it range from a single site to industrial groups with several legal entities under one roof.

The question that kept coming up in sales conversations

The older product is a Windows desktop application, written in Delphi on top of MS SQL and installed on a server at each plant. That shape fitted the era it was chosen in, and it decides how the product travels: to put it in front of a buyer you send an executable that somebody installs. A new plant means another installation and another database to look after. A new version means a file that has to reach every machine running it.

By the time we met, the arithmetic had turned against that. Buyers were asking for a browser version and there was none to show them. One large prospect made it clear that a browser version was a condition, which put a date on the problem. Rewriting inside the old technology would have taken years of the in-house team's capacity while the same question kept coming back in sales conversations. And the understanding of how the whole thing fitted together lived with the people who had been there longest.

We read thirty years of code before writing a line of our own

Before designing anything, we documented what already existed. We ran AI tooling over the legacy source and generated an internal wiki of the product: every module and table, what it does, why it exists, and the exact place in the code that proves it. Thirty years of decisions became something a new person could read in an afternoon.

Then we sat with the owners and walked through the real product for hours. That is where we hit something worth recording. Both sides were using the words company, department, location and customer to mean different things, and it was already causing confusion on calls. The client offered to write a shared glossary, with example plant setups from the simplest to the most layered. We had it in hand before the data model was fixed, and it saved us from wrong turns that would have been expensive to undo.

What we built for them to sell

A web platform that carries the same maintenance work the old product was trusted for: asset structures, work definitions, recurring and one-time jobs, work orders and reports. The decisions that mattered to the owners:

• One codebase, two ways to run it. The platform runs as a cloud service or on a plant's own server, so the buyers whose rules keep data inside the building can keep it there.

• Every plant's data sits isolated at the database level. This was the first thing the owners asked about. With the contracts their buyers now sign, a data breach is the kind of event a company their size does not recover from, and the architecture had to answer that before it answered anything else.

• Onboarding moved into an admin console. Setting up a new plant takes a few minutes, with no installation involved. It used to mean standing up a server.

• The source code sits in the client's own hands, with full repository access and history, and no licence held on our side.

• Work was estimated in small packages, approved in advance, and invoiced after delivery.

Their in-house Delphi team stayed. We ran working sessions with them on AI-assisted development, and they now move faster through the old product while the new platform grows beside it. That collaboration also helped their team approach the old product with more confidence.

The person building it was one call away

The platform was led by Aleksey Andruschenko, our senior developer, with the rest of the team working alongside him. The owners never had to route a question through anyone. When something about their business was unclear, they called Aleksey and settled it in the same conversation.

That access is worth as much as what he put in from his own side. Aleksey went deep into how the client's business actually runs: how a plant is structured, what a maintenance planner does on a Tuesday morning, which parts of the old product the plants would never give up. Deep enough to push back on a requirement when it would not serve the product our client has to sell. Decisions that would otherwise have waited for the next cycle were made in the room.

What changed for the business

• 3 weeks from approved architecture to the first working version of the core workflow, demoed on screen.

• 78 tracked changes delivered in a single agreed work package, on estimate.

• The client's in-house team stayed focused on the legacy product while the new platform was built beside it.

• Setting up a new plant went from installing a dedicated server and database to creating an account in the console, in minutes.

• Cloud running costs for the whole platform are in the low hundreds of euros per month.

• The old product stayed in production throughout, and no plant was moved before it was ready.

Where we corrected course

As we shaped the first version, the client helped us keep the product grounded in how most of their customers actually work. We had started by looking closely at the most complex setups in their base, because those are the ones where mistakes are hardest to undo. The owners brought the discussion back to the everyday case: most plants they sell to run a single site, and the first version had to stay simple enough for those customers to set up and use without friction. We kept the layered structure in the plan, but moved it out of the foundation. That decision kept the product easier to sell and easier to adopt.

We also adjusted the rhythm of delivery as the work sped up. Fast iterations gave the client working screens quickly, but they also made it important to protect quality between releases. So we added a stabilisation day to every cycle — manual review, cleanup and automated tests — and made it a regular part of each package rather than something handled at the end.

Is your product held back by the technology it was built in?

The pattern behind this case is common in established software products. The business grows, customer expectations change, and the original technology starts to limit what the product can do next. At that point, the question is not whether the in-house team is capable. It is whether this is the best use of their time.

Our view is that strong internal teams should stay focused on the product knowledge only they have: the customers, the workflows, the edge cases, the things that make the product valuable. When the next step requires a different technology stack, outside support can carry that part of the work while the client's own team stays close to the product and keeps the existing system moving.

If your product has reached that point, bring in a team that has already worked across the technologies your next version may need. See how we approach legacy modernization and custom web platform development, or book a call with us.

These images were modified to comply with the client's NDA. The software interface remains unchanged.