The Old Software Was Still Running. The Problem Was the Only Person Who Understood It Had Left.
The application had been running for nearly two decades.
Nobody wanted to touch it.
But every morning, employees opened it and the business kept moving.
Then the developer who understood it best announced he was leaving.
Suddenly, leadership realized something uncomfortable:
They didn't just have a legacy software problem. They had a knowledge problem.
Legacy systems have an interesting way of becoming invisible.
Employees know which buttons to press.
Reports appear when expected.
So everyone focuses on newer projects.
"Ask David. He knows how that works."
Every company with long-running software seems to have a David.
Maybe it's someone in operations who has used the system since 2009.
They know things nobody bothered to write down.
They know why one calculation has a strange exception.
They know which process needs to run before month-end.
They know why a particular database table should never be modified directly.
They know that when Error 142 appears, restarting the server isn't enoughβyou need to clear something else first.
And somewhere along the way, that knowledge became part of the infrastructure.
Except it isn't stored on a server.
The code doesn't disappear.
The database doesn't disappear.
The documentation folder is still there.
But something important is gone:
Source code can tell a developer:
"When X happens, execute Y."
It doesn't necessarily explain:
"We added this rule 12 years ago because a particular manufacturing process behaves differently under these conditions."
That's a completely different kind of knowledge.
And it's exactly the kind that gets lost.
Imagine rebuilding an old quoting application.
The modernization team finds a strange pricing adjustment.
Months later, an unusual customer order appears.
Now everyone starts investigating.
Eventually someone remembers:
"Wait⦠wasn't there some special rule for this?"
That's why legacy modernization isn't simply about translating old code into newer technology.
Sometimes it's an archaeology project.
You're uncovering years of decisions.
What happens if we remove it?
Which customers depend on it?
Which other systems expect it?
And developers aren't the only people carrying this knowledge.
Sometimes the most valuable conversation is with the employee who's been using the application every day for 15 years.
"What do you do when this happens?"
"Oh, then I export this report, fix these three columns in Excel, send it to finance, and upload the final file here."
Nothing in the architecture diagram shows that.
But remove that export during modernization and suddenly a business process stops.
People can become undocumented integrations too.
This is why documentation shouldn't begin when someone resigns.
Three weeks of knowledge transfer cannot reliably capture 15 years of experience.
Ask experienced employees:
Which parts of the system are dangerous to change?
Which problems happen repeatedly?
What do new developers usually misunderstand?
Which manual workarounds exist?
Which calculations contain unusual rules?
What would you explain first to the person replacing you?
Those questions uncover the knowledge traditional documentation often misses.
Then don't just write everything into a giant document nobody will open again.
Turn knowledge into something useful.
Create architecture maps.
Write down business rules.
Capture unusual scenarios.
Build troubleshooting runbooks.
Create automated regression tests for critical calculations.
Cross-train another developer.
Have someone else perform the deployment.
Knowledge isn't truly transferred until someone else can use it.
There's another reason this matters.
Eventually, that legacy application will probably need modernization.
Maybe it's an old .NET application.
Maybe it's a desktop system that needs to become web-based.
Maybe the infrastructure is simply becoming too expensive or risky.
When that day comes, the modernization team will need to separate two things:
Old technology that should disappear.
Business knowledge that absolutely should not.
If you haven't captured the second, replacing the first becomes much more dangerous.
A useful question for leadership is surprisingly simple:
"If the person who understands this system best disappeared tomorrow, what would we no longer know?"
If the answer includes pricing logic, engineering calculations, customer workflows, deployment procedures, integrations, or recovery processesβ¦
You already have a knowledge gap.
You just haven't experienced the consequences yet.
The goal isn't to preserve old software forever.
The goal is to make sure your organization can eventually replace the technology without accidentally replacing years of accumulated knowledge with guesswork.
Your legacy application may belong to the company.
But if only one person understands it, part of the system effectively belongs to them.
That is worth fixing before their final day.
π§ Legacy systems contain institutional knowledge. Old code can represent years of business decisions, exceptions, and lessons.
π€ One expert can become a hidden dependency. If only one person understands a critical application, their departure becomes an operational risk.
π Source code isn't enough. Code often explains what happens without explaining why.
π₯ Talk to business users too. Long-term employees frequently understand workflows and workarounds developers can't see.
π§ͺ Turn behavior into tests. Regression tests can preserve expected calculations and outcomes during modernization.
π Cross-train before someone leaves. Documentation becomes much more valuable when another person can actually use it.
β° Don't wait for a resignation. Knowledge accumulated over 15 years cannot realistically be transferred in a two-week handover.
ποΈ Preserve knowledge, not obsolete technology. Modernization should remove technical limitations while retaining valuable business logic.
If your business depends on an application understood by only one or two long-term employees, the modernization risk may already be growing.
KSoft Technologies explores how organizations can identify, capture, and transfer critical legacy system knowledge before that expertise disappears:
π https://www.ksofttechnologies.com/blogs/legacy-code-knowledge-gap
