The hidden layers of modernisation

Responding to change, be it entering new markets, adjusting to regulatory shifts or adapting to operational complexity, is never just a commercial decision. It comes with new compliance requirements, operational constraints, and overcoming hard technical boundaries shaped by past solutions that stand in the way.

While it’s tempting to treat modernisation only as a technical upgrade, the reality is layered.

Changes at the infrastructure level often cascade up to architecture, business logic and even the way outcomes are delivered. And when regulatory or operational pressure is involved, these layers become even more tightly coupled, making it harder to act without a clear strategy.

Strategic growth hinged on timely execution

Let’s now look at how that capability was put to the test.

One of our clients, an HR-tech platform provider, was approached by a global delivery and logistics company. They were interested in using the product as their core hiring tool, but only if the platform could support a segment of job seekers it hadn’t handled before.

Securing the deal meant a significant commercial opportunity: one that could impact the platform’s growth, revenue, and market position.

The task might sound simple enough. After all, it was just an extension of the existing functionality.

What truly made it difficult was the deadline. The functionality had to be delivered within seven days, no buffer. Miss it, and the deal was off the table.

A turning point in platform capability

At that point, the client realised that their current software delivery partner just wasn’t delivering. Changes took too long, release cycles dragged on for months, and the overall quality left little room for basic client-vendor trust.

Meanwhile, the business context was clear. The broader environment, shaped by post-pandemic recovery, hybrid work models, and growing geopolitical uncertainty, had unprecedentedly accelerated the pace of change in the recruitment sector. And amid all this, the platform had to keep up.

A tough choice to make

This is when the company made a deliberate (yet not a risk-free) decision to switch vendors in the middle of ongoing operations. It meant starting over with a new team, new processes and a platform that wasn’t built for change.

We stepped in with just two weeks to work alongside the outgoing team, transfer essential knowledge and prepare for full responsibility. Two and a half months later, we were to take over the entire platform and in six months – deliver the first fully reworked module.

And the state of the platform? Not exactly a starting point you’d choose for an easy modernisation task.

On paper, the architecture was cloud-based. In reality, core components were integrated via a shared database, and the responsibility of the components was mixed, resulting in an embodiment of the “distributed monolith” anti-pattern. There were no automated tests whatsoever. Each deployment was a coordinated, manual effort, carried out once per quarter, with fingers crossed.

To succeed, we had to move smart. And fast.

A shift in technology: untangling complexity

We approached the technical transformation gradually, starting with the most constrained areas, where even the smallest change could set off a chain reaction. At a first glance, the scope looked fully manageable, but the deeper we went, the more we uncovered: hidden dependencies, process-specific logic and legacy decisions layered over one another.

To bring structure to the process, we broke the work down into a sequence of practical steps:

Improving modularity

Once we mapped out the impact areas, we started decoupling the most entangled services. Each got its own data store, interface, and release path. This reduced regression risk and made testing and deployment faster, since changes no longer had to be coordinated across the entire platform.

Introducing automated testing

With no test coverage in place, we focused first on the areas with the highest risk of failure. Tests were added incrementally, and built into the pipelines, making safe, unattended releases possible.

Implementing CI/CD pipelines

Manual release processes were replaced with automated pipelines integrated into development workflows. Changes could now be tested, verified, and deployed with minimal overhead, at the speed of development.

Building a reliable deployment process

Deployment moved from quarterly, manual routines to automated, domain-level pipelines. Releases became faster, isolated, and easier to roll back when needed. This also laid the groundwork for agile onboarding of the new enterprise clients with custom requirements.

Adding observability

We introduced structured logging and metrics across services. This gave teams visibility into what had changed, what had failed, and how the system behaved in production.

Focusing on priorities

Not every component needed rework. We put high-impact domains first, exactly where stability, performance or change-readiness brought the biggest return. This helped control scope and align technical work with commercial priorities.

The platform became modular, stable and ready to evolve, but the modernisation couldn’t stop at the code level. It had to reach into how people worked, made decisions and delivered value every day.

A shift in culture

The modernised platform gave the teams the technical ability to move faster. Without changes in the way people worked, however, the system’s potential would have stayed theoretical.

Before the handover, the delivery process was fractured. Delivery, QA, and Ops teams worked in silos, with long handovers and no clear sense of ownership. Fixing a small issue in one module meant coordinating changes across multiple teams, often without shared context or responsibility. This way of work had to go, fast.

You build it, you run it

We reorganised teams around business domains rather than technical layers. Each team took responsibility from the first line of code to production release. This eliminated handovers and made it easier to track progress, resolve incidents and deliver change continuously.

DevOps as a culture

The new architecture made faster delivery possible, but only because teams had full control over how changes moved through the pipeline. If a release failed, the team responsible for the change fixed the issue directly, making a path from code to production clear.

Release infrastructure wasn’t managed by a separate DevOps function. Pipelines were owned and maintained by the people who used them every day. When something blocked delivery, it was immediately addressed at the source.

Monitoring was a part of the release process from the start. Teams could see what had been deployed, when it went live, and how the system behaved afterward. That visibility helped anticipate issues early and understand the real impact of each change.

Result

Following the total metrics-driven modernisation approach, the team knew that delivery performance after modernisation couldn’t be based on perception. The platform was changing fast, and it needed equally fast feedback on how it was progressing.

To stay in control, we tracked DORA metrics from the earliest releases.

The results speak for themselves:

The gains in performance were backed by tangible changes in how the system was built and operated:

It’s obvious that without that modernisation effort, the request for a new hiring capability delivered in just seven days would have triggered delays, cross-team escalation, and difficult trade-offs.

But this forward-thinking company had secured earlier exactly what it needed: a system capable of responding, without hesitation, when the opportunity arrived.

The result was telling: the new hiring capability went live in just seven days – seamlessly and without disruption.

But as it turned out, the same foundation would soon be tested again.

Meeting compliance requirements

The next opportunity came from a new US-based client – one of the first to onboard under the new delivery model.

The deal was solid, but one requirement stood out: certified SOC 2 compliance.

Not unusual at this scale – security had become non-negotiable after a wave of data breaches, even in regulated industries.

Although the platform hadn’t been built around this particular requirement, the modernisation laid the solid groundwork, as core controls – traceability, access management, monitoring – were already in place.

With focused effort, the team closed the remaining gaps fast, giving the client full confidence to move forward with the attestation.

Was the compliance requirement the endgame? Definitely not.

The platform’s growing reputation attracted more users, which in turn led to an influx of job postings. This surge meant more data to process and more perfect matches to make, without delay.

Making job offer matching work at scale

Meanwhile, newly registered users often waited days to receive the first meaningful job offer. The logic behind candidate matching was one-way and static. Internal teams stepped in to close the gap – but even then, nearly one in five job postings remained unanswered.

Prolonged inefficiency at that scale could erode trust in the platform: both among users and enterprise clients.

This time, the challenge was operational. But thanks to the earlier architectural work, the technology was ready, and the response was immediate.

Matching rules were redesigned and tested through a canary release. Adjustments followed in real time. And just within 3 months, the new engine went live across the platform.

The results here?

• Time-to-offer dropped from days to under 24 hours
• Matching efficiency improved over 3x
• Monthly operational costs fell by more than 90%

What stood out along the way

The right approach to modernisation not only removes obstacles but also establishes a new baseline for how things get done.

Read more:

• How to re-engineer applications to achieve scalability
• Application modernisation: a guide for business leaders
• Rearchitecting: why you should redesign your application

The win in the modernisation game is not the shiniest tech tool. It’s removing friction where it hurts the business most, so the system stays reliable under pressure, flexible in the face of change, and ready when the next opportunity knocks.