When a system has been running unattended for years and the person who wrote it has left, the first question is not how do we modernise this. It is much smaller and much more useful:
Can anyone, today, on a machine they can actually buy, turn this source code back into the thing that is running in production?
Ask it first. About half the time the answer is no, and everything you were planning to decide depends on it.
Why the answer is so often no
A running binary and a buildable codebase are different assets. The binary keeps working long after the ability to produce a new one has quietly expired. Nobody notices, because nobody has needed a new build.
The usual causes, roughly in the order we hit them:
- The toolchain is gone. A Delphi 7 project needs Delphi 7. Old Xcode versions are not always downloadable, and often will not run on a current macOS at all.
- Dependencies no longer resolve. Component vendors go out of business. Package hosts disappear. A path points at a network share that was decommissioned in 2019.
- Certificates have expired. For anything signed — mobile apps especially — the signing identity may be attached to an account nobody has the password to.
- The build script assumes a machine nobody has. Hardcoded drive letters, a specific Windows version, a licence dongle, a folder on someone’s desktop.
- Source and production have drifted. The repository holds the version from before three hotfixes were applied directly to the server.
That last one is the worst, and it is not rare. It means the source you have is not the system you are running, and no amount of reading will tell you what the difference is.
What it costs to find out
Two or three days. That is the whole point of asking first.
Compare it with the alternative, which is what usually happens: a vendor quotes a modernisation project from a folder listing and a ninety-minute call, the contract is signed, and the build problem is discovered in week two — after the number has been approved and the plan has been socialised internally.
Every estimate written before this question is answered is a guess. The answer moves the number more than almost anything else you might learn.
What to do with each answer
If it builds. Good. You have a working feedback loop, which means everything that follows — a dependency upgrade, a strangler-pattern migration, a security fix — is ordinary engineering. Most of the risk in the project just went away.
If it does not build. You now know the real first phase, and it is not modernisation. It is reconstructing a build. That work is bounded and it is worth doing on its own, whatever you decide afterwards, because until it is done you cannot ship a single change — including a one-line security fix on a system that is currently running your business.
If source and production have drifted. Stop and reconcile them before anything else. Decompiling, diffing behaviour, interviewing whoever is left. It is unpleasant work and there is no way around it: you cannot modernise a system whose current behaviour you cannot reproduce.
Ask it out loud
If you are talking to a vendor about a legacy system, ask what they will do in the first week. If the answer does not include building it, they are going to quote you from the outside, the way everyone else already has.
It is a cheap question and it sorts the room quickly.