Every legacy application tells two stories. The one written in code. And the one carried by people, until they leave.
During more than twenty years in IT, I have worked with and led teams responsible for systems that organisations often describe as legacy.
For the last five years, I was responsible for one of those applications. By then, it had already been running for more than two decades.
When I arrived and took responsibility for leading the project, I was lucky. I found a team that was committed, experienced and very proud of the application they were supporting. They cared about understanding it and pushing it forward.
I didn't arrive knowing the system, and pretending otherwise would have helped nobody. My first approach was to listen and understand what the team already knew, where the gaps were and what the organisation could not afford to lose.
I also had to protect the continuity of the service, the confidence of the team and our ability to keep moving forward.
The application, the business and the organisation didn't wait for me to get to know the system and catch up. Incidents continued, new requests arrived, components needed attention and technologies had to be upgraded or replaced.
We didn't have one document, one person or one place that could explain everything that had been built, changed or decided during the previous twenty years. Some areas were well known. Others became clear only when we started working on them.
I remember situations where a change looked limited and safe at the beginning. Then one dependency appeared, followed by another, and the discussion became much larger than the original request.
At times, it felt like navigating an uncertain ocean. The waves didn't wait until we understood the entire sea, so we had to keep moving while learning what was beneath the surface.
The team also needed time to get to know me. Trust doesn't come with the job title. It develops through daily work and consistency, by listening when someone raises a concern, giving direction when the path is unclear and standing with the team when the pressure increases.
Over time, we became a team that could face difficult situations together. We didn't always agree, and uncertainty didn't disappear. What changed was that people could speak honestly, challenge an assumption and ask for help without being left alone when difficulties appeared.
That trust increased over time and became essential when the more difficult changes began.
The knowledge had not disappeared. It was simply spread everywhere. Part of it was in the code, scripts, database structures and server configurations. Other parts were hidden in long email exchanges. Some knowledge appeared only when we changed a component and observed how the application reacted. A great deal still lived with developers, business users and colleagues who had moved to other teams or departments or who had left the organisation.
Documentation existed, and some of it was useful. But there was no single place where a new person could start and understand the application from beginning to end.
That wasn't surprising. Over twenty years, many Project Managers, sponsors, developers and business users had contributed to the application. Each person had understood one part, solved particular problems and recorded what seemed important at that time.
The result was a large amount of information, but information alone doesn't create understanding.
A document may explain what a process does. It rarely carries the full discussion behind it, the constraints that existed, the options that were rejected or the reason why a temporary solution remained for many years. We often discovered this when we compared the documentation with the real behaviour of the application. The document wasn't always wrong. It was incomplete.
To understand a long running system, you need more than facts. You need to understand the project, the business, the users and the people who have supported it over time, (as I use to say, feel its pulse).
I realised early that producing more documents would not solve the problem by itself. We needed documentation for our team and for those who would come after us, but it had to become part of the daily work.
We used it while analysing incidents. We corrected it when a change exposed something new. We discussed it with the team and business users. Sometimes an old email explained more than a formal specification because it contained the original concern and the decision made at the time.
Knowledge needs people who are willing to share what they know, including the parts that were never written down. It also needs people who are prepared to listen, ask questions and spend enough time connecting one piece with another. Knowledge requires someone willing to receive it, but also willing to give it. Knowledge requires much more than storage.
As Project Manager, I couldn't transfer all that knowledge myself. Much of it was technical or linked to specific business processes. My responsibility was to create the conditions for it to move between all of us, between developers, analysts and business teams, and from colleagues who remembered the past to those preparing what came next.
That work was not always visible in a plan or a status report, but it was essential. Organisational memory becomes weak or fragile when information still exists but nobody has enough time, curiosity or commitment to make sense of it.
How much knowledge does an organisation really have when no one can tell its complete story?
And how safely can we transform a system that we still depend on, but no longer fully understand?
Taking responsibility for more than code
When a team takes responsibility for a long running application, the software is only the visible part. What comes with it is a history of decisions.
Some were deliberate architectural choices. Others were made because the business needed an urgent solution, a regulation changed or another system imposed a limitation. A few were introduced as temporary measures and stayed for much longer than anyone expected.
After many years, it can be difficult to separate what is still necessary from what simply survived. A rule that looks unnecessary may be protecting a rare but important use case. A process that appears too complicated can make more sense once the systems and responsibilities around it are understood.
Business users naturally asked why the system still worked in a certain way, why a rule remained in place or whether a process could be simpler. They were right to ask. An application should not be protected from change simply because it has existed for a long time. Some rules had lost their purpose, and some processes needed to evolve.
The difficult part was that the team answering those questions had not created many of the rules. Sometimes we had to explain a decision made ten or fifteen years earlier with only part of the original context, defending rules the team didn’t created or even trying to prove the value of behaviours that everyone had relied on until the moment they were questioned. It could feel as if the current team was being judged for the entire history of the application.
In those moments, even a committed team can feel as if it is facing the waves alone.
Not because people disagree, because disagreement is often necessary, but because the line between challenging a system and challenging those who care for it can become surprisingly thin.
This is where leadership became important. I had to protect the team while we investigated those decisions honestly. Questions about the application could not become unfair judgements about the people supporting it. At the same time, protection could never mean using the past as an excuse to avoid change.
There were meetings where I had to slow the discussion down. Before deciding that something was wrong, we first needed to understand why it existed. Once we understood it, we also had to be ready to say that it was no longer needed.
The business had every right to question the existing process. The technical team also deserved respect for its knowledge and commitment. My responsibility was to keep both sides in the same conversation, absorb the pressure and make sure that the team could investigate without becoming defensive or silent.
That kind of pressure is not always visible. When an application works every day, its strength can appear ordinary. Users see the result, but they don't always see the controls, exceptions and small decisions operating underneath. Much of that value becomes visible only when a replacement or redesign begins.
A new platform can look simpler until the first hidden exception appears. A process can seem complete until a rule that nobody mentioned becomes essential. This is often the moment when the organisation finally sees how much knowledge the existing system and the people supporting it have been carrying quietly.
The same applies to support. Teams responsible for long-running applications are often remarkably fast. They recognise patterns before an incident is fully described. They know already where to look. They can sometimes predict the consequence of an action because they have seen the system respond in similar circumstances before. A business user may remember an exception that has not appeared for years.
Over the years, I saw that much of this speed didn't come only from tools or procedures. It came from having seen the application behave under many different conditions. Technology can be deployed quickly. Operational intuition takes time.
I considered it part of my responsibility to make that experience visible, especially because it is difficult to represent in reports. The number of incidents closed doesn't explain why someone recognised a risk before anyone else, or why a developer questioned a result that looked technically correct.
New teams need time to build that judgement. This is normal and says nothing negative about their competence. Experience develops through incidents, decisions, mistakes avoided and behaviours observed over time.
The application carried the same kind of history. The code could show what happened, but it didn't always explain why. That explanation was often spread across emails, old discussions, technical constraints and people who remembered one part of the journey.
Over time, knowledge changes form. What starts as a shared decision may later become a procedure, then a line of code and finally a behaviour that nobody feels safe enough to remove.
Recovering the reason behind that behaviour became part of our daily work. We found it while investigating incidents, preparing changes, speaking with former users or comparing an old email with what the application was doing today.
Sometimes the answer confirmed that the behaviour still had value. Sometimes it gave us the confidence to remove it. The difficult judgement was knowing the difference.
How much of a system should be preserved because it still carries business value, and how much remains only because nobody can yet prove that it is safe to let it go?
Changing what you do not fully understand
There are moments when knowledge has to grow at the same time as change. An organisation cannot always wait until every dependency has been identified, every old decision reconstructed and every uncertainty removed.
Sometimes the deadline already exists. A new integration must be delivered. A sensitive component needs to be refactored. A technology is reaching the end of its supported life and has to be replaced. The application, the business and the organisation continue to operate while the team prepares to change part of the foundation beneath them.
Waiting for complete certainty would have created its own risk. Moving without understanding the consequences would have been equally irresponsible. We had to find a practical balance and keep reviewing it as the work moved forward.
We lived this while delivering a new integration, refactoring a sensitive component and replacing technology that could no longer support the future of the application. Each initiative had a clear technical objective, but the real boundaries were never as simple as they first appeared.
An integration is more than an exchange of data. It also carries assumptions about timing, ownership, failures and which system should be trusted when information doesn't match. A refactoring may affect sequence, error handling or a dependency that another process has quietly used for years. Replacing unsupported technology also raises a basic question about which old behaviours should still exist in the new environment.
The deadline did not remove these questions. It made them more urgent. Under pressure, there is a temptation to reduce the problem until it fits the available time. An interface becomes only an interface. A component looks isolated because nobody has yet found the connection. Equivalent technology is expected to produce an equivalent system.
Sometimes those assumptions are correct. Sometimes one of them becomes the next serious problem.
I made one expectation clear from the beginning. Pressure could not reduce the care we gave to the work. The team shared that commitment.
We stayed with difficult questions when the first answer was not enough. We investigated behaviours that didn't immediately make sense. We looked beyond a technically correct result and asked whether the application was still behaving as the business expected.
Our goal was never to resist change. It was to understand what each change might disturb and make the remaining uncertainty visible enough to manage.
We traced dependencies, challenged our own assumptions and tested not only whether the new solution worked, but whether the surrounding processes continued to behave as expected. We also listened when something didn't feel right, even if the first technical indicators looked fine.
Experience sometimes appears in small observations. A delay that should not be there. A result that is technically correct but doesn't fit the normal business flow. A behaviour that passes the test but makes the application respond differently from what the team has seen for years.
These signals are easy to dismiss when time is short. They may also be the first warning available before all the evidence exists.
Leadership under uncertainty moments meant creating enough space for uncertainty to be expressed without being treated as weakness. A developer had to be able to say that the integration worked but that one interaction still caused concern. A business user had to be able to say that the result was correct while the process no longer felt the same.
As a Project Manager, sometimes I had to slow down or pause a decision, explain why one more test or discussion was necessary and remain accountable for the deadline. Those choices were not always easy or comfortable, especially when more verification could easily be seen as delay.
There were also moments when further analysis would not remove every risk. At that point, responsibility meant accepting what remained, making the decision and moving forward. Leadership under uncertainty requires both forms of judgement. You need to know when the team has to investigate further and when enough has been learned to continue.
The team didn't always look to me for an immediate answer. They looked for the assurance that we could continue searching without losing direction. This is a different kind of responsibility. I had to carry the pressure without pretending that certainty existed, protect the team's judgement when speed starts to sound more important than understanding and still make sure that uncertainty didn't become a reason never to decide.
One of my roles, among many, was to keep three components moving together: the delivery, the confidence of the team and the protection of the organisation. None of them could be treated as optional. A deadline could not be protected by silencing the people responsible for meeting it. The organisation could not be protected by allowing every doubt to stop progress.
How do you ask a team to move faster without teaching it to ignore what feels wrong? That question stayed with me throughout the work.
Too much caution can stop change. Too much confidence can hide risk until it reaches production. We had to move with enough discipline to protect what already worked and enough courage to change what could no longer remain as it was.
The responsibility is to move with enough discipline to protect what already works, and enough courage to change what can no longer remain as it is. We did the move. The integration was delivered, the component was refactored and the technology transition was completed successfully.
When I reached that point, I felt relief, of course, but also pride in how the team reached that point. We had crossed uncertainty together without allowing pressure to divide us, silence important questions or reduce the care we gave to each decision. I am very proud not only what we delivered but also on how we delivered it.
The service continued, the organisation was protected and the technology moved forward. At the same time, every dependency we uncovered and every assumption we challenged improved our knowledge of the application.
A change can make technology newer without making the system clearer. It can also reduce the distance between what the system does and what the organisation understands about it.
What does successful delivery really mean if the technology changes, but the organization learns nothing from the transition?
Technology can change within a defined schedule. Understanding develops through investigation, questions, decisions and mistakes avoided while the people involved still remember the context.
One day, another team will take responsibility for what we leave behind. They may see the new integration, the refactored component or the modern technology. They should also be able to see the reasoning, the risks and the decisions that made the transition possible.
Modernising without losing meaning
Eventually, maintaining a system is no longer enough. A technology reaches the end of support, an architecture can no longer meet the organisation's needs or a dependency becomes too fragile. At that point, the cost of continuing begins to compete with the risk of changing.
From a distance, modernisation can look simple. Replace the technology, build the new solution, move the data, connect the systems and decommission what came before.
A long running application cannot be reduced to the technology on which it runs. Its screens and interfaces may be visible, and its processes may be documented, but much of its real value sits in the exceptions it recognises, the sequence it protects and the controls that users no longer notice because they have always been there.
A system can become so reliable that the organisation stops seeing what it quietly prevents. The invisible often becomes visible only when someone tries to replace it.
A rule that appeared unnecessary protects a rare situation. A manual action contains a decision that was never formally written. A simple field carries a meaning that cannot be understood from its name. A process that looks inefficient reflects responsibilities spread across several teams and systems.
Modernisation reveals the application, but it also reveals the organisation to itself.
It shows where responsibilities were never fully clear, where processes changed without being formally redesigned and where technology had been compensating for business decisions that were never completed.
This is why replacing a system cannot mean rebuilding everything exactly as it exists. Some behaviours should continue, some should be redesigned and others belong to a reality that no longer exists. There may also be behaviours that remain essential even when nobody immediately remembers why.
The hardest question is therefore not whether the new solution can reproduce the old one. It is what the organisation should deliberately carry forward and who is prepared to take responsibility for that choice.
These decisions are not purely technical. Technology can implement a rule, but it cannot decide whether the rule still reflects how the organisation wants to work. A development team can identify a dependency, but it cannot decide alone whether that dependency represents a valid business need or an old compromise.
Modernisation needs judgement. The business must look again at processes that have become so familiar that nobody questions them. Technical teams must explain the consequences of change without using technical history as an automatic argument against it. Leaders have to bring both sides together and keep the decision clear.
I never believed that the existing application had to be defended at any cost. I also never accepted that replacement automatically meant progress. Organisations need to change. Technologies reach their limits, priorities move and decisions sometimes have to be made beyond the interests of one application, one team or one project.
My responsibility was to support that change while making sure that the organisation did not ignore what it had already learned. A request to preserve a behaviour may be resistance, but it may also be knowledge protecting something important. A request to simplify may overlook the past, or it may be the right decision for the future. The challenge is to understand which situation we are facing.
There is also a responsibility towards the team supporting the current application. When attention moves towards the future, everything linked to the existing system can start to sound like part of the problem. The old becomes outdated and the new becomes strategic.
At exactly that moment, the people who kept the application working through years of change may become less visible, even though their knowledge is needed more than ever.
A replacement project cannot treat the existing team only as part of the past. They know where the application bends without breaking. They remember which unusual behaviours are intentional. They can see where a technically elegant solution may collide with daily operations.
Their role should go beyond documenting the old system. Their experience can help the organisation decide what the new one needs to become.
This leads to an important choice. Experienced teams can be used mainly as sources of information, or they can also contribute to the decisions about what should be preserved, redesigned or left behind. I always favoured the second approach. It asks more of everyone, but it creates a stronger transfer of understanding and responsibility.
A document can explain a rule, a diagram can show a dependency and a process can describe a sequence. None of them can fully replace the judgement built through years of incidents, decisions and consequences.
Modernisation also requires humility. The existing system is not always right because it has survived, and the new system is not automatically better because it is new.
A modern platform can reproduce old complexity with more speed and a better interface. It can carry forward rules nobody understands, dependencies nobody questioned and processes nobody consciously chose.
The technology may be modern. The legacy may remain.
That is perhaps the most uncomfortable possibility. An organisation can replace the application, update the architecture and complete the migration while keeping the same distance between what the system does and what the organisation understands.
Because replacing technology changes the platform. Understanding changes what the organisation can build next.
What remains
For years, the application carried more than processes, data and technical rules. It carried memory in the form of accumulated judgement.
It carried the reason why one exception mattered, why one sequence could not be changed casually and why one apparently inefficient step protected something that was no longer visible. It also carried the experience that allowed a team to recognise a problem before a monitoring tool raised an alarm.
Some of that memory was written. Some was built into the application. Some lived in people who had spent years listening to its signals. Other parts appeared only when change forced us to look again.
This may be why the word legacy is so often misunderstood. We use it to describe something from the past, but the application was still operating in the present. People depended on it, decisions were made around it and its consequences would continue into the future whether we understood them or not.
Age alone does not explain that responsibility. A system may be old and still be well understood, well governed and safe to evolve. Another may use recent technology and still carry rules, dependencies and decisions that nobody can fully explain.
The real question may not be how old the system is.
It may be how far the organisation has moved away from understanding what the system still does for it every day. That distance does not appear overnight… it grows quietly (one person leaves, one decision remains in an email, one temporary solution survives another year, one process changes, while the code continues to reflect the reality that come before it).
Eventually, the system may remember more than the organisation does.
Then modernisation begins, sometimes because of strategy, sometimes because of ambition and sometimes because time has simply run out. Replacing the technology doesn't remove the responsibility. It makes the missing understanding more visible.
Looking back, I don't remember only the technologies we changed, the integrations we delivered or the deadlines we met. I remember the moments when the team stayed together under pressure, when someone had the courage to express a doubt and when we chose to investigate one more time.
I also remember the moments when we had enough information, accepted the remaining risk and made the decision to move. That part matters too. Leadership is not only about asking more questions. It is also about knowing when the team must move forward and accepting responsibility for the choice.
Methodologies gave us structure. The difficult moments changed and shaped the way I understand leadership.
For me, courage doesn’t mean being fearless, it means moving forward without hiding what we don't know. Discipline was not following the plan at any cost, it was protecting the purpose of the work when the original plan was no longer enough. Resilience was visible in the way the team stayed together after difficult moments, ready to face the next wave. Loyalty was not defending every part of the past, it was protecting the organisation, the users, the team and the knowledge needed for what came next.
A Project Manager cannot control every wave or remove every uncertainty. No team can carry the full memory of an organisation forever. However, we can decide how we face uncertainty, we can decide whether questions are welcomed or discouraged, whether experience is respected or simply collected and whether knowledge is passed forward or left behind.
We can also decide whether change makes the organisation only newer or also stronger.
Every legacy application tells two stories. The one written in code. And the one carried by people, until they leave.
Our responsibility today is to understand what matters in those stories, lead people through uncertainty and decide what the next story should be.