Engagement · Kickstart + Nurture · 2025–2026

A legacy payroll & HR platform on the edge of shutdown one budget, two ways to lose, a closing market window

The unit could only survive by winning a new municipal market, yet chasing it recklessly would bleed the clients keeping the lights on today.

~€5M

annual IT budget owned, with hiring and supplier authority

~35

direct reports across product, infrastructure and third-line support

3 → 2

siloed teams consolidated into two aligned delivery streams

Ready to bid

platform rebuilt to public-tender specification for the contested municipal segment

Priority

One budget. A market window closing on a deadline. Two different ways to lose the unit, depending on where the money went. When the constraints are that sharp, ranking the work is not a planning chore, it is the whole job.

Context · Approach

Survival meant winning a new market without losing the old one, so the roadmap was ordered by what saved the most ground for the least effort.

The question on the table

The group's leadership had come with one question about the business unit behind the platform: make the software profitable, or stop it. Investment had already been cut. Years earlier, clients had been told the product was winding down, and it had been quietly slumbering ever since, never funded, never killed. There was a reason it was worth saving at all: this kind of payroll runs deep, because every customer set its own rules, and the platform was configurable enough to calculate all of them. An audit found a single path back to profitability. The competitor that had served the cities-and-communes wage-calculation segment was withdrawing its hosting offer, and those municipalities would soon have to choose a new vendor.

That deadline started a clock. Municipalities would choose their vendor once and stay with that choice for years, so missing the window meant being shut out of the segment for years more. The unit could not afford that: the business was already being weighed for closure, and the people who worked there were depending on it to survive. Saving the unit, and the jobs inside it, was the real brief.

Two ways to lose

The arithmetic was unforgiving. The current client base alone could not sustain the unit, so the new municipal segment had to be won. Lose that, and it was over. Yet pour everything into the new segment and let the existing clients bleed away, and it was over just the same.

So the work took real but bounded risk with the existing base, and made the new segment the true priority, because that is where the unit, and its people, would be saved. The budget could only be spent once, and every choice was weighed against that single goal. Nothing non-essential earned a place on the roadmap.

A month in, the whole unit heard the reasoning directly. There was a great deal to improve, and it would be improved, but the first work would be whatever moved the unit toward its goal. Good ideas were not turned away. They were written down and queued, so people could see the logic and see that their input still had a place in it.

One strategy, a few deliberate tracks

A municipal public tender asks specific things, and each had to be answered to even bid. The platform had to be secure enough to pass procurement on data protection, priced to beat the rival vendors bidding for the same cities, fast enough to demo without the daily complaints, and predictable enough to deliver on a promise. The estate Kurt inherited met none of these. Acquired years earlier and never integrated, it ran on ageing servers carrying critical vulnerabilities, with thousands of custom scripts nobody could still explain.

Rather than a task list, the turnaround became one strategy broken into a few parallel tracks, each answering one of those demands:

  • Security, infra and codeSecure the estate and the code, so the product can pass a public tender on security at all.
  • Compliant processesAddress the serious data-protection, privacy and secure-process gaps a NIS2- and GDPR-bound public tender checks first.
  • PriceMake the price competitive in a contested segment where other vendors bid for the same cities, through the licensing fix and a re-architected IaaS offering.
  • Cost and efficiencyReduce the cost of delivering and running the product across its life: simpler client onboarding, better self-help through a clearer manual, more efficient support, and automated, predictable releases.
  • Organisation and agilityPut end-to-end skill and capacity inside cross-functional product teams, so a team can take a change all the way to done instead of waiting on a separate one. A dedicated enablement team kept raising efficiency, the floor under offering the product profitably.
  • Central-IT collaborationMake central IT's security goals the unit's own; a breach of client data would end the business for everyone.

The long backlog came first, including the compiler upgrade that had been bleeding delivery capacity and shipping decade-old packages; build automation, a security baseline, proactive monitoring and the reorganisation ran alongside it. Clearing that backlog meant putting roughly five years of nearly-finished work live in a single push, which was always going to be turbulent: five years of problems that had never been spread out arrived together. Holding it one more year would have been worse, adding another year of problems on top and another year of the team losing a large share of its planning capacity to maintaining two code bases at once. The turbulence was the cost of the waiting, surfaced by the release rather than caused by it. Sometimes the only way past accumulated risk is straight through it, and the longer the wait, the worse it gets.

A price that wins a contested tender

Security and a working demo got the platform to the door of a tender. Price decided whether it could walk through, and the segment was contested: other vendors bid for the same cities, so the figure had to beat what they were offering on value. The licence was billed per registered user, which charged for access for every client, when granting access costs almost nothing, a single row in a table. The real load comes from somewhere else. The application is a heavy desktop client, so what consumes a server is the instances open at any one moment, each reserving memory and processors, and one person may keep several open. Repricing the licence to concurrent instances tied it to the figure a server can actually be sized against. That mattered most for the segment in view: public bodies carry many occasional and seasonal users, so a per-registered-user price would have inflated the bid as if every one of them worked at once, and quietly closed the door on the cities the unit was trying to win. With the IaaS operating cost cut alongside it, the price followed the capacity the software actually used. That is what the bid figure rested on.

The same re-architecture decided a deal already on the table. An existing public-sector customer who had been weighing whether to stay was kept on board by the re-architected, managed infrastructure.

Making the work hold together

The platform had been delivered by three teams that had grown up in separate silos without clear ownership, so finished work was rarely agreed across the seams. Central IT, meanwhile, had gone unheard for years.

The reorganisation split the unit into a customer-facing side and a product side, and gave the product side a product focus: cross-functional teams that each hold the skills and the dedicated capacity to take a change all the way to done. Before, a change could only be functionally tested by a separate team that had no capacity set aside for it, so it waited, and the wait was the bottleneck. Moving that responsibility and that capacity inside the product teams is what loosened the flow: releases came faster and landed more predictably. Some of that capacity had to be created from scratch. There had been no functional analysts at all, so an analyst was hired to coach the team, ten people were trained in the discipline, and a Scrum Master came in alongside them. The IT budget was grown by design to fund the change, releasing some roles and hiring the capability the turnaround needed.

A separate enablement team carried DevOps, automation and infrastructure, the standing capacity that keeps raising efficiency over time. Without that floor, the product could not be offered at a price that made the business work. Work the third line did was documented and handed down to first and second line, so support could resolve more on its own.

The counterparts in these decisions were the group's central-IT directors of architecture, infrastructure and business applications, the function that supplied the unit. Their security concerns became the unit's own concerns, because a breach of unprotected client data would end the business for everyone. The unit that had been held together by the goodwill of a few key people started to hold together by design.

~€1M added to the annual IT budget by design, to fund the people the change needed

Outcomes

A crisis-bound legacy platform made secure, competitively priced, fast enough to demo, and predictable enough to deliver on a public-tender promise.

Roughly five years of "nearly finished" backlog and large refactorings became usable in eight weeks, testing included, then shipped. That single push ended a dual-codebase maintenance burden that had run for years, unlocked current compilers, and replaced long-obsolete packages with maintained versions for a sharp security gain. Delivery became something the unit could promise: predictability rose from a low base to a reliable cadence, production defects fell, and ad-hoc demands on IT dropped as work was anticipated and planned rather than absorbed reactively. The re-architected infrastructure made the software measurably faster and far cheaper to run, with most of the saving coming from retiring a database licence the platform no longer needed, and it ended the daily slowness that had made the product hard to demo. The platform that had been slumbering toward shutdown was, by departure, secure, competitively priced, performant and sellable into a contested public-tender market.

~2 mo

to put ~5 years of undelivered backlog live, testing included

4×

measured software performance after the infrastructure re-architecture

~−70%

on the total cost of running the re-architected infrastructure

80%

delivery predictability, up from under 20%

“The budget could only be spent once, so every choice was weighed against one goal: making the platform sellable into the market that would save the unit.”

AI knowledge assistants · delivered for the platform's support teams

The turnaround delivered a working AI capability, in production before the engagement closed. Three pieces shipped. Internal knowledge agents, built in Microsoft Copilot Studio with semantic search across the SharePoint documentation, helped the helpdesk and support teams find the right answer fast and surfaced where the documentation was wrong or missing, which fed the quality work on the manual. Automated documentation-quality checks surfaced contradictions and gaps in the product manual, the groundwork any client-facing assistant would later stand on. In the delivery pipeline, GitHub Copilot and Claude Code ran inside a containerised CI/CD setup for AI-assisted review and quality gates. Three further pieces were designed and placed on the product roadmap, built to ship once the foundation work completed rather than during this engagement: an AI-assisted first-line tier that would take the customer's opening question and hand off to a person, held back until its answers were good enough to help rather than frustrate; a self-hosted RAG endpoint over the 2000+-page product manual that would answer clients from the improved documentation; and unsupervised ML anomaly detection on wage calculations. The delivered work was internal and concrete. The customer-facing pieces sat on the roadmap, designed and waiting on it.

A legacy platform the business is weighing for closure?

The fastest way to find out whether this shape of work fits your problem is a short conversation.