Most mid-market companies have at least one application that fits the same description: business-critical, poorly documented, runs on infrastructure that hasn’t been touched in years, and nobody wants to go near it. These are the applications that block cloud adoption, slow down product teams, and represent significant operational risk.
Modernizing them is possible. But it requires a clear framework for decision-making, because “modernize” means different things in different contexts.
The Modernization Spectrum
Think of modernization not as a single destination but as a spectrum of options, each with a different risk and reward profile:
Rehost (Lift and shift): Move the application to cloud infrastructure without changing the code. Fastest, lowest risk, smallest benefit. Appropriate for applications you plan to retire within 12–18 months.
Replatform: Move to a managed cloud service with minor changes — for example, moving from a self-managed database to Amazon RDS. Moderate effort, meaningful operational benefit.
Refactor / Re-architect: Change the application’s architecture to be cloud-native — containerisation, microservices, event-driven patterns. High effort, high long-term reward. Appropriate for applications central to your product or operations.
Replace: Swap the application for a SaaS product. Sometimes the right answer when a vendor has solved the problem better than you can.
Retire: Decommission applications that no longer provide value. Often overlooked, always underestimated in its impact on reducing complexity.
Making the Decision
For each application in your portfolio, work through three questions:
1. What is the business value? Is this application in the critical path for revenue or operations? The higher the value, the more investment in modernization is justified.
2. What is the technical debt? A clean, well-tested monolith may need only a replatform. An undocumented spaghetti system with no tests may require a full re-architecture — or replacement.
3. What is the migration risk? Assess integration complexity, data sensitivity, and team familiarity. High-risk applications need more runway and a more conservative approach.
The Strangler Fig Pattern
For large applications you can’t afford to rewrite in one go, the strangler fig pattern is the most reliable approach. You build new functionality around the edges of the legacy system, gradually routing traffic to the new implementation while the old system “withers.” Over time, the legacy system does less and less until it can be retired.
This approach requires discipline — particularly around maintaining two systems simultaneously — but it dramatically reduces the risk of a big-bang rewrite that disrupts production.
What to Do First
Before writing a line of code, invest in understanding what you have. Run a discovery sprint: interview the people who operate the application, map the integrations, identify the data flows, and document the undocumented. The discoveries made in this phase consistently change the plan — and they’re far cheaper to find in discovery than in a failed production deployment.
Application modernization is a long game. The companies that do it well treat it as an ongoing investment rather than a one-time project, and they make decisions at the application level rather than trying to apply a single approach across their entire portfolio.