How Do You Get Out of a Big Ball of Mud?

In Refactoring, Martin Fowler shows how existing code can be structurally improved through small, behavior-preserving changes. In Working Effectively with Legacy Code, Michael Feathers shows how code that is difficult to change can be brought back under control through tests, dependency breaking, and seams that create places where behavior can be changed safely. Both remain essential tools for working with long-lived systems.

With a mature Big Ball of Mud, however, another boundary appears:

A Big Ball of Mud should never be rescued by one person alone.

This is not an empirical law of nature. It is an architectural stance.

At some point, structural erosion no longer affects isolated classes, services, or modules. It affects business behavior, historical requirements, technical dependencies, organizational boundaries, responsibilities, tests, knowledge, and release and operational processes at the same time.

One person will typically possess neither the complete knowledge, the business authority, the organizational legitimacy, nor the time required to reorder all of these dimensions alone.

You cannot rescue a Big Ball of Mud on your own. And certainly not as a side project.

That does not mean individual developers cannot make a difference. Quite often, change begins precisely because one person recognizes a problematic structure, proposes a better boundary, or creates the first controllable point of entry.

But an individual observation eventually has to become a shared decision.

A systemic problem eventually requires a shared decision.

That matters especially in a Big Ball of Mud. If the way out once again depends on an exceptional architect understanding the entire system, making every important decision, and personally ensuring that nobody deviates from the new path, the next knowledge monopoly is already being created.

The architecture may be better, but the structural dependency problem is not.

Three responsibilities instead of one hero

“Together” does not simply mean putting more developers on the problem. Ten developers without a shared direction can produce an inconsistent structure faster than two.

A sustainable reconstruction needs at least three perspectives: technical responsibility, domain responsibility, and organizational responsibility.

Technical responsibility

The technical perspective defines the direction of the reconstruction. It answers questions such as:

• Where should domain responsibilities live in the future?
• Which dependencies are allowed?
• How should domain slices be separated from one another?
• Which integration mechanisms should be used?
• Where does business state live?
• Which recurring patterns should shape new structures?
• Which problematic patterns should no longer be introduced?

The goal is not to centralize every implementation decision. It is to create rules that lead different developers, working independently, toward compatible solutions.

Domain responsibility

Technical analysis can help reconstruct what a system does today. It cannot reliably determine what the system should do tomorrow.

That requires people who are able to make business decisions.

They need to answer questions such as:

• Which business rules still apply?
• Which edge cases are genuinely required?
• Which historical behaviors may disappear?
• Which currently observable outcomes are binding?
• Which behaviors are merely consequences of old technical constraints?

In a system that has grown over many years, this responsibility is particularly important because code and domain behavior may no longer be cleanly separable.

Organizational responsibility

Reconstruction also needs organizational room to act.

Someone has to make it legitimate to invest time, make decisions, and collaborate across existing ownership boundaries.

That does not necessarily mean creating a dedicated modernization program. But even a small tactical reconstruction requires enough legitimacy to actually carry it out.

These three perspectives do not have to belong to three different people or roles. In smaller organizations, responsibilities may overlap.

They do, however, have to exist.

A Big Ball of Mud has become a shared problem. Its reconstruction therefore cannot remain the private initiative of a single developer.

Reconstructing a Big Ball of Mud requires technical, domain, and organizational responsibility. None of these perspectives can permanently replace the others.

You do not clean up a Big Ball of Mud

Local refactorings remain useful inside a Big Ball of Mud. Fowler defines refactoring as a disciplined change to internal structure while preserving externally observable behavior. The small steps and the resulting feedback are precisely what make the technique valuable.

Feathers’ techniques remain relevant as well. A problematic service can be decoupled, a class can be brought under test, a difficult dependency can gain a seam, and a local area can become easier to understand.

A mature Big Ball of Mud, however, adds another dimension: the structure of the overall system no longer explains its actual responsibilities and dependencies well enough.

The problem is therefore not merely that existing code is “ugly”. There is no longer a reliable answer to the question of which part of the system should be responsible for what.

That is why “cleanup” is too weak a word for the work that is required.

You do not clean up a Big Ball of Mud. You reconstruct it incrementally.

Reconstruction does not mean replacing the entire system in one move, nor does it mean:

old out → new build → switch over.

The idea is less spectacular and, for that reason, often more realistic:

A system that remains in production gradually regains domain and technical boundaries.

What this looks like in practice depends heavily on how much room the team actually has to act.

Two different starting positions

It is useful to distinguish between two situations.

In the first, there is no explicit mandate for broader reconstruction. The team still has to deliver features and can only make structural improvements where they are economically compatible with ongoing product work.

In the second, the organization has accepted the structural problem and is willing to fund reconstruction as planned product work.

The technical room for action differs considerably between these two situations.

Situation 1: There is no explicit modernization mandate

This is probably the more common situation in many organizations.

The product is needed. Customers are waiting for functionality. Budgets are limited. It may even be unclear how long the system will remain in service, and there may be other strategic investments with a higher expected return.

Stakeholders are therefore not automatically irrational when they decline to fund a dedicated modernization program.

For the development team, however, that also means it should not begin a hidden second project.

Systematically using feature budgets to finance a covert reconstruction of the entire system is neither transparent nor sustainable. As soon as larger effort becomes visible, the work lacks an organizational foundation.

The more interesting question is:

Can a product change that has to happen anyway become a useful cutting point for tactical reconstruction?

Suppose a new domain requirement touches a particularly problematic area. There may be two genuine implementation paths.

Option A: Implement the feature along the existing structure.

Option B: Isolate or reconstruct enough of the affected domain slice that the feature can then be implemented within a more robust structure.

Both options need to be estimated honestly.

If extending the existing structure costs around 20 person-days while a meaningful reconstruction costs 60, the economic decision will often be entirely understandable: implement the feature in the existing system for now.

Architecture does not have a right to override every other product priority.

The situation is different if both options fall into roughly the same effort range. Perhaps a direct extension takes 25 days while a controlled separation and subsequent implementation takes 30 or 35.

Then there is a real decision to make.

For the stakeholder, the primary goal remains unchanged: the required feature should be delivered reliably within an acceptable timeframe. If, however, a similar amount of effort can also create a robust domain boundary, that option deserves deliberate consideration.

And it should not be decided by one developer alone at their desk.

When extension and reconstruction are economically close, the responsible group should consciously decide which path to take.

This is where experienced developers and technical owners need to come together. Not to create an architecture committee for every line of code, but because the future structure of the system gradually emerges from many such decisions.

When a change is required anyway, it can be useful to compare extension and tactical reconstruction as two real implementation paths.

Architecture guidelines before opportunistic reconstruction

Tactical reconstruction has an obvious danger: many local improvements do not automatically add up to a better overall architecture.

Developer A may introduce a new domain store while developer B prefers services, developer C establishes an event bus, and developer D adds another facade layer. Each solution can be locally plausible; together they can still create the next system whose rules nobody can explain precisely.

A Big Ball of Mud does not become healthy merely because every developer adds their personal idea of good architecture to it.

That is why a small, shared target model should exist as early as possible.

This does not mean a one-hundred-page enterprise architecture document. In a system with high change dynamics, such a document would quickly become another historical artifact.

What is needed are a few rules that actually help with concrete decisions, for example:

• Where do domain responsibilities live?
• In which direction may dependencies point?
• How do domain slices communicate?
• Where does business state live?
• Which integration mechanisms are preferred?
• Which patterns should no longer be introduced in new areas?
• How are external systems integrated?
• Which rules must be reproducible regardless of the individual developer?

These guidelines may evolve, and they do not need to cover every edge case from the beginning.

Their purpose matters more:

Tactical reconstruction needs a shared direction. Otherwise a Big Ball of Mud merely turns into several new islands.

The goal must specifically not be to create a new architecture hero who personally reviews every pull request.

A robust architecture rule is one that multiple people can understand and reproduce.

If only one person knows why the new structure works, the system may be technically cleaner while remaining organizationally fragile.

Build new features along the target model — where a real boundary is possible

New functionality should not automatically continue to grow into the same old structures.

Where a robust domain boundary can be created economically and technically, a new feature is a good opportunity to establish it.

This advice is easy to oversimplify.

“Never touch the legacy and just build the new code cleanly next to it” sounds attractive. In a mature Big Ball of Mud, that may be impossible.

Business state may be distributed globally across several services. Workarounds may couple otherwise unrelated areas. Supposedly independent features may share the same data structures. An implicit event may trigger behavior in three other places that nobody has documented.

In that situation, a new directory called

features/new-feature

may look clean without creating a real boundary.

A boundary that looks clean on the new side but has to reach deep into the Big Ball of Mud for every domain operation is not yet a robust boundary.

Sometimes the first useful reconstruction step is therefore not implementing an entirely new slice.

The team may first need a controllable integration point.

This is where Feathers’ concept of a seam becomes useful: a place where behavior can be altered, or a dependency separated, without changing all surrounding code at the same time. The concept originated in the context of legacy code and testability, but it is also a useful way to think about controlled transition points.

Sometimes the first result of reconstruction is not a new feature slice. It is merely the first reliable boundary at which one can later emerge.

That is progress too, even if it is less spectacular than introducing a new directory structure.

Situation 2: Stakeholders consciously support the reconstruction

The second starting position changes the room for action fundamentally.

Management, product management, or other responsible stakeholders have accepted that the system has a structural problem and that further change is still necessary. Reconstruction may now be planned, prioritized, and funded deliberately.

In that situation, simply doing “more refactoring” is not enough.

Treat the reconstruction like product development.

That means starting from meaningful domain slices rather than technical files or layers.

For such a slice, requirements are confirmed, relevant existing behavior is understood and protected, a target boundary is defined, and responsibility is then moved deliberately to a new implementation.

Only when the new path carries the responsibility should the old path disappear; after that, the next slice follows. This may sound slower than building one large new system next to the old one, but this limitation of scope is exactly the point.

Strangler Fig: do not take on all uncertainty at once

Martin Fowler described the Strangler Fig Application in 2004 as an alternative to replacing an important system in one large cut-over. The metaphor comes from strangler figs that grow around a host tree and gradually take over its role. In his original description, Fowler emphasized reduced risk, earlier value, and the ability to observe progress through frequent releases. His 2024 revision places the idea explicitly in the broader context of incremental legacy modernization.

For a Big Ball of Mud, Strangler Fig is less interesting as a fixed implementation recipe than as a fundamental way of thinking:

Limit the size of each individual bet.

A slice should be small enough for the team to understand its relevant business behavior. Its requirements need to be confirmable, its result testable, and the transfer observable. A failure should not automatically endanger the entire modernization effort.

Strangler Fig does not guarantee success. It limits the amount of uncertainty a team has to take on at the same time.

This differs fundamentally from an approach in which old and new exist for years as two complete worlds.

With a strangler approach, the team does not wait until an entire replacement system is eventually finished. Instead:

Responsibility moves slice by slice.

For example, a domain process may first be routed through a newly created seam to a new implementation. Once the new path has taken over successfully, the legacy system no longer owns that process and the old path can be removed. Only then does the next slice follow.

The principle has costs of its own. Old and new structures coexist temporarily, routing or other integration mechanisms are needed, data may have to be synchronized or migrated incrementally, and transitional states can temporarily create more complexity rather than less.

A name does not make these costs disappear.

Strangler Fig is therefore not universally ideal. Some technical or business systems are difficult to divide meaningfully, some data migrations have hard consistency requirements, and some products are so close to end of life that major structural investment simply makes no economic sense.

For a Big Ball of Mud, however, the principle is particularly valuable because it avoids one dangerous assumption: that the entire system first has to be understood and then reordered in one large move.

With the Strangler Fig approach, responsibility moves incrementally. Every slice that has been successfully taken over reduces the remaining legacy surface.

Why I would be very cautious with a large cut-over

Replacing an entire system in one large cut-over is not impossible. There are situations in which it can be justified technically or organizationally.

With a Big Ball of Mud, however, it should be a consciously justified exception rather than the default approach.

The strongest reason is not a failure statistic.

A full replacement has to reconstruct a body of functionality while the productive legacy system continues to live.

The existing product is normally not frozen while the replacement is being built. It still needs security fixes and bug fixes, regulatory changes may appear, customers may need urgent adjustments, and sometimes entirely new features are added.

Every such change creates a synchronization problem. If a new requirement is implemented only in the legacy system, old and new drift apart; if it is implemented in both, at least some work is duplicated; if it is implemented only in the future system, today’s production system receives no benefit.

A big-bang replacement does not merely have to reconstruct the known state of a system. It has to catch up with a system that keeps changing while the replacement is being built.

The longer a full replacement takes, the more its functional target can move.

A recent empirical study provides useful, but deliberately narrow, evidence. Jørgensen, Nereng, and Torrissen asked 76 Norwegian software professionals about their most recent IT-system decommissioning initiative. The decommissioning and replacement initiatives in the sample lasted 5.5 years on average. Among initiatives that aimed to fully replace an existing system, 44 percent did not actually succeed in decommissioning the old one and instead continued to operate old and new in parallel. The authors also report that failures were closely associated with big-bang replacement of COBOL systems more than twenty years old. In the same sample, a stepwise replacement-based decommissioning process was associated with higher success rates.

Those 44 percent are not a general failure rate for big-bang projects. The study covers a specific sample, one country, and heterogeneous decommissioning contexts. Its analyses describe associations rather than universal causal laws.

It does, however, fit the structural concern: the more responsibility that has to move at once, the more uncertainty a program has to control simultaneously.

My recommendation is therefore deliberately narrower:

With a Big Ball of Mud, a big-bang replacement should be a consciously justified exception, not the default approach.

Requirements engineering is not a side issue

The hardest question in a reconstruction may not be:

How do we implement the new slice?

It may be:

What is it actually supposed to do?

A Big Ball of Mud does not simply contain “the requirements”.

The existing code may contain current business rules, historical rules, obsolete rules, bugs, workarounds, technical constraints, and behavior that emerged accidentally.

There is also a particularly uncomfortable category: behavior that may never have been intended originally, but that customers, other systems, or operational processes now depend on.

That is why “just rebuild it exactly as it is” is not a sufficient requirement.

Legacy code is an important source of evidence, but it primarily answers:

What does the system do today?

It does not reliably answer:

What should the system do tomorrow?

This distinction is not new in requirements-recovery research. Liu, Alderson, and Qureshi described requirements recovery for legacy systems in terms of observed system behavior, different stakeholder perspectives, and the business context. Their 1999 work is old and should not be treated as a universal modernization method, but it reinforces an enduring point: the business meaning of a legacy system cannot be recovered from technical artifacts alone.

For reconstruction, this means:

The business side has to take responsibility again for the domain truth.

It has to decide which rules still apply, which edge cases are genuinely relevant, which historical properties may disappear, and which outcomes remain binding.

The code may be evidence.

It should not automatically become the specification.

When reconstructing legacy code, you need two truths: the technical truth about what the system does today, and the domain truth about what it should do in the future.

Those truths may match, but they do not have to.

That is why requirements engineering is not documentation work at the edge of reconstruction. It is part of the architectural work itself, because before a new boundary can permanently take over responsibility, the team has to know which responsibility it is supposed to take over.

Protect business behavior, not the old implementation

That makes the test strategy important as well.

This section is explicitly not an argument against unit tests.

Reconstructed code should of course use unit, integration, component, or other tests wherever they are useful. A clean new domain model still benefits from fast and precise tests of small rules.

For the displacement of a legacy slice, however, another kind of test often has greater strategic value: one that protects relevant business behavior independently of the internal implementation.

The internal implementation may be exactly what is meant to disappear.

Classes may be removed, services cut differently, state management replaced, module boundaries moved, and algorithms exchanged.

Tests that are tightly coupled to those implementation details may legitimately disappear with them.

What must not disappear accidentally is confirmed business behavior.

For that reason, business-facing end-to-end or acceptance tests are particularly valuable as preparation for reconstruction.

Here, “end-to-end” does not necessarily mean an enormous Selenium, Playwright, or Cypress suite that automates every mouse movement through the UI.

It means:

A business-relevant scenario is exercised from a stable entry boundary to an observable business outcome.

Suppose a system processes contracts.

Given a business starting state X, when process Y is executed, the system must end in state Z, persist the corresponding result, and — where relevant — expose observable business effect A.

For a frontend feature, the appropriate entry boundary may indeed be the browser; for a domain backend process, a useful test may instead look more like:

API → domain processing → persistence / observable outcome

The important thing is not the tool, but the boundary.

The test should protect the feature slice, not its current implementation.

Characterization is not yet acceptance

A distinction from legacy work helps here.

Feathers uses characterization tests to capture the actual behavior of an existing system. They are particularly useful when original requirements are missing or nobody is quite sure which edge cases occur in practice. His book places them in the larger task of getting a legacy system under control before making riskier changes.

During reconstruction, however, characterization should not automatically become acceptance.

Characterization answers:

What does the existing system actually do?

Acceptance answers:

Which behavior should remain valid after reconstruction?

There is a domain decision between those two questions.

A historical bug does not become a business rule simply because it has been in production for twelve years. At the same time, unusual behavior may have become part of an external contract that a customer, an integrating system, or an operational process depends on.

A sensible path therefore does not go directly from legacy code to new implementation. It is closer to:

Legacy code → observed behavior → characterization → domain evaluation → confirmed requirement → acceptance / E2E test → new implementation

E2E tests do not replace requirements engineering. They make confirmed requirements executable.

That is what allows them to become an outer safety boundary for reconstruction.

Reconstruction should not preserve the old implementation. It should preserve the business behavior that has actually been confirmed.

Put the safety net in place before reconstruction

Timing matters.

Business-facing acceptance tests are most valuable not after the new implementation has already been completed, when the only remaining question is whether the team built something roughly equivalent.

For controlled reconstruction, the relevant scenarios should, as far as possible, be understood before the slice is cut out of the old structure.

This creates a safety boundary before the legacy code is changed.

That does not mean every last business rule has to be known upfront. A Big Ball of Mud will reveal additional edge cases during the work.

But before a slice takes over responsibility, the team should know as clearly as possible which business behavior it has to defend.

Those scenarios need confirmation from the business side.

Only then can they become something close to a contract between the old and new implementation.

Before a slice is reconstructed, it should be as clear as possible which business behavior the new implementation must defend.

This helps avoid two opposite mistakes: blindly preserving every historical quirk, or accidentally replacing relevant behavior with a technically cleaner interpretation.

Do not slice by folders

The next slice should not be chosen because one particular directory in the repository looks especially ugly.

In a Big Ball of Mud, technical structure is precisely what can no longer be trusted as a reliable indicator of domain boundaries.

A good candidate should, where possible, have a comprehensible business purpose, a recognizable entry boundary, and an observable business result. It should also be small enough for the team to understand and take over in a controlled way.

Different factors may influence the choice:

• current feature work,
• economic value,
• frequency of change,
• known pain points,
• technically available seams,
• risk,
• dependencies on other areas.

This should not be turned into a universal scoring model. Which slice makes sense first depends heavily on the concrete system.

Some Big Balls of Mud do not initially have any sufficiently robust domain boundaries at all.

In that case, creating a region that is controllable enough to support a later cut is the first task.

Reconstruction as a sequence of small product decisions

With an explicit mandate, this can become a recurring operating model.

Not as a universal method, but as a way of thinking:

1. Identify a domain slice.
   Start from a responsibility that can sensibly be taken over rather than from files.
2. Confirm requirements with the business side.
   Clarify which rules, outcomes, and edge cases should actually apply in the future.
3. Understand relevant current behavior.
   Code, logs, existing tests, documentation, user knowledge, and observed production behavior may all be needed.
4. Prepare business-facing acceptance / E2E tests.
   Make confirmed target behavior executable as independently as possible from the internal structure being displaced.
5. Define the target boundary using shared architecture guidelines.
   The new slice should not merely look clean locally; it should become part of the same future architecture as the other reconstructed areas.
6. Create the required seams and integration points.
   Change only as much legacy structure as needed to move responsibility in a controlled way.
7. Reconstruct the implementation.
   Inside the new boundary, use suitable technical patterns and tests.
8. Route traffic or responsibility to the new path in a controlled way.
   The transition should be observable and, where feasible, reversible or at least bounded.
9. Observe and validate behavior.
   Automated tests matter, but they do not replace observing the real system.
10. Remove the old path.
    The previous implementation must not remain permanently as a second source of truth.
11. Choose the next slice.
    Only then should the team take on the next bet.

The exact order can vary. Some activities overlap, characterization may reveal that the originally planned slice is too large, or a technical dependency may force the team to create another boundary first. What matters is not strict process compliance but that each step produces a manageable, verifiable intermediate state.

The old path eventually has to disappear

One uncomfortable step is easy to postpone in strangler-style modernization: actually removing the old implementation.

The new feature works, the new service is running, and the new slice is in production. Why take another risk and delete the old code?

Because otherwise responsibility has not moved.

It has merely been duplicated.

If both paths remain indefinitely, new questions appear:

• Which implementation is authoritative now?
• Do both have to be changed?
• Are their data still synchronized?
• Who owns which version?
• Which tests apply to which path?
• When can the old implementation finally disappear?

Modernization can then paradoxically increase the amount of system without materially reducing the legacy surface.

A reconstruction is only complete when the old responsibility has actually disappeared.

Not every transitional bridge can be removed immediately. Some have to survive several releases.

But removal has to be part of the work package.

Otherwise “later” is merely another word for “probably never”.

What “not as a side project” actually means

At this point, an apparent contradiction emerges.

On the one hand, the guiding statement is:

You cannot rescue a Big Ball of Mud on your own. And certainly not as a side project.

On the other hand, for organizations without a dedicated modernization program, the article recommends using necessary feature work as a possible point for tactical reconstruction.

These ideas do not conflict.

“Not as a side project” does not mean:

Every structural improvement needs a separate million-euro program.

It means:

Structural reconstruction must not be treated as an invisible private extra task performed by individual developers.

If a feature is used as an opportunity for reconstruction, that decision needs to be visible, jointly supported, economically understood in the feature context, and implemented according to shared rules.

That is fundamentally different from:

“I will just refactor the system a little more in the evenings.”

One reason a Big Ball of Mud can survive for so long is that exceptional individuals repeatedly compensate for structural problems.

If the same mode of compensation becomes the modernization strategy, the principle has not changed. Only the direction of the heroic effort has.

And what if the organization does not support it?

Even without a mandate for a broader modernization program, technical room for action remains.

The team can identify small tactical work packages, experienced developers can establish common guidelines, necessary feature work can become a possible cutting point, extension and reconstruction can be estimated as genuine alternatives, and changes can be kept small and verifiable.

That room for action is not meaningless. Over years, such decisions can create genuinely robust areas.

But there is a limit.

There is no refactoring trick that allows a development team to permanently compensate for missing organizational mandate.

If structural work is categorically disallowed, no additional delivery time is accepted, and every change is evaluated solely by the cheapest short-term implementation path, the technical room for reconstruction is limited as well.

That is not automatically a judgment of the organization. Its priorities may be economically understandable.

It is simply a diagnosis of what can realistically be achieved under those conditions.

One person cannot replace that mandate.

And that brings the argument back to where it started.

Conclusion

Local refactorings and the techniques described by Fowler and Feathers remain important tools for working with long-lived systems. A Big Ball of Mud can, however, reach a level of scale and systemic entanglement where many independent improvements do not automatically recreate a coherent overall architecture.

At that point, what is needed is incremental reconstruction along domain slices, a confirmed understanding of the behavior that should be preserved, and acceptance or E2E tests that protect that behavior independently of the old implementation. Shared architecture guidelines help different developers create compatible parts of the same future structure, while organizational time and legitimacy provide the room to make those decisions explicit rather than private.

Strangler Fig offers a particularly useful mental model: do not take on all uncertainty at once. Understand one slice, evaluate it with the business side, protect it, reconstruct it, move responsibility to the new path, remove the old path, and only then take on the next bet. Modernization does not become easy as a result, but the amount that has to be understood and controlled at any one time remains more bounded.

That brings the argument back to the opening thesis:

A Big Ball of Mud should never be rescued by one person alone.

Not because a single person is necessarily incapable of understanding or achieving enough. There may indeed be someone who understands the old system exceptionally well, recognizes boundaries faster than others, and becomes the most important starting point for reconstruction. The problem would be allowing the future system to become dependent on that exceptional person all over again.

A system whose architecture works only as long as one individual carries all of its relationships in their head is already reproducing part of the problem it was meant to escape.

The new architecture must not exist only in the head of the person who understood the old Big Ball of Mud best.

The way out of a Big Ball of Mud is therefore not a hero story. It is a reconstruction carried collectively.

References

• Feathers, Michael C. (2004): Working Effectively with Legacy Code. Prentice Hall / Pearson, ISBN 978-0-13-117705-5. The book covers characterization tests, the Seam Model, and techniques for changing difficult-to-test legacy systems in a controlled way. Pearson
• Fowler, Martin (2004): Original Strangler Fig Application. Original description of incremental displacement as an alternative to a large cut-over. martinfowler.com
• Fowler, Martin (2024): Strangler Fig. Updated discussion of the Strangler Fig approach in the context of incremental legacy modernization. martinfowler.com
• Fowler, Martin (2018): Refactoring: Improving the Design of Existing Code, 2nd edition. Addison-Wesley. See also: Definition of Refactoring.
• Jørgensen, Magne; Nereng, Johan; Torrissen, Tobias (2026): A survey of the decommissioning of IT systems. Journal of Systems and Software, 241, 113016. DOI: 10.1016/j.jss.2026.113016.
• Liu, Kecheng; Alderson, Albert; Qureshi, Zubair (1999): Requirements recovery from legacy systems by analysing and modelling behaviour. Proceedings of the International Conference on Software Maintenance, pp. 3–12. DOI: 10.1109/ICSM.1999.792485.