Before You Change a System, Understand Why It Became This Way

When an organisation decides that an old system needs to be replaced, attention tends to move quickly toward the future. What should replace it? What architecture should we use? Which technology is appropriate? How long will implementation take, and what will it cost?

Those are necessary questions. But in complex legacy transformation, I think they are often asked too early.

The first architectural risk is not necessarily choosing the wrong technology. It is designing the future state before the organisation has properly understood what the current state is actually doing.

Before I want to discuss architecture, I want to understand how we arrived at the current environment. What business problems was it originally solving? How has it changed since then? Which processes now depend on it? What information is genuinely critical? What happens downstream if a particular capability disappears? And, perhaps most importantly, which parts of the current environment still deserve to exist in the future?

For me, this is one of the most consequential early stages of transformation. It is where business analysis, operational knowledge and technical decision-making begin to meet.

Legacy systems are usually the result of history, not a single design decision

It is easy to look at a legacy system from today’s perspective and conclude that it was badly designed. Sometimes that assessment is justified. But often the more useful question is why the system became that way.

Many long-lived systems began as reasonable responses to immediate business problems. A team needed something the existing environment could not provide quickly enough. A local solution emerged. It solved the problem, so another requirement was added. Then another. More people began relying on it. New processes developed around it. Information started being used for purposes that were never part of the original design.

The system grew because the business kept asking more of it.

Over time, tactical decisions can become structural ones without anyone explicitly deciding that this should happen. What was once temporary becomes operational. What was once local becomes shared. What was once a small convenience becomes embedded in a wider process.

Years later, the organisation sees complexity. But that complexity is often accumulated business history.

This distinction matters because it changes how I approach replacement. If I assume that everything in the current environment is simply poor design, I risk removing things I do not yet understand. If I assume that everything exists for a good reason, I risk reproducing years of historical baggage in a newer technology stack.

Neither is a good transformation strategy.

The first task is to reconstruct enough of the current operating environment to distinguish between the two.

Business analysis is not requirements collection

In complex system transformation, I see business analysis less as a process of asking users what they want and more as a process of reconstructing how the business actually operates.

The difference is substantial.

Traditional requirements gathering can easily become future-facing: tell us what you need the new system to do.

But if the existing environment has evolved over many years, the organisation may not yet know enough to answer that question properly. Documentation may be incomplete or out of date. Processes may have changed without the documentation changing with them. Business rules may be embedded in system behaviour. Dependencies may exist outside the obvious user group. Some functionality may be understood only through the way people use it.

In that situation, the current system itself becomes part of the evidence.

The analysis has to establish what the environment actually does, how information moves through it, which business processes depend on it, what happens when particular capabilities fail, and where the consequences appear downstream.

This is not purely a business exercise, and it is not purely a technical exercise.

A business analyst may identify that a particular piece of information is required for an operational decision. A technical team then needs to understand where that information originates, how it moves, what consumes it and what reliability the future architecture must provide. A downstream dependency discovered during business analysis can change an integration design. A distinction between operational and analytical use can change the target data architecture. A process that turns out to be obsolete can remove an entire piece of planned scope.

That is why I am reluctant to separate “the business part” and “the technical part” too neatly at this stage. The quality of the technical solution depends heavily on the quality of the business understanding underneath it.

Architecture should not be expected to compensate for an incompletely understood problem.

The first priority is understanding what cannot fail

The difficulty is that analysis can continue indefinitely.

In a sufficiently complicated legacy environment, complete knowledge may be impossible before work on the future state begins. Waiting for perfect understanding can become its own form of paralysis.

The question is therefore not whether we understand everything. It is whether we understand the most consequential parts well enough to start making responsible decisions.

That requires a definition of criticality.

I would not define something as critical simply because people use it frequently or strongly prefer it. Criticality should be defined by business consequence. A capability becomes critical when its loss interrupts core operations, prevents a time-sensitive decision, or causes material failure further downstream.

That immediately gives the discovery process an order.

First understand what the organisation cannot afford to lose. Understand the core processes, the information they require, how that information is consumed, and what depends on it. Once those elements are sufficiently clear, the first technical decisions can begin.

I use “sufficiently” deliberately.

In real transformation work, there is rarely a clean handover where analysis reaches 100 percent and the technical teams then begin. Discovery continues while architecture is being shaped. New information appears. Previously invisible dependencies become visible. A process that initially appeared secondary may become more important once another part of the legacy environment is removed.

The challenge is to design the programme so that this continued learning is expected rather than treated as failure.

This is where modular architecture, phased delivery and scope discipline become important. If the technical design assumes that all requirements are fully known on day one, late discovery becomes expensive. If the architecture allows capabilities to be separated and introduced progressively, the programme has more room to incorporate what it learns.

The business-analysis strategy and the technical strategy therefore cannot be designed independently.

Understanding the current state is not the same as preserving it

There is another trap.

After investing substantial effort in reconstructing what the existing system does, teams can become reluctant to remove anything. Everything discovered starts looking like a requirement for the replacement.

That can produce a technically modern system carrying almost exactly the same responsibilities, complexity and historical compromises as the one it replaced.

I do not see that as transformation.

The purpose of understanding the current environment is not to reproduce it faithfully. It is to create enough evidence to decide what should be preserved, what should be redesigned, what belongs elsewhere and what should disappear.

One of the most useful distinctions in that process is between operational and non-operational information.

Operational information exists to support the work that has to happen now. It is required to execute a process, make a time-sensitive decision or maintain a core operational capability. Its availability, reliability and integration requirements therefore belong directly in the design of the operational environment.

Other information can be extremely valuable without being operational. Historical information may be needed for modelling, analysis, reporting or wider business decisions. That does not make it less important. It means it serves a different purpose.

If those two categories are mixed simply because they happened to coexist in the legacy environment, the replacement can inherit unnecessary scale and complexity. The operational platform ends up carrying analytical responsibilities it does not need, while architecture is designed around historical accumulation rather than current business purpose.

Separating those concerns changes the technical problem.

The question stops being: how do we move everything into the new system?

It becomes: what does the operational environment actually need to do, and where should the rest of the organisation’s information capability sit?

That is a business decision with direct architectural consequences.

It also illustrates why requirements should be challenged rather than copied.

Existing functionality is evidence. It is not automatically future scope.

Analysis also determines the economics of the transformation

The pressure to shorten business analysis is understandable. Analysis has an immediate and visible cost. The cost of incomplete analysis remains hypothetical until it appears later in the programme.

That asymmetry is precisely why organisations can underinvest in it.

If an important dependency is discovered before architecture is finalised, it can be incorporated into the design. If the same dependency appears halfway through implementation, the consequences are different.

Scope may change. Architecture may need to be revisited. Another team may need to become involved. Additional specialist resources may be required. Integration and testing expand. Delivery sequencing changes. A deadline that once looked achievable becomes difficult.

If the deadline is externally fixed, resource pressure increases further.

This is how incomplete understanding turns into cost.

Sometimes the programme absorbs that cost directly through additional people and budget. Sometimes it absorbs it indirectly through technical compromise. There is not enough time to redesign properly, so an interim solution is introduced. An exception is created. A workaround is accepted.

The system goes live, but some of the legacy problem has simply been recreated in another form.

That is why I do not see the economics as “spend more on analysis versus start building earlier.”

The real comparison is between the cost of discovering something early and the cost of discovering the same thing late.

Good analysis also creates savings by reducing scope.

If a capability is obsolete, we do not rebuild it. If information belongs in an analytical environment, we do not force it into the operational architecture. If something creates value but is not required for the first viable release, it can be sequenced later. If an external dependency is understood early, the required team can be brought into the programme deliberately rather than as an emergency.

Business analysis therefore does not only tell us what to build.

Done properly, it tells us what not to build, when to build it and what the technical solution actually needs to support.

That information has direct economic value.

Replacement should reduce uncertainty, not transfer it

This is also why I prefer phased replacement in complex environments.

The first release should not attempt to reproduce the entire legacy landscape. Its purpose is to establish the critical operational capability safely: the core process works, the required information is available, essential downstream interactions continue, and the business can operate in the new environment.

Once that is established, part of the legacy dependency can be removed.

And something interesting happens as this progresses.

As major capabilities move away from the old environment, the smaller processes underneath them often become easier to see. What was previously hidden behind more visible functionality becomes more prominent.

Business analysis continues while delivery continues.

The organisation is simultaneously reducing dependence on the old environment and increasing its understanding of what remains.

This is not the clean sequence that project plans often imply: analysis, design, build, test, finish.

It is closer to controlled convergence.

We understand enough of the critical environment to make the first decisions. We design for what we know while allowing for further discovery. We move the most important capabilities. We learn from what becomes visible. Then we make the next decision.

For me, that is a more realistic way to manage uncertainty than either pretending everything is known before development begins or allowing requirements to remain permanently open.

Start before urgency removes your choices

There is one final reason I think organisations should begin analysing important legacy environments earlier than they typically do.

As long as a system continues to work, replacement is difficult to prioritise.

The business case is rarely attractive compared with initiatives that create visible new capability or immediate commercial value. A working legacy system can therefore survive for years precisely because it continues performing its job.

Until the moment when it no longer feels optional.

By then, urgency changes the programme. There is less time to understand dependencies, less time to reconstruct processes, less time to challenge existing functionality and less freedom to sequence the replacement carefully.

The organisation can find itself making some of its most consequential architectural decisions at exactly the moment when it has the least time to investigate the problem.

I would rather begin the understanding before that point.

That does not necessarily mean launching a full transformation years in advance. It can mean documenting critical processes, understanding key information flows, identifying major dependencies and building enough knowledge that the eventual replacement does not begin from zero.

Because once the transformation becomes urgent, time itself becomes one of the constraints shaping the architecture.

And architecture designed primarily around urgency rarely produces the same choices as architecture designed around understanding.

For me, this is the point where business and technology genuinely meet.

The business needs to explain what must continue, what creates value, what can change and what the consequences of failure are. Technical teams need to translate that understanding into architecture, integration, data design, resilience and delivery choices. Neither side can do its job properly without the other.

So before I ask what technology should replace a legacy system, I want to understand why the current environment became what it is, how the business depends on it today, and which of those dependencies deserve to survive.

Only then does the question of what to build become meaningful.

Because the objective is not to produce a technically better version of the past.

It is to make a deliberate decision about what the business needs next.