Why Legacy Systems Can't Be Rewritten: Evolution, Maintenance Types & Migration

Software Architecture Evolution

Software architecture evolves when one or more of the following change sources occur:

System requirements : functional or quality demands change (e.g., adding an online store that must return an order within 2 seconds).

Technology : legacy technology becomes obsolete or a newer technology fits better (e.g., database version end‑of‑life, migration to a container platform).

Environment : hardware, OS, regulations or external interfaces change (e.g., OS upgrade, tax‑message format change).

Distribution : deployment locations, nodes or collaboration mode change (e.g., moving from a single data‑center to multi‑region, multi‑store access).

Static vs. Dynamic Evolution

Static evolution modifies the system while it is stopped; dynamic evolution modifies it while the system continues to run.

System stopped → static evolution
System running → dynamic evolution

Static evolution steps (textbook) :

1. Software understanding
2. Requirement change analysis
3. Evolution plan formulation
4. System reconstruction
5. System testing

Example: pause all stores on Sunday night, upgrade the DB driver, split the settlement module, run data conversion, perform regression testing, then go live.

Dynamic evolution considerations (must keep compatibility, transfer state, ensure atomicity, provide rollback, and avoid unstable intermediate states).

Four Types of Software Maintenance

Corrective (bug fixing) – triggered by discovered errors or performance defects. Example: fix duplicate discount calculation.

Adaptive – triggered by external or data‑environment changes. Example: adapt to a new tax‑message format.

Perfective – triggered by user requests for new features, performance or efficiency. Example: add sales‑analysis report, speed up queries.

Preventive – proactive improvement for future reliability. Example: clean duplicate code, add automated tests.

Quick decision rule:

Already wrong → Corrective
External changed → Adaptive
Want better → Perfective
Not broken yet → Preventive

Reverse Engineering, Refactoring, Re‑engineering, Migration

Reverse Engineering : recover high‑level design from source code, DB schema, interfaces, call graphs, logs, or real‑world user actions. Goal – understand the old system. Does not add functionality.

Refactoring : improve internal structure at the same abstraction level (e.g., split a 5,000‑line settlement class into clear modules, extract payment adapters, eliminate duplicate code and circular dependencies, add automated tests). Goal – reduce complexity, improve maintainability. Does not add functionality.

Re‑engineering : combine reverse engineering, new requirements, and forward construction to systematically transform the old system. May add functionality.

Migration : change platform, DB, deployment environment, or system ownership (e.g., Oracle → new DB, on‑premise → cloud, monolith → services). May or may not add functionality.

Legacy‑System Quadrant Strategies

Combine technical quality (high/low) with business value (high/low) to select a disposition strategy:

High tech & high value – Refactor/Enhance : improve performance, data model, and continue evolution.

High tech & low value – Integrate : retain capability via APIs or messaging, letting the asset serve the larger system.

Low tech & low value – Retire : stop, replace with a standard product, migrate needed data.

Low tech & high value – Inherit : preserve valuable business rules, build a new system that gradually takes over while keeping old functionality alive.

New‑Old System Conversion Methods

Direct conversion : stop the old system, start the new one immediately. Pros : fast, low cost. Cons : highest risk, no rollback. Suitable for simple, low‑impact systems.

Parallel conversion : run both systems for a period, compare results, cut over once stable. Pros : low risk, result verification. Cons : higher cost, data‑sync effort. Suitable when data is critical and continuity is required.

Segmented conversion : migrate by module, region, or user group in batches; each batch is verified before proceeding. Pros : risk spread, ability to adjust later batches. Cons : longer timeline, need temporary interfaces. Suitable for large, complex systems.

Guideline for quick choice:

Simple & tolerates failure → Direct
Critical & must keep service → Parallel
Huge & can be split → Segmented

Example for a 600‑store retail system:

Segment by region → each region runs short‑term parallel → verify orders, inventory, settlement → after stability, migrate next region.

Decision Chain for Legacy Modernisation

Why change?
↓
Which maintenance class?
↓
Static or dynamic evolution?
↓
How much business value remains?
↓
Refactor, integrate, retire, or inherit?
↓
Direct, parallel, or segmented conversion?
↓
Validate data, monitor risk, keep rollback path

Architecture Knowledge, Modification, and Version Management

Knowledge management : store architecture design plus design decisions, including why a choice was made, business goals, constraints, alternatives evaluated, expected benefits, costs, and conditions for re‑evaluation.

Modification management : for each change record the target, rules, impact scope, possible side‑effects, verification method, and rollback procedure. Isolate modifications to limit impact.

Version management : track which architecture version is in production, its components and connections, what changed, why it changed, and how to revert if needed. Keep architecture diagrams, decision records, interface contracts, data models, deployment topologies, and operational configurations in sync with code versions.

Ten‑Stage Evolution of Large Websites (Problem‑Driven Roadmap)

The textbook lists a typical progression, each step driven by a concrete bottleneck:

Monolithic architecture

Vertical (layered) architecture

Introduce caching (e.g., to relieve repeated query load)

Deploy service clusters with load balancing

Database read/write separation

Reverse proxy and CDN for static assets

Distributed file system and distributed database

NoSQL and search engine integration

Business‑level decomposition

Distributed services (micro‑services, service governance)

Each stage is justified by a specific problem, e.g., “database overload → add cache”, “single instance cannot handle load → cluster”, “read pressure too high → read/write split”, etc.

Complete Retail Case Study (Ten‑Year System)

Evaluate technical level (low) and business value (high) → choose inherit strategy.

Perform reverse engineering on source code, DB schema, interfaces, call graphs, logs, and real user actions to reconstruct module structure, data model, business rules, external dependencies, and exception handling.

Refactor high‑coupling modules (e.g., split a 5,000‑line settlement class, extract payment adapters, remove duplicate code) while preserving external behavior.

Encapsulate legacy functionality that cannot be replaced yet with adapters or façade interfaces.

Adopt segmented conversion as primary approach, with short‑term parallel runs within each segment (region or store group) to verify order, inventory, and settlement consistency.

Implement data synchronization, format conversion, integrity checks, consistency verification, and exception compensation to guarantee no loss of historical transaction data.

Define success metrics, monitoring items, rollback conditions, and rollback procedures for each batch; monitor error rate, response time, reconciliation differences, and business success rate before decommissioning the old module.

Key Takeaways

Software architecture evolves because of changes in requirements, technology, environment, and distribution; legacy‑system disposition must weigh technical quality against business value, then adopt refactor, integrate, retire, or inherit strategies, and finally control migration risk with direct, parallel, or segmented conversion methods.