Key Takeaways
- Understand legacy systems before you touch them
- Modern-looking code doesn't mean a modern platform
- Shared system knowledge reduces reliance on specialists
- Legacy modernisation should be continuous, not one-off
A 20-year-old software company can look modern from the outside while much of its operational risk remains buried in outdated systems. Legacy modernisation is rarely driven by age alone. The pressure usually builds up from the settlement engine that still works but nobody wants to change, or the client workaround that quietly became part of the product.
Deloitte estimates that organisations spend between 21% and 40% of IT budget managing technical debt. That cost appears in cautious estimates, delayed releases and important changes that keep slipping down the roadmap because too few people understand what might break.
AI gives engineering teams a better way to investigate these systems. It can trace behaviour across a large codebase and connect evidence scattered across code and documentation. It can also accelerate repeatable work such as test creation and refactoring.
Once teams can understand and change legacy software faster, the pressure moves to the architecture that must support more clients and the delivery platform that must test, review, and release a growing volume of change safely.

How AI Changes the Cost and Risk of Legacy Modernisation
A long-lived C++ estate can be stable in production yet costly and risky to change. Years of fixes and client-specific exceptions become embedded in the code, while the reasoning remains in the heads of two or three senior engineers. Even a minor change can require weeks of investigation because its wider impact is difficult to predict.
Understand Legacy Code Before Rewriting It
Moving old code into a newer language is only one part of modernisation. Automated tools can accelerate translation, but they cannot determine on their own which behaviours remain important to the business, which workarounds are now obsolete, and which apparent defects are supporting an undocumented process.
Without that understanding, teams risk reproducing the same complexity in newer code. The language changes, but releases remain slow and the platform stays dependent on the same specialists.
Before replacing the system, teams need a reliable picture of how it behaves today. Static analysis reveals dependencies between components. Runtime data shows which paths are actually used. And support tickets and architecture records explain decisions that the code cannot.
AI can connect this evidence into a current map of the system, helping engineers assess the likely impact of a change and identify areas that still require specialist review.

Give AI Work With a Verifiable Result
AI-assisted modernisation becomes valuable once the team understands the system and agrees on the destination. Dependency upgrades, test migrations and repeated refactoring are well suited to AI because the output can be checked against a known standard.
Amazon used this approach to reduce some Java 17 upgrades from an average of 50 developer days to a few hours, with annualised efficiency gains of around $260 million.
The Amazon example involved a defined target and a testable result. Complex legacy systems require the same discipline, with evidence that each replacement works during normal use, under realistic load and across the edge cases accumulated over time.
Ciklum applied the same controlled approach when modernising the data infrastructure of a healthcare technology company. The estate included a legacy .NET monolith that could no longer handle growing data volumes. Ciklum built parallel environments and migrated workloads in controlled batches. It then successfully completed the programme with zero downtime while moving the infrastructure to code for repeatable deployment.
AI can accelerate analysis and implementation, but this testing and migration discipline is what turns faster engineering into safe modernisation.
Keep Engineers Accountable for High-Risk Decisions
Senior engineers are often cautious about AI for good reason. They have seen tools overpromise before, so they double-check the output and remain accountable for the decisions that carry the greatest risk.
That is the right model for AI-assisted modernisation. AI can reduce months of code investigation and process more material than any individual engineer, but senior engineers still decide which behaviour should survive, how the system should be separated and whether a change is safe to release. Architecture, security, and production behaviour always remain human responsibilities.
How Platform Architecture Breaks as One Client Becomes Many
A product built for one client can perform extremely well and still become difficult to scale. Each new customer brings different rules and integrations, and over time those exceptions become embedded in the core product.
Multi-tenant SaaS is one possible model, alongside standardised single-tenant and hybrid models. Whatever the approach, companies must define which capabilities are shared and which differences are managed through configuration or integrations.
One Ciklum engagement shows how this problem develops in practice. A global enterprise software provider had accumulated decades of client-specific customisations, leaving less engineering capacity for strategic product development. Ciklum helped an enterprise software provider replatform a heavily customised product while supporting more than 170 enterprise customers, moving its core business logic towards a scalable SaaS model.
Protect Each Client as the Shared Platform Changes
On a multi-tenant platform, customer differences should be handled through configuration rather than hard-coded rules. Data must remain separated, and new integrations should not require engineers to change the core product for every customer.
Once the architecture is agreed, AI can help find repeated client-specific code, prepare migration scripts, and draft the tests needed to move those exceptions out of the core. AI helps apply the agreed design across a large codebase while engineers review the migration scripts and tests.
Build Tenant Protection Into the Release Process
A mistake becomes more serious when several customers depend on the same platform. A permissions error, for example, could expose one client’s data to another.
Automated checks should therefore identify changes that cross customer boundaries or break existing integrations. Monitoring should also show performance for each client because a healthy platform-wide average can hide a serious problem affecting one customer.
Preserve Platform Knowledge as Engineering Teams Grow
Platform knowledge should connect the code with architecture decisions and current production behaviour. AI can help engineers retrieve that context as the team grows, but only when those sources are current and accessible. Without it, the platform remains dependent on its original engineers. In this way, AI assistants risk producing confident recommendations from incomplete evidence.

How AI Improves Delivery on a Mature Platform
Once a platform is established, the roadmap keeps growing while testing, release management, and operations become more expensive. Faster coding may appear to be the answer, but producing code is only one part of getting a useful change into a customer’s hands.
Where Faster Coding Creates a Delivery Bottleneck
AI can help engineers produce code faster, but most delivery systems cannot review, test and release changes at the same pace.
Some teams are already assigning structured work to AI agents overnight and reviewing the results the next morning. According to McKinsey, companies experimenting with this model have seen productivity improve threefold to fivefold. However, that additional output also increases the pressure on architecture reviews, integration testing, security approvals and release processes.
Coding assistants such as Claude Code can examine a codebase, edit files and run tests, making them useful for bounded engineering work. Every change still needs to follow the company’s architecture, security and approval requirements.
Keep Testing, Review and Operations From Falling Behind
The problem begins when AI helps teams produce changes faster than the organisation can test, review and release them.
To prevent the rest of delivery from falling behind, teams need to automate integration and security checks. They need to define where human review is required and improve production monitoring. Without those controls, AI increases work in progress without helping customers receive improvements any faster.
Measure How Fast Safe Changes Reach Customers
Code volume and AI-tool adoption reveal little about business value. Leaders should measure how long a change takes to reach production, how often releases fail and how quickly teams recover when something goes wrong.
In legacy modernisation, progress should appear as high-risk components being retired and releases becoming less dependent on a few specialists. On a growing platform, it should appear as faster client onboarding without creating another customer-specific version of the product.
The relevant metric should track the programme’s original constraint, whether that is release time, failure rate, client onboarding or reliance on a few specialists.
In another engagement, Ciklum simplified customisation and deployment for a mature enterprise software platform, reducing delivery timelines from nine months to five weeks.

Make Legacy Modernisation Part of How the Platform Runs
Legacy modernisation works best when it becomes part of normal platform work rather than returning every few years as another large transformation programme. AI makes that approach more practical by reducing the effort required to understand and change complex systems.
Ciklum's engagement with Salling Group offers one example of progressive modernisation. The work replaced legacy systems across e-commerce and internal tools, contributing to a 40% reduction in technology costs.
Start with the system creating the greatest business risk, whether because failure would cause serious disruption or because too few people understand how it works. Build a reliable picture of the system before choosing a migration approach or tool, then begin with a change that can be tested properly. Each stage should leave the platform easier to change.
Ciklum's AI-Assisted Legacy Refactor and AI-Enabled Engineering services help engineering leaders map high-risk systems, modernise them safely, and improve the delivery platform around them. Speak to Ciklum about the system creating the greatest constraint on your roadmap.