A Practical Guide to Incremental Software Modernisation

Modernisation is a constraint-removal programme

Rewriting old code in a new framework can leave the organisation with exactly the same bottlenecks. If releases still require a weekend outage, business rules remain hidden in stored procedures and only one person understands reconciliation, the technology is newer but the system is not meaningfully more modern.

Start by naming the constraint worth removing. It might be unsupported infrastructure, slow regulatory change, fragile deployment, poor security isolation, limited capacity or an integration that blocks product development. Connect that constraint to a measurable outcome: lead time, incident frequency, recovery time, support effort or the cost of making a representative change.

This prevents “move it to the cloud” from becoming the objective. Rehosting may reduce infrastructure risk without improving the application. Refactoring may improve changeability but delay a time-critical platform exit. Both can be valid increments when their purpose is explicit.

Do not confuse incremental delivery with an indefinite migration

Small releases reduce risk only when they move towards a defined end state. Running old and new systems together creates routing, synchronisation, support and security work. Without retirement criteria, the temporary architecture becomes a permanent distributed system.

Describe the target in terms of ownership and operating behaviour rather than a detailed five-year component diagram. Which system will own customer identity, pricing, orders and audit history? Which deployment and recovery standards will apply? Which legacy runtimes, databases and interfaces must disappear?

Maintain a retirement ledger beside the delivery backlog. For every compatibility adapter, replicated table, feature flag and duplicated job, record why it exists, who owns it and the condition that allows removal. Modernisation debt is easiest to create when temporary components have no expiry test.

Map behaviour before changing structure

Legacy systems contain more knowledge than their source code suggests. Behaviour lives in database triggers, scheduled tasks, spreadsheets, support procedures, integration retries and user workarounds. A code inventory cannot reveal the full contract the organisation depends upon.

Trace representative business journeys from input to final outcome. Record users and service identities, state changes, reports, downstream consumers, timing assumptions and manual interventions. Include end-of-month, failure recovery and correction paths; these are where undocumented rules usually appear.

Production telemetry can expose calls and dependencies that documentation misses. Database query logs, message traffic, scheduled job history and access records help build the map, subject to privacy and retention controls. Interview the people who reconcile failures, not only the people who operate the happy path.

The result is not a perfect specification. It is a prioritised set of behaviours that must be preserved, deliberately changed or retired.

Create a behavioural baseline before the first extraction

Characterisation tests capture what the existing system does, including odd behaviour that may be accidental. They are not endorsements. Label each observed behaviour as required, tolerated, unknown or defective so the new implementation does not faithfully reproduce every historical bug.

Test at stable boundaries: public APIs, generated documents, messages, database effects and completed user journeys. Snapshot tests can help with large outputs, but assertions should highlight business meaning rather than approve an unreadable blob.

Record operational baselines too: request volume, latency percentiles, batch duration, error rate, recovery time, infrastructure cost and support workload. A replacement that passes functional tests but doubles reconciliation effort has not succeeded.

When automated coverage is weak, shadow traffic or replay sanitised production examples in an isolated environment. Protect personal data and avoid reproducing side effects. The purpose is to find unknown behaviour before users do.

Choose a vertical business seam

Replacing the user interface, then the service layer, then the database sounds orderly but keeps every layer coupled until late in the programme. Prefer an end-to-end capability that can be owned, tested and released independently: notification preferences, document generation or a bounded part of customer onboarding.

A good first seam has business value, observable outcomes and manageable dependencies. It need not be the easiest component. Extracting an unused utility proves little; a frequently changed but bounded capability demonstrates whether the new delivery and operating model works.

Avoid decomposing according to technical nouns such as “the customer table”. One table may support several business capabilities with different rules. Domain boundaries are about responsibility and language, not where data happens to be stored today.

Do not assume every seam must become a microservice. A modular monolith can provide strong internal boundaries without network failure, distributed tracing and eventual-consistency costs. Independent deployment is valuable only where independent change or scaling justifies it.

Put routing and translation in the right places

The Strangler Fig pattern introduces a façade that routes some requests to the legacy implementation and others to the replacement. Clients keep one stable entry point while responsibility moves behind it. The façade must be observable, resilient and simple; it should not become a new home for business logic.

An anti-corruption layer solves a different problem. It translates legacy concepts, data shapes or protocols into the new domain's language. Without it, the replacement gradually inherits names, null semantics and workflow assumptions that made the old system difficult to change.

These layers impose latency and operational ownership. Use them where semantic or routing isolation is valuable, and document whether they are transitional or permanent. If the façade cannot intercept internal calls, scheduled jobs or direct database access, the apparent seam is incomplete.

Contract tests protect the boundary while implementations change. Version interfaces deliberately and observe consumers before removing old operations. An endpoint receiving no web traffic may still serve a monthly job.

Shared databases are the hardest coupling to remove

Code can be routed through an API; a database shared by reports, integrations and ad hoc scripts is harder to divide. Giving the new component direct write access to legacy tables may accelerate the first release, but it imports the old schema and allows either application to violate the other's invariants.

Assign one writer for each business fact. During an early phase, the legacy application may remain authoritative while the new component reads through an adapter. Later, ownership can move to a new store and the legacy system consume an API or replicated view.

Dual writes from application code are deceptively unsafe. One write can succeed while the other fails, creating reconciliation that is difficult to detect. Prefer a transactional outbox, change-data capture or an explicit migration pipeline where appropriate, and define how lag, replay and duplicates are handled.

Replication does not create two systems of record. State which copy is authoritative at every phase, who may write it and what evidence is required for cutover. Reconciliation must compare business meaning, not merely row counts.

Use expand-and-contract for compatible change

Database and message contracts often need old and new consumers to coexist. Make an additive change first, deploy producers and consumers that understand both forms, migrate data or traffic, then remove the obsolete form only after usage evidence shows it is safe.

This expand-and-contract sequence costs more steps but avoids requiring every component to deploy at once. It is especially useful for renaming fields, changing identifiers and replacing events.

Backward compatibility has a time limit. If the contract phase is never contracted, every future change must support all historical shapes. Put removal work in the same funded increment and monitor old-field use rather than relying on a calendar date.

Parallel running compares outcomes but creates another system

Shadowing production input through the new implementation can reveal behavioural differences without affecting users. It works well for deterministic calculations, read models and document generation. It is harder when the operation sends email, charges money or depends on time and random identifiers.

Suppress or virtualise side effects and compare normalised outcomes. Differences need classification: a new defect, an old defect intentionally fixed, acceptable formatting variation or incomplete test normalisation. A mismatch dashboard without an owner becomes noise.

Parallel running is not free. It doubles some processing, expands data access and creates a reconciliation workflow. Set the sample, duration, acceptance threshold and exit condition before starting. Long-running comparison can become a substitute for making the cutover decision.

Feature flags control exposure, not data compatibility

A flag can route a tenant or cohort to the new implementation and provide rapid rollback. It cannot undo a schema migration, reverse an external payment or reconcile state written under different rules. Rollback design must include data and side effects, not only code routing.

Keep flags few, typed and observable. Record which variant handled each request so incidents and outcome metrics can be correlated. Test both paths while both are supported, and remove the flag when the rollout or experiment ends.

Tenant-by-tenant rollout can be useful for business software, but tenants may interact through shared records or cross-tenant administration. Confirm that the routing unit matches the data and workflow boundary.

Modernise operations before multiplying components

Extracting services into a team that still deploys manually and cannot trace a request creates more failure points without better control. Establish automated builds, repeatable environments, secrets management, health checks, central telemetry and tested rollback early.

Observe a user journey across old and new components using a shared correlation identifier. Operators need to know which route served it, where latency accumulated and whether a retry is safe. Do not log sensitive payloads to compensate for weak tracing.

Ownership must move with functionality. The team responsible for a new component needs deployment access, alerts, runbooks and authority to fix it. A hand-off to an operations group after launch preserves the organisational coupling that incremental architecture was meant to reduce.

Measure whether change is becoming easier

Lines rewritten and services created are activity measures. A successful increment reduces a constraint, transfers ownership and enables deletion. If the legacy footprint never shrinks, the programme is adding a second estate.

Know when incremental modernisation is the wrong strategy

A phased approach is not automatically safer. A small, well-understood system may be cheaper to replace outright. An imminent platform shutdown, expiring licence or severe security exposure may impose a deadline that coexistence cannot meet. Some legacy applications cannot be intercepted or changed enough to establish a reliable seam.

Conversely, a rewrite is dangerous when the business cannot specify existing behaviour, data migration dominates the work or years of feature development would be frozen. The choice is about risk distribution, not engineering fashion.

Use discovery to compare options: retain and stabilise, rehost, replatform, refactor, replace with a product, rebuild or retire. Different parts of one portfolio may need different treatments.

A practical sequence for the first increment

1. Name one costly constraint and its measurable outcome.
2. Map one end-to-end capability, including data and operational dependencies.
3. Capture required behaviour and current service baselines.
4. Choose the smallest valuable seam and assign a single owner.
5. Introduce routing or translation only where the boundary requires it.
6. Move a vertical slice with telemetry, recovery and data reconciliation.
7. Release to a controlled cohort and compare business outcomes.
8. Delete the replaced path and record what was learned before expanding.

The deletion step matters. It proves that the boundary was real and prevents the programme from celebrating migration while continuing to pay for both implementations.

Related C3 Software guides

• How to Modernise Software Without Replacing Everything at Once
• Migrating an ASP.NET MVC Application to Modern .NET
• The Hidden Cost of Maintaining Legacy Software
• What Good Software Discovery Looks Like Before Development Starts