Every business, once it reaches a certain scale and age, knows this problem. Maybe it’s an internal tool, maybe it’s the product itself, but there is always that piece of software. It has been around for years, slowly accumulating complexity and importance until it is practically irreplaceable. By then, it is usually showing its age too.

For Siemens, that piece of software was a quoting tool for selling medical equipment to hospitals. Tens of thousands of sales staff in more than twenty countries used it every day, building deals worth close to €10bn a year.

A rewrite was already two years in, with no firm end date and costs still climbing. The business was starting to plan around a reduced scope and cut features just to get something out the door. Instead, DRS engineers ported the existing C++ to the browser by compiling it to WebAssembly, carrying twenty years of business logic across intact. The application was live within a year, and DRS went on to support and extend it for the two years that followed.

By 2023, the tool had become as much a liability as an asset. Built in C++ with MFC, its design language and interaction patterns belonged to the early 2000s: dense dialogs, nested menus, and nothing a modern user would call intuitive. And it ran only on Windows. Every new starter needed it installed before they could quote, every release had to be rolled out to tens of thousands of machines of every age, spec and Windows version, and anything that went wrong had to be diagnosed one locked-down corporate laptop at a time. Mac users were out of luck altogether.

It was also holding the business back. Around it, Siemens had built a browser-based ecosystem of sales tools, and the quoting tool sat awkwardly outside it, unable to integrate cleanly. More pressing was a plan already under way to let trusted customers view and adjust their own quotes. An installed Windows application made that a non-starter. Siemens could hardly ask hospital procurement teams to install and maintain its sales software on their own machines, and even if they could, the interface was not one anyone wanted a customer to see. The plan needed a modern and maintainable tool that ran in the browser.

However, creating this would prove to be easier said than done. The tool was an enormous and complex codebase, totalling over seven hundred thousand lines of code, and containing over twenty years of accrued evolutions, refinements, rules and exceptions to the rules. All of these came together to form crucial and highly complex business logic, none of which could be lost in the move.

The obvious answer, and the one Siemens reached for first, was a ground-up rewrite in TypeScript. After more than two years it was proving far slower and more costly than expected, and the conversation had turned to what could be dropped to hit the deadline, while the sales teams carried on struggling with the old tool.

A rewrite depends on knowing what the existing system does, and in a codebase of this age that knowledge lives in the code rather than in any document. Rules were tangled into interface code, special cases were scattered across modules, and the only way to find them all was to read every line. Each behaviour then had to be reimplemented and verified against the original.

Rather than painstakingly unpicking the web of behaviours, DRS engineers proposed a different route. Using Cheerp, the C++ to WebAssembly compiler built by DRS’s sister company Leaning Technologies, the existing code could run in the browser behind a new web front end. That turns a rewrite into a port, which is far faster, and the business logic comes across intact without needing to be reimplemented.

Even as a port, this was a huge undertaking, and confidence within the Siemens team was mixed. Some were optimistic; others felt the task was too large, or outright impossible. The concerns were reasonable. C++ written for Windows depends on Windows APIs, libraries and conventions, none of which exist in a browser. Every Windows and MFC component the application used would need to be reimplemented, right down to the string type.

DRS proposed a proof of concept: take one particularly complex calculation, port it with all of its dependencies, and run it in the browser. If the hardest logic could run in a browser, the rest could too, and the full port would go ahead. DRS built it alone, working from a copy of the codebase and needing nothing from the Siemens team beyond the occasional question answered. Two months later, the proof of concept was completed and Siemens leadership gave the green light.

From there, the two teams split the work. Siemens’ developers stopped reimplementing business logic and focused on building the front-end pages. DRS ported the C++ core to run in the browser, then adapted those first-pass pages to plug into it. Where a component was too tightly bound to the underlying data to be built in isolation, DRS built it from scratch alongside the port. The full port took six months, followed by eight weeks of rigorous acceptance testing and polishing to reach a production-ready release. The browser application went live ten months after kick-off, and users were migrated gradually. Once the last of them were across, Siemens retired the Windows version in 2025, completing what the Senior IT Director overseeing the project called the most significant deployment the business had seen in over a decade.

The web application was live within a year of kick-off, around 70% sooner than the remaining projection for the rewrite, with none of the core business logic rewritten or lost, and nothing cut from scope to get there. The project manager who worked with DRS throughout repeatedly described the team as wizards, having delivered what many had thought impossible.

For the sales teams, the change was immediate. The tool opened in a browser on any machine, Mac or Windows, with nothing to install and nothing to keep updated. A new starter could quote on their first morning, and a release reached every user in every country the day it shipped.

Running in the browser also meant the quoting tool could finally connect properly to the rest of Siemens’ sales ecosystem, unlocking direct integrations between the quoting tool and other stages of the pipeline. And with a modern interface that customers could open in their own browser, the plan to give trusted customers direct access to understand and customise their own deals could go ahead.

The engagement ran for three years in all, from proof of concept through to long-term support and knowledge transfer. After go-live, the working model shifted. DRS engineers worked alongside their Siemens counterparts as a specialist extension of the team, shipping weekly releases and playing a core part in building those new integrations and customer-facing features. Throughout, they were teaching Siemens engineers to work with the ported code, and by the end Siemens’ own team was maintaining and extending the system without them, at which point DRS stepped away.

Most businesses have a system like this somewhere: starting to show its age, but too central and too complex to rewrite easily.

DRS’s Complexity Scan is a short, cheap engagement that maps the problem, the principal risks and the realistic options, and ends with a recommendation on the best next steps.

Contact Us