What to do when an old system matters but is hard to develop
How to regain control of an important legacy application without automatically choosing an expensive full rewrite.
An old system is not a problem merely because it uses older technology. The problem begins when the company cannot change it safely, diagnose failures or predict the cost of the next deployment.
Establish the facts first
An audit should cover architecture, dependencies, the database, deployment, monitoring and recurring incidents. The goal is a risk map, not a catalogue of stylistic comments.
Stabilisation may be the best first step
Critical-path tests, better logs, repeatable deployment and safer background jobs often reduce risk quickly. Larger changes are easier to plan afterwards.
Modernise in stages
New functions can be separated module by module, individual layers upgraded, or traffic gradually moved to a new application. Each stage should deliver independent value.
A rewrite needs an economic case
A full rewrite makes sense when constraints cannot reasonably be removed in stages and the business value exceeds the cost and risk of a long period of parallel development.
Example: connecting an older application to a shop
An existing WebForms application can receive shop orders through a separate API while staff continue using familiar screens. Agree data rules, duplicate protection, retries and rollback. The audit should deliver priorities, dependencies, a first-stage scope and acceptance criteria. Compare a concrete operation before and after the change under similar data and load, rather than relying on a list of outdated libraries.
Contact me
Considering automation of a similar process?
Briefly describe the situation. I will recommend a sensible first step — without a sales pitch or obligation.