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.
Let's talk
Considering automation of a similar process?
Briefly describe the situation. I will recommend a sensible first step — without a sales pitch or obligation.