Enterprise Application Modernization: Beyond Lift-and-Shift

Most enterprises have hundreds of applications, many built a decade or more ago. The modernisation pressure comes from multiple directions: cloud cost optimisation (legacy apps waste cloud resources), feature velocity (monoliths are slow to change), talent retention (engineers don't want to work on COBOL), and security (legacy frameworks have unpatched vulnerabilities).

The most common mistake is treating all applications the same. Not every application needs the same modernisation approach — and some shouldn't be modernised at all.

The Modernisation Spectrum

Assessment Framework

Step 1: Application Portfolio Analysis

For each application, assess:

Step 2: Plot on the Modernisation Matrix

High business value + High technical health: Replatform or refactor. Invest in making a good application better.

High business value + Low technical health: Rearchitect or rebuild. The application is critical but holding you back.

Low business value + High technical health: Retain or rehost. Don't invest in modernising something that works and isn't strategic.

Low business value + Low technical health: Replace or retire. Don't modernise something that should be eliminated.

Step 3: Prioritise

Prioritise modernisation based on:

1. Business impact: Which modernisations unlock the most business value?
2. Dependencies: Which applications block other modernisation efforts?
3. Quick wins: Which applications can be modernised quickly to build momentum?
4. Risk reduction: Which applications pose the highest operational or security risk?

The Strangler Fig Pattern at Scale

For large, monolithic applications, the strangler fig pattern is the safest modernisation approach:

1. Identify a boundary: Find a well-defined functional area within the monolith (e.g., user authentication, search, notifications)
2. Build the replacement: Create a new, modern service that implements the same capability
3. Route traffic: Use an API gateway or routing layer to direct requests to the new service
4. Validate: Run both systems in parallel, comparing results
5. Cut over: Route all traffic to the new service
6. Remove from monolith: Delete the old code from the monolith

Key principles:

• Work from the outside in (start with capabilities that have clear API boundaries)
• Maintain backward compatibility (the rest of the monolith shouldn't know the difference)
• One bounded context at a time (resist the urge to extract multiple services simultaneously)
• Keep the monolith deployable and stable throughout the process

Database Modernisation

Database modernisation is often the hardest part of application modernisation:

Options

The Shared Database Problem

The biggest obstacle to microservice extraction is the shared database. Multiple services reading from and writing to the same tables create tight coupling that's extremely difficult to unwind.

Approach:

1. Identify which tables each bounded context owns
2. Introduce APIs for cross-context data access (instead of direct DB queries)
3. Gradually move tables to service-owned databases
4. Use change data capture (CDC) for synchronisation during transition

Containerisation Strategy

Containerising applications is a common modernisation step, but it's not always the right one:

Containerise when:

• You want environment consistency (dev = staging = production)
• The application is stateless or can be made stateless
• You want to leverage Kubernetes for orchestration and scaling
• Multiple applications share the same host and need isolation

Don't containerise when:

• The application is a simple, single-instance service (use a managed platform instead)
• The application has heavy state dependencies that don't fit container patterns
• Containerisation would be a significant refactoring effort with no other benefit

Testing Strategy for Modernisation

Modernisation introduces risk. Your testing strategy must account for it:

1. Characterisation tests: Before touching the code, write tests that capture the current behaviour. These tests serve as a safety net.
2. Contract tests: When extracting services, contract tests verify that the API contract between the new service and its consumers is maintained.
3. Shadow testing: Run the new implementation alongside the old one, comparing results without serving the new results to users.
4. Canary deployment: Gradually shift traffic to the modernised component, monitoring for regressions.

Timeline Expectations

---

Application modernisation is a strategic investment that compounds over time. Every modernised application is faster to change, cheaper to operate, and more secure. If you're planning your modernisation strategy, let's talk.