From COBOL to Cloud: A Practical Legacy Modernisation Playbook

Legacy systems are the elephant in every boardroom. Everyone knows they're a problem, nobody wants to touch them, and the longer you wait, the more expensive they become. But modernisation doesn't have to be a terrifying, multi-year gamble. With the right approach, you can upgrade safely, incrementally, and with measurable value at every stage.

Step 1: The Legacy Assessment

Before you change anything, understand what you have. This takes 2-4 weeks and answers five critical questions:

What Does the System Actually Do?

Legacy systems often have undocumented behaviour evolved over decades. We use stakeholder interviews, code analysis, traffic analysis, and characterisation testing — writing tests that capture current behaviour, even if nobody remembers why it works that way.

What Are the Risks?

Score each component across security vulnerability, knowledge concentration (if only one person understands it, that's critical), maintenance cost trends, integration capability, and compliance exposure.

What's the Business Impact?

Not all legacy is equally urgent. Prioritise by revenue impact if it fails, whether it's customer-facing, regulatory deadlines, and competitive disadvantage.

What Are the Dependencies?

Map every upstream source, downstream consumer, batch job, and third-party integration connected to the legacy platform.

What Would Modernisation Cost vs Status Quo?

Calculate current annual maintenance, projected 3-5 year cost increase, phased modernisation cost, and expected savings gained.

Step 2: Choose Your Strategy

Rehost ("Lift and Shift")

Move to cloud without changing code. Fastest and cheapest but doesn't fix underlying problems. Best for systems that work but run on expensive hardware.

Replatform

Targeted changes to leverage cloud capabilities without rewriting. Best for systems that are mostly fine but need better infrastructure.

Refactor / Re-architect

Restructure to modern patterns (microservices, API-first) while preserving business logic. Best for systems hitting scalability or integration limits.

Rebuild

Write from scratch. Most expensive and risky. Best when technology is truly obsolete (COBOL, VB6, FoxPro) and requirements have fundamentally changed.

Our default: Refactor using the strangler fig pattern.

Step 3: The Strangler Fig Pattern

Named after the tree that grows around a host, gradually replacing it:

• Identify a module — Pick one bounded area
• Build the new version — Match old behaviour exactly
• Route traffic — Gradually redirect to the new system
• Validate — Run both in parallel, comparing outputs
• Decommission — Remove old only after new is proven
• Repeat — Next module

Why It Works

• Zero downtime — Old system keeps running throughout
• Incremental value — Each module delivers improvements immediately
• Reversible — Traffic routes back if problems emerge
• Lower risk — One piece at a time

Where to Start

Pick the module with highest value and lowest risk. Don't start with the hardest part.

Step 4: Data Migration

Data migration is where projects most commonly fail. Rules:

• Never delete source data until new system is proven for a full business cycle
• Use idempotent migrations that can be re-run safely
• Validate row counts and checksums at every stage
• Run parallel systems with data comparison reports
• Plan for rollback — you must be able to go back

Step 5: Team Considerations

Upskilling vs Hiring

You need both. Existing team understands business logic (invaluable). New hires bring modern skills. Pair them together.

Knowledge Transfer

Document business rules, record stakeholder explanations, write characterisation tests, and create a decision log before changing anything.

Timeline Expectations

• Assessment: 2-4 weeks
• First module: 2-4 months
• Full modernisation: 12-24 months (phased)
• Value delivery: From first module (not at the end)

Common Mistakes

• Attempting a full rewrite — Takes 2-3x longer than estimated and frequently fails
• Ignoring data migration — Code is the easy part; data is where projects die
• Not testing against production data — Synthetic test data misses real edge cases
• Underestimating institutional knowledge — Document before the experts leave
• Trying to improve during migration — First match existing behaviour. Then improve. Never both at once

Next Steps

Start with an assessment. We provide legacy modernisation services from assessment-only to full enterprise programmes. Our fractional CTO service provides senior technical leadership to guide the process.

Book a free assessment consultation to discuss your situation.