That alignment of tech and business is the foundation of the total metrics-driven approach: a proven framework that brings structure, clarity, and accountability to application modernisation efforts.

It flips the script on how legacy modernisation is usually done and it all comes down to how you frame the problem from the very start and how you translate it into actions that not only deliver but also prove their value in the numbers.

What is a total metrics-driven modernisation approach?

The way we see it,

The work starts well before any technical decisions are made with defining the underlying drivers for change, mapping where the organisation is today, where it needs to be in the future, and agreeing on what success should look like, both in terms of business impact and operational readiness.

Only when the direction is clear, is the modernisation effort guided by:

• Key success metrics – clear indicators that the modernisation has delivered the intended value. These might include ROI, increased operational efficiency, reduced time-to-market, improved system availability, or measurable gains in user satisfaction.
• Delivery metrics – reflecting the relevance, quality and speed of the process, including predictability, technical stability, and effectiveness of implementation.

The method is simple on the outside, yet rigorous on the inside: the real impact happens when delivery is tied to measurable outcomes.

Total metrics-driven approach: the benefits

What makes this approach work is what it delivers early on. You see results fast, and you know it’s working because outcomes are measured from the start.

• Clear definition of success
  The goal of modernisation effort is clearly defined up front, in terms of outcomes and business needs.
• Measurable results and accountability
  Every milestone has a clear set of metrics attached to it, making the progress traceable and any issues visible early.
• Faster time to value
  First tangible results show up within first weeks of work. This early feedback confirms the direction and builds momentum without stalling on long timelines.
• Result-focused collaboration
  While delivery is scoped to the most urgent goal, the team works holistically, proactively identifying improvements that can amplify impact elsewhere.
• Commercial predictability
  Built around Performance-led Engineering, the model ties delivery to metrics and holds the vendor financially accountable for results.

The true value of the framework, however, becomes clear only when it’s tested under real-world constraints.

How is it different from a traditional modernisation approach? A case study

Before working with us, one of our clients in the transportation industry put it bluntly:

I’ve had some severe struggles with third-party partners and boutique shops that have overpromised and not even underdelivered… just haven’t delivered at all.

Our Client

Transportation industry

What sounded like pure outsourcing frustration was a symptom of a much deeper issue – the company’s business continuity was under threat due to a failed modernisation attempt.

By the time we first met, the company had already spent over 18 months and tens of thousands of dollars working with external vendors on a big-bang back- and front- office tech rebuild which had collapsed under its own weight.

Despite all that time and all that money spent, no feature had gone live, as the modernisation stalled before any outcomes were delivered. The business was still stuck with the same monolithic on-prem .NET app, expensive to maintain, increasingly unsupported, and poorly aligned with how teams wanted to work.

And without the ability to respond to market opportunities, the risk of business stagnation was becoming real.

Why did they fail?

On paper, that modernisation looked ambitious, yet feasible. In practice, however, it lacked the foundations to succeed. Why?

• First, there was no clear plan: no defined goals or success metrics. Without a clearly defined “why”, the initiative lacked direction from day one.
• Second, there was no way to measure progress or course-correct along the way. Without metrics, success was impossible to define. And worse, issues that grew along the way were impossible to spot until it was too late.
• Finally, the entire effort relied on a full tech rebuild delivered all at once, with no room for early wins or iteration, and causing even minor missteps to snowball out of control.

What did we do differently?

Instead of repeating the big-bang mistake and trying to solve everything at once, we focused on what would deliver the highest value and built from there.

Discovery

Before deciding what to modernise, we needed to understand how the current system actually worked and where it held the business back. That meant running a series of structured discovery activities:

• First, we looked at the core process and timelines to understand which areas were most business-critical and time-sensitive.
• We conducted a comprehensive audit of the existing system (covering the codebase, databases, user interface, and operational processes) to understand how it supported key workflows and where it introduced friction, from outdated UI patterns to performance bottlenecks.
• We mapped out the stakeholders’ roles to surface any gaps between ownership, priorities, and expectations.
• And finally, we used activity design methods, like service blueprinting and story mapping, to reveal where day-to-day friction was the highest.

Across all the areas we explored, the process for setting dynamic pricing stood out: the point where technical debt most clearly collided with commercial needs. What should have been a fast lever for pricing decisions, took a week of manual coordination. Adjustments required input from both sales staff and a database engineer, all working within outdated, legacy-bound workflows.

It was a narrowly defined part of the system, but the implications were broad. This single feature had become a bottleneck with outsized commercial impact. It offered a rare combination: high strategic value and relatively low effort to address. And that made it the obvious place to begin.

Implementing proven frameworks

This also raised a practical question: what’s the best way to move the project forward without repeating the past mistakes?

We used the 7R framework from AWS to assess our options, focusing on the best balance between effort, cost-effectiveness, and business impact.

While rewriting the entire system meant returning to the strategy that had already failed to deliver, all off-the-shelf tools lacked the flexibility the pricing model required. Therefore, the best path was to build a dedicated cloud-native module from scratch. Crucially, it had to be designed as a standalone, microservice-based component, ready to grow with future features.

Defining success metrics

Once the goal was clear, one thing still needed to be nailed down: how to recognise success and how to prove it in real, measurable terms.

We worked with the client to define that together and share that understanding across the whole project. Success had to be measured in terms of how the change would support day-to-day operations and unlock real business value.

From that shared understanding came a clear set of business-related metrics, providing a measurable representation of the outcomes we aimed to achieve:

• Deadline: go live in under 3 months with the dynamic pricing functionality,
• Efficiency: reduce the dynamic pricing process setting from 1 week to under 10 minutes,
• Ownership: cut involvement in the process from 3 roles across departments to 1 product owner, with no database knowledge required,
• Frequency of updates: shift from quarterly to weekly changes in pricing logic, without engineering input.

With that in place, we focused on finding the most effective way to deliver results we agreed on.

Performance-led delivery

After a failed all-or-nothing modernisation efforts run by another third-party vendor, our client had every reason to be sceptical about delivery promises. That’s why they needed a plan that would work and a way to know it was working.

What made our modernisation attempt different was that we approached delivery through our Performance-led Engineering model. How did it look in practice?

Knowing the goal, we chose the tech stack, delivery standards and the team setup best suited to make it happen. But the tech alone wasn’t enough. This is why we sat down with the client and agreed on how success would be measured – what to track, how to read the numbers, and where the line between “done” and “not done” was.

Read more: Beyond the code: achieving business goals with Performance-led Engineering

To track progress throughout the project, we implemented a metrics framework built around industry-standard, recognised benchmarks, including DORA metrics, SLA targets, and operational thresholds.

To strengthen predictability and accountability even more, we tied performance of delivery teams to commercial terms: the client paid only for outcomes that met the agreed performance thresholds. Within this framework, we prioritised a core set of delivery indicators reflecting speed, reliability, and efficiency, including:

• Lead time for change
  • Before: not tracked, releases required manual coordination and typically took weeks
  • Target: cut lead time to under 48 hours from code commit to production
• Deployment frequency
  • Before: 1-2 releases per quarter, typically requiring bundled deployments
  • Target: At least 1 deployment per week for the new module
• Change failure rate
  • Before: No clear data, as rollbacks and production fixes weren’t tracked consistently
  • Target: Keep failure rate under 5%, supported by automated testing and quality gates
• Time to restore service
  • Before: Reactive fixes with unclear ownership and variable response time
  • Target: Restore in under 30 minutes for any deployment-related disruption
• SLA: system response time and availability
  • Target: Response time under 200 Ms for key API endpoints under normal load, availability of 99.99% across new components.

Adaptive team for scalable delivery

To implement and deploy the new solution efficiently, we shaped the team around the intended outcome, starting with a Solution Architect and a Business Analyst to define priorities and constraints. A UX designer joined early to ensure the interface was both intuitive and visually engaging. As the work progressed, the team was scaled up with developers and DevOps specialists to accelerate delivery.

The new app ran in the cloud from day one. Lower environments were spun up on demand, optimised for cost and speed. The setup gave the team the flexibility to move fast and gave the client a delivery process that was measurable and built for impact.

Result

The new pricing module went live in under three months, just as planned.

The dynamic pricing process, previously a full week of cross-team coordination, now took less than ten minutes. Ownership shifted from three roles across departments to a single product owner and pricing logic could be adjusted on the fly, without engineering involved.

Our solution became a working part of the business. Thanks to its modular, cloud-native architecture, it opened the door to modernising other features by gradually replacing old functionality with new components through a strangler fig pattern.

Modernisation did not stop with the dynamic pricing module. It evolved into an ongoing, agile, and iterative process, expanding to other parts of the system. Together with the client, we prioritised further opportunities based on the highest business impact and lowest effort, building a clear and adaptable roadmap, ready to adjust to shifting priorities and emerging opportunities.

Will total-metrics driven modernisation work in my business?

Although the total-metrics-driven modernisation isn’t a plug-and-play framework, it is repeatable.

It works across industries, stacks and setups because it reframes modernisation as a business-critical, data-backed initiative, not just a narrow exercise in system replacement.

The total metrics modernisation: step by step

Modernisation is always triggered by a concrete business need, like the pressure to prepare for future growth, fix costly inefficiencies, accelerate product delivery, or ensure business continuity. The problem might be operational, financial or strategic, but the solution can’t be technical alone.

While every modernisation engagement is unique, the process follows a repeatable structure that keeps the work focused on what matters most.

Each phase stays grounded in business impact and remains traceable to working results.

Understand: define the goals

Before any design or delivery work begins, there needs to be a shared understanding between the business and the tech partner of why change is needed and where it will have the most impact. In a total-metrics driven approach, it means investigating both internal and external forces shaping the business context:

• Interview stakeholders to know where the pressure comes from. This step uncovers the true cost of staying still and surfaces where value might be trapped
• Review internal materials and external market reports to gain critical context on company performance, market dynamics, and structural constraints
• Run an initial assessment of business processes and systems to clarify what’s in place and where the most critical inefficiencies live
• Assess risk and constraints to pinpoint and remove all factors that may block or delay the process. This step helps set realistic expectations and prepare for trade-offs before delivery begins
• Define non-functional requirements, like scalability, performance or cost. These set the ground rules for what success looks like once the modernisation is delivered and help narrow solution paths well before any tech is chosen
• Align on the desired business outcome through structured workshops. Define what a successful modernisation means in operational terms.

Once the business goals are uncovered, translate them into measurable KPIs, so that progress can be tracked from day one.

Deliver

Once the metrics and the modernisation path are defined, delivery becomes the engine of the transformation. The right process should be predictable and designed to stay accountable from start to finish.

• Choose solutions based on impact and efficiency, prioritising solutions with the best alignment with success metrics
• Apply lessons from similar projects to avoid unnecessary detours and double down what’s proven to work
• Look beyond the scope: even if the project scope covers one area, stay alert for inefficiencies that may arise elsewhere. Look for any factors that may derail or amplify the outcome
• Avoid the pitfalls of vague, big-bang modernisation initiatives. Instead, deconstruct the scope into smaller, outcome-driven components built incrementally, following the strangler fig pattern. Each part should serve a clearly defined business goal, with measurable impact tracked throughout the delivery process.
• Build the team with the milestone in mind, ensuring the setup is tailored to the current project need with just the right skills, roles, and capacity to deliver the next outcome without unnecessary overhead
• Optimise for efficiency with the right delivery model, pairing it with operational metrics that show how efficiently the value is being delivered
• Follow industry-recognised frameworks like DORA, CI/CD, Lean IT, Agile or ISO-9241, selected to bring clarity, repeatability and traceability to the delivery process
• Stay aligned and accountable by ensuring that roles and responsibilities are clearly assigned across in-house and external teams. Keep communication transparent to share understanding of what success looks like for both sides
• Tie tech partner collaboration to the outcomes, using the right collaboration model (like performance-led engineering) that links effort to results with metrics and shared accountability

Monitor

Once the delivery is underway, metrics must remain in focus. Review progress at both operational and strategic levels to ensure alignment with business goals and to spot early signs of drift or inefficiency.

• Stay on course with executive-level visibility: review progress at both operational and strategic levels, ensuring decisions stay aligned with business values. Introduce regular checkpoints, like demos, retrospectives, and quarterly checkpoints, to validate direction and adjust when needed.
• Document key risks and decisions as they emerge, maintaining a shared risk log and decision log to ensure transparency and informed stakeholder oversight.
• Establish a clear cadence for sharing risks, so that everyone is on the same page, unexpected issues are reduced, and ownership stays shared.
• Surface and manage risks early, especially when goals are at risk. Give every team member the ability to flag risks, ensuring issues are spotted and addressed properly before they spiral out of control

Making modernisation work

As there is a difference between moving fast and making progress, total metric-driven approach helps make that distinction clear, by connecting action to evidence and every project scope to measurable impact.

For organisations under pressure to modernise and adapt, that clarity brings the unprecedented value.