The operating problem
Legacy software often becomes visible only when it fails or when the last person who understands it leaves. The natural reaction is to replace it. Yet the old system may encode hundreds of decisions that were never documented: validation rules, report calculations, file formats, customer exceptions and sequencing assumptions. A rewrite started without this knowledge can remove technical debt while introducing operational debt.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 08 Jul 2026 · Last reviewed 08 Jul 2026Separate age from risk
Old technology is not automatically the greatest danger. A stable, isolated application with known support procedures may be lower risk than a newer system with weak data integrity and no diagnostics. Assess business criticality, change frequency, support knowledge, deployment fragility and failure impact rather than judging only by framework version.
- Map which business processes stop when the system stops.
- Identify components that are obsolete versus merely unfashionable.
- Prioritise unsupported dependencies and data risks over cosmetic age.
Capture the real system before changing it
Source code is only part of the application. Configuration files, scheduled tasks, database jobs, file shares, certificates, service accounts, local machine settings and user workarounds may all be required. A reliable baseline records how the system is built, deployed and used.
- Create a deployable copy or reproducible environment where possible.
- Back up schema, data and configuration before structural work.
- Document external files, services and manual steps that complete the process.
Improve evidence before chasing intermittent defects
Teams waste time when errors produce only a generic message or disappear after a restart. Add targeted logging around boundaries: database calls, file imports, API requests, background jobs and state transitions. Good diagnostics often reduce immediate support cost before any large modernisation effort.
- Log enough context to reproduce, without exposing sensitive data.
- Distinguish business validation failures from technical exceptions.
- Record version, environment and correlation identifiers.
Stabilisation creates a decision point
A stabilised system gives the business time and evidence. Urgent defects are controlled, support can see failures and the team can measure which modules change most often. That information makes the modernisation plan more accurate and prevents a crisis from dictating architecture.
- Fix the smallest set of defects that reduce material risk.
- Avoid broad refactoring while behaviour is still poorly understood.
- Use incidents and change requests to identify the best replacement boundary.
Choose replacement seams, not a big-bang promise
Many legacy systems can be modernised by extracting one module, report, portal or integration at a time. A new web interface may coexist with the old database temporarily, or a background service may replace a fragile manual import. The seam should be chosen where ownership and data boundaries are clear.
- Prefer modules with clear inputs, outputs and business ownership.
- Create compatibility layers only when their retirement path is understood.
- Keep reconciliation between old and new behaviour visible during transition.
Retire only when operational evidence is complete
A successful demo does not prove that the new system covers month-end, rare exceptions or historical reporting. Parallel validation should include real data, edge cases and the workflows users rely on under pressure. Retirement requires agreement on data retention, rollback and support.
- Test rarely used but high-consequence paths.
- Reconcile reports and transaction totals across systems.
- Archive source, deployment and data artefacts according to business obligations.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
The system is stable, rarely changed and well understood.
Immediate rewrite may have weak return.
Document support and monitor risk rather than modernising for appearance.
Failures are costly but the architecture is poorly understood.
Diagnosis and stabilisation should precede replacement.
Capture the environment, add evidence and control urgent defects.
One module changes frequently while others remain stable.
A phased extraction seam may exist.
Modernise the high-change boundary first with reconciliation.
The platform is unsupported and essential dependencies cannot be secured.
Replacement urgency is high.
Plan a controlled migration with explicit behaviour and data validation.
Evidence that the current approach is becoming risky.
- Nobody can recreate the production deployment from source.
- A rewrite estimate assumes the current screens describe all business rules.
- Database changes are made without migration scripts or rollback planning.
- Rare operational paths are excluded from acceptance testing.
- The old system is switched off before reports and historical data reconcile.
What to clarify before commissioning work.
- Inventory code, database, configuration, jobs, integrations and manual dependencies.
- Identify critical workflows and known failure consequences.
- Establish backups and a reproducible baseline.
- Add targeted diagnostics around unstable boundaries.
- Stabilise urgent risk before expanding scope.
- Choose phased replacement seams and validate old versus new behaviour.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
Is a full rewrite ever the right answer?
Yes, especially where the platform is unsupported, the architecture blocks essential change or the operational boundary can be defined clearly. It should be a conclusion from evidence rather than the opening assumption.
Can a new web application use the old database?
Sometimes, as a transitional phase. The risk depends on schema quality, ownership and how both applications coordinate changes.
Should old bugs be reproduced in the new system?
Only when users or downstream processes rely on the behaviour. The team must distinguish accidental defects from undocumented business rules.
How do we estimate work before understanding the codebase?
Use a paid discovery or technical audit to establish dependencies, risk, modules and migration options before committing to a broad fixed scope.