That’s exactly when scalability comes to the forefront, driving serious modernisation decisions: often too late to avoid instability, urgency, and reactive work that leaves no room for long-term thinking.

According to Red Hat’s 2024 survey, 98% of organisations recognise application modernisation as critical for future success, and more than 70% identify scalability (alongside reliability and security) as a key metric for measuring the impact of their modernisation efforts.

But how exactly do you re-engineer applications that start holding your business back and turn scalability into something you can test, measure, and trust? And, more importantly, how can you ensure that system behaviour remains predictable as load and complexity grow? Let’s break it down.

What does it mean to reengineer applications for scalability?

In common understanding, scalability is often reduced to the ability of an application to handle more traffic or increasing operational load. While that’s fair part of the picture, it’s not the whole story.

While scalability is about maintaining performance, efficiency, and reliability under increasing load, it ultimately means being able to support growth without degrading user experience, compromising business operations, or inflating operational costs uncontrollably.

This applies to both business growth over time (such as a rising number of clients in new markets) and to short-term, often unexpected spikes in system usage triggered by events like time-limited offers or operational peaks specific to certain industries. It also includes the ability to remain resilient in the face of change: whether it’s shifts in regulatory policies, market conditions, or internal business priorities.

That’s why scalability should always be viewed through two lenses:

• Solution scalability – the ability of software to handle increasing usage, data volume, and complexity without loss of performance.
• Business scalability – the ability of the system to support expansion into new markets, fresh revenue streams, or broader operational models without becoming a bottleneck.

The two are closely interdependent: technical scalability doesn’t drive growth on its own, but it makes business growth possible. Without it, even the most promising opportunities can be throttled. But technical scalability alone isn’t enough: it removes obstacles, but delivering real value still depends on the business’s ability to act.

This is why designing for scalability always starts with the business: defining growth targets and translating them into measurable system requirements for performance, reliability, and efficiency.

Scalability can (and must) be measured

Scalability is never an abstract property, and it can be expressed with a set of measurable capabilities: how many users can the system support? At what point does performance degrade? How efficiently can resources be added when needed?

But deep down, the metrics are not about the system alone. They’re about protecting business momentum, making sure that growth doesn’t outpace the organisation’s ability to deliver. Each target reflects a measurable strategic intent, be it faster new client onboarding, smoother operations or outstanding resilience under pressure.

Translating scalability theory into real-world change is rarely linear. In practice, growth pushes systems to their limits in uneven, often unpredictable ways, forcing businesses to confront unexpected trade-offs between continuity and expansion.

One company we worked with, a retail-focused CRM provider, faced this exact struggle as its growth outpaced what the system was originally built to handle.

Re-engineering application for scalability: a case study

When we first met the team behind a high-growth CRM product used by retail stores worldwide, they were already a victim of their own success, firefighting to keep technology aligned with the pace of their business growth.

Despite the amount of engineering work they put in, the application was constantly pushing back: the entire business model depended on a single .NET monolith product, deployed on a tightly coupled, single-environment structure.

At first, the setup they had built served them well. But as the product adoption accelerated across a growing number of retail locations worldwide, the system began showing cracks.

The risk

Performance issues became a daily reality, especially during retail peak hours, when CPU usage would spike and response time would grow erratic.

Without a way to isolate workloads or distribute the strain across the system, even small issues spiralled out of control, turning a single store’s slowdown into a full-platform’s disruption. On several occasions, daily outages lasted up to one hour.

Lacking a clear path forward, the team kept circling around recurring issues, with technical debt piling up faster than they could contain it.

Technology had hit a wall. There was no more room to grow without risking collapse. But tech wasn’t the only challenge the company was facing.

The pressure

Tech problems emerged just as the pressure to scale intensified. The company’s investors demanded a 50% year-over-year growth in store adoption: precisely when every new store onboarding was making the system even more fragile.

The stakes were rising fast but so was the risk to business continuity.

Scaling further was no longer an option as the system was already stretched to the limit. A big bang rebuild would have taken months, while performance issues were already eroding customer trust and investor patience. It felt like a dead-end: too risky to scale, and too costly to stand still.

That’s when we found another way through.

Understanding the basics

We started by clarifying what the business actually needed the application to support in day-to-day operational realities and strategic goals. That meant speaking directly with engineering teams, product owners, and commercial stakeholders to understand how the application was used, where it created friction, and what growth targets it was exactly expected to sustain.

We also met with the investors to understand their expectations, particularly around store adoption, speed of onboarding, and platform reliability.

Only once this foundation was in place did the technical direction start to make sense. We reviewed incident history and analysed patterns in performance slowdowns to highlight operational issues that had long gone unaddressed.

This included non-functional requirements that had never been formalised before for the application: minimum uptime targets, performance thresholds under load, failure tolerance, and architectural guardrails that had to be respected throughout the re-engineering process.

What emerged was a clear picture: the system needed to grow in a way that preserved the pace of delivery and protected customer trust at every step.

The metrics

From that, we built a language of measurable outcomes, understood by the tech teams, management, and investors alike: a set of technical and operational metrics that would guide every step of the transformation, aligned with the company’s growth forecast and investor expectations over the next 24 months:

Performance & efficiency

• Reduce performance-related incidents from 3-5 per day to a maximum of 1 incident per month
• Maintain <200 ms response times for critical APIs during peak usage
• Keep CPU usage under 70% and memory usage under 80% across production nodes during high-traffic hours

Reliability & continuity

• Achieve 99.99% uptime SLA – replacing daily outages of up to one hour with no more than 52 minutes of downtime per year
• Ensure 100% SLA compliance across all external APIs integration under projected peak loads

Scalability readiness

• Stimulate and pass load tests reflecting 200% of expected daily peak traffic, based on observability data and growth forecasts
• Validate platform stability across a growing network of 2,000+ retail stores
• Reach 80% migration coverage across business-critical modules within the two-year scalability window
• Route 90% of production traffic through modernised components
• Achieve 100% observability coverage for performance-critical services and scaling thresholds

Re-engineering the platform

With success metrics in place, we could move forward, without taking the system offline or pausing the business. Here’s how that played out in practice:

• The decision to refactor and replatform, rather than rebuild everything, gave the team a pragmatic starting point: modernising only where it moved the needle most, without rebuilding everything from scratch.
• Migration to .Net Core opened the door to performance improvements and cloud-native features, all while keeping the existing codebase largely intact.
• Introducing microservices by extracting them from the existing codebase preserved core logic, accelerated delivery, and enabled independent scaling, without the cost and delay of a full rewrite.
• Modularising key components allowed for targeted deployments, easier scaling, and better fault isolation, without destabilising the wider system.
• Introducing sharding at the database layer helped eliminate performance bottlenecks and made horizontal scaling finally achievable.
• Feature flags throughout the process gave the team confidence to deploy gradually, test under real conditions, and roll back safely if needs.

Testing and observability

The team designed performance tests to capture real system behaviour, including response times, resource usage and traffic handling under peak conditions. Each test result informed next optimisation decision. Built-in observability helped detect anomalies early and monitor improvements as they happened.

The result

Throughout the transformation, the retail stores kept using the platform as usual, unaware of the deep engineering work happening in the background. The only thing they noticed?  One day the app just started working better, with no frustrating slowdowns or unexpected gaps in availability.

Before modernisation, investors had set a clear target: 50% year-over-year growth.

Observability and testing confirmed (and they still confirm) that the system holds strong and is ready to keep going. Any early signs of any strain or bottlenecks will now be visible long before they become issues, giving the team time to respond proactively.

Key focus areas when re-engineering for scalability

The case shows that re-engineering only works when it’s focused on changes that improve how the system supports clear growth or efficiency targets, and when those changes can be measured.

This includes making data-driven modernisation decisions about where to invest effort and what level of technical change is needed to achieve the desired level of scalability.

Instead of applying one-size-fits-all approach, each modernisation must be evaluated on its own terms, considering the business impact, technical constraints, resources and effort required to achieve the right scalability. Still, a set of common steps can serve as a reliable framework for navigating the process.

Align scalability goals with business needs

Understanding how the business expects to grow and what that growth will require from the app, is a critical first step.

This stage combines strategic analysis, planning, and stakeholder collaboration. The goal is to uncover where scalability is most critical and define what capabilities it must deliver to support that growth objective, both now and in the future.

This stage requires:

• Clarifying business priorities, such as increased user activity, transaction volume, geographic expansion, or product diversification, with a clear timeline for when each area is expected to scale.
• Defining what kind of scalability the business needs: is it related with more users, more data or faster response times?
• Linking system capabilities to business goals by identifying the underlying reasons for scaling — and mapping them to the components that need to scale.
• Identifying initial constraints and risks that could block growth, whether technical, organisational, or architectural.

To ground technical planning in business context, it’s essential to combine stakeholder interviews, product workshops, historical incident analysis, usage data reviews, and feature planning reviews sessions, all aimed at defining what scalability means to a specific organisation.

Application monitoring is one of the most valuable sources of input. When in place, it reveals real-world usage patterns and helps pinpoint bottlenecks and inefficiencies.

Define measurable scalability targets

Scalability needs to be defined in terms of how well the system can hold up as demand grows. And to be meaningful, that capability must be measurable.

The metrics should thus capture both what the business aims to achieve and how the system performs under pressure.

The metrics provide the tangible baseline for validating architectural decisions and verifying that performance improvements deliver the intended business impact.

Diagnose architectural bottlenecks

Scalability constraints often reveal themselves gradually, through slow API responses, resource exhaustion or a rising number of incidents under load.

To move forward, you need to identify the parts of the system that are already under strain, using available observability data, past incidents and usage logs trends.

If monitoring data is limited, start by looking at business-critical workflows and core system functions, where poor performance has the greatest impact. Pay special attention to areas where performance degrades faster than traffic grows – that’s where bottlenecks turn into real barriers.

Choose the right modernisation path

Not every scalability issue requires a full rebuild. With clearly defined metrics and a structured approach, such as one of the 5 Application Modernisation Strategies by Future Processing, we can identify whether replatforming, rehosting or rewriting offers the best balance between effort and value.

Design for modularity and independent scaling

Breaking apart tightly coupled systems makes it possible to scale the most demanding components first without duplicating effort across the whole architecture.

Modular design enables independent deployments, targeted performance improvements, and the ability to test scalability at a more granular level.

Implement observability and load testing early

Proper monitoring and observability in place provide real-time insight into how the system responds to change — exposing bottlenecks, latency spikes, resource saturation, and failure patterns before they become user-facing problems.

It also enables faster root-cause analysis and helps prioritise which improvements deliver the greatest impact.

Enable delivery in small, validated steps

Scaling systems iteratively – through feature flags, parallel rollout paths or partial migrations, keeps risks low and control high.

Each step can be tested, measured and adjusted in isolation, allowing improvements to be introduced without jeopardising businesses continuity.

Re-engineering applications for scalability improvement

Clarity on the business problem and expected outcome comes first. Only then do technical decisions make sense – in the codebase, the infrastructure, and performance. Every step should maximise impact and minimise effort. The goal is to deliver visible value fast, without falling into a big-bang rewrite that solves nothing.

Re-engineering only works when priorities are shared between tech and business stakeholders, progress is measurable, and improvements are introduced without putting the business at risk.

That’s what makes scalability sustainable.