Taking Over a Legacy System — the First 90 Days

There is one moment in modernization that causes more anxiety than any other: the day you take responsibility for a system you didn't build and don't yet understand. From that day on, a running business depends on this system — and every intervention, every lapse of attention can disrupt it, even though you don't yet know how it works. Start wrong here, and within a few days you squander the trust that a modernization needs over months.

This document treats that first phase — often called the first ninety days — as a discipline in its own right. It is not the modernization itself; it is what comes before: understanding the system, making it safe and manageable before you change it. It is kept framework-neutral, because the mindset doesn't depend on any technology. How to modernize afterwards is covered in separate texts; this one is about the beginning, where it is decided whether everything that follows can succeed.

1. Why the takeover is the most dangerous moment

The takeover is dangerous because two things come apart that otherwise belong together: responsibility and understanding. From the very first hour, you are responsible for what the system does — but you don't yet have the understanding you would need to carry that responsibility safely. You own a house whose wiring you don't know, and people live in it. Every move can trigger something you didn't foresee, because you don't know the connections.

The first phase therefore has a clear internal order — four movements that build on one another:

This gap between responsibility and understanding is the real danger of the first phase — and the reason it deserves its own discipline. Anyone who ignores it and starts working right away, as if they had built the system, acts on assumptions nobody has checked. The art of a takeover is to close this gap deliberately before putting it to the test through interventions. You earn the right to change by understanding first.

Diagram: responsibility is full from the first day; understanding only grows. The area in between is the danger zone — the first phase exists to close it.

Trade-off. Treating the takeover as a phase of its own means holding off on visible change — that feels like a lack of progress, but it is the precondition for moving forward safely at all.

Cost. The first phase delivers no new feature; it costs time that looks like standstill from the outside and demands patience from everyone expecting quick results.

When we decide differently. For a small, well-documented system that you can fully grasp within days, the phase may be short; its length grows with the size, age and opacity of the system.

2. Understand first, don't change

The strongest instinct during a takeover is also the most dangerous: to immediately improve whatever catches your eye. You see messy code, a questionable decision, something you would have done differently — and your hand twitches toward a fix. Resisting this instinct is the first discipline of a takeover. Because what looks like a mistake in a system that has grown over time is often a solution to a problem you don't know yet. Change before you understand, and you may remove exactly the safeguard that prevented a silent failure.

The mindset is therefore: understand first, then change. In the first phase, understanding is the actual work, not improving. You read, you observe, you ask — you build a picture of what the system does and why it is the way it is. Every oddity gets noted, not fixed right away; the list of questions is more valuable than the list of quick fixes. You earn the right to change a system through the understanding that makes the change safe.

Trade-off. Not improving right away means leaving visible blemishes in place and tolerating the impatience of not touching something obvious.

Cost. For a while, you carry the flaws of a system that you have recognized without fixing them — that requires discipline and the willingness to look unfinished.

When we decide differently. Where an oddity is an acute, understood risk — an open security hole, impending data loss — you don't wait; the restraint applies to what you don't yet understand, not to what is clearly dangerous.

3. Safety nets before interventions

Before you seriously touch a system you have taken over for the first time, you put up nets that catch a mistake. The most important is the ability to go back: verified backups that you know you can actually restore in an emergency — not ones that exist in name but have never been tested. The second is the ability to see: enough observability to recognize how the system behaves and whether an intervention has disrupted something. A system you cannot reset and cannot observe must not be changed — you would be working blind on something irreversible.

Putting these nets in place is often the first concrete work on a system you have taken over, and it is valuable even before you change anything: it makes the system manageable. Whoever knows they can notice a mistake and undo it works calmly and safely; whoever doesn't works in fear or not at all. The safety nets are thus not preparation in the sense of postponement, but the first real improvement — they increase the system's safety without touching its functionality.

Trade-off. Putting up nets first means investing work before the first intervention that changes nothing about functionality — effort that only pays off in damage avoided.

Cost. Establishing verified backups and sufficient observability can itself be laborious in a neglected system and delay the actual work.

When we decide differently. Where a system already comes with reliable backups and good observability, you skip this build-up and only verify that the nets really hold; if they are missing, building them is non-negotiable.

4. The map of the system

A system you have taken over is initially a blank spot, and the first phase serves to turn it into a map. This map answers simple but decisive questions: what does the system consist of, which parts depend on each other, what external dependencies does it have, where does the data live, which paths do the most important processes take? You don't draw every detail but the load-bearing lines — enough to know what you're touching when you touch something, and what else moves when you pull at one point.

The richest source for the map is often the people who have operated or used the system so far. Those who built it know the reasons behind its quirks; those who operate it know where it gets stuck. These conversations lead to the forgotten edges faster than analyzing the code alone — provided you ask early, while the knowledge is still within reach. With every week after the handover, the memory of those involved fades, and the map you could easily get today has to be painstakingly reconstructed from the system itself tomorrow.

Special attention goes to the edges and to the dependencies nobody has in their head anymore: the rarely used service, the silent connection to the outside, the process that runs only once a month. It is precisely these forgotten parts that cause the greatest damage during an intervention, because nobody reckons with them. The map makes them visible while you haven't changed anything yet. It is not a document for its own sake, but the tool with which you turn an unknown system into a manageable one.

Trade-off. Drawing the map costs time spent on understanding that you would rather put into building — in exchange for not reaching into the unknown.

Cost. In a large, opaque system, mapping is laborious and never quite complete; you have to work with a map that has gaps, and know those gaps.

When we decide differently. For a small system that one person can fully grasp, a rough sketch is enough; the elaborate map pays off with size and the number of forgotten corners.

5. Characterization instead of assumption

Before you change a system's behavior, you have to know how it behaves today — with evidence, not by guesswork. In someone else's system, the current behavior is the only reliable truth: it is what the business has adapted to, including its quirks and even its small bugs. Characterization means capturing this behavior before you touch it — as a reference point against which you can check every later change. You don't describe how the system should be, but how it is.

The value of this mindset is that it makes changes safe. Once today's behavior has been captured, you see immediately whether an intervention has shifted something you didn't want to shift — including a quirk you didn't know somebody relied on. Without this reference point, you change things on a hunch and only learn of an unintended side effect when a user reports it. Characterization turns assumptions about the system into evidenced knowledge — the foundation of every responsible change.

Trade-off. Capturing today's behavior costs work on something you want to change anyway — in exchange for being able to check every change against a reliable reference point.

Cost. Characterization requires capturing the system's quirks and small bugs too, not just its ideal behavior — more effort than describing the obvious.

When we decide differently. For a part that you are going to replace completely anyway and whose old behavior nobody wants to preserve, you skip characterization; it is for what stays and whose behavior has to remain stable.

6. The first safe changes

Once the nets are up, the map is drawn and the behavior is captured, you start to change things — but small and reversible. The first interventions are deliberately low-risk: an improvement whose effect you can fully oversee, in a place you understand, with a clear way back. You are not looking for the biggest impact but for the most reliable proof that you have the system under control — that you can change it without breaking anything. Every small intervention that succeeds increases understanding and trust; every one that fails would, kept small, be cheap to correct.

Diagram: the first safe change comes last, not first — it rests on everything before it and proves that it holds.

These first changes have a dual purpose. Outwardly, they show that the takeover is progressing and the system is in good hands — they establish the trust the actual modernization needs. Inwardly, they test whether the groundwork holds: whether the nets hold, the map is accurate, the captured behavior provides the reference point. Only when these small, safe interventions succeed reliably is the takeover complete and the modernization can begin. You move from understanding to changing not with a leap but with a tentative, reversible first step.

Trade-off. Starting small and safe means forgoing a big, visible first impact — in exchange for proving control before you attempt anything big.

Cost. The first changes deliver little visible progress for the effort; their value lies in proven control, not in the result itself.

When we decide differently. Where an acute problem is pressing and understood, the first intervention may be bigger; the restraint applies to the normal case, in which you first have to prove control.

7. What you don't do in the first ninety days

Just as important as what you do is what you deliberately refrain from doing in this phase. You don't start a major restructuring or a rewrite as long as you don't understand the system — the temptation is great precisely because the old system is unpleasant, but a rewrite based on lack of understanding only repeats the mistakes whose causes you don't know. You don't hastily restructure what you consider messy, because the order you miss is often serving a purpose you don't see yet. And you don't promise quick, big results to the outside world that could only be achieved through risky interventions.

This restraint is not passivity but a decision. The first phase has a clear goal — to understand the system and make it safe and manageable — and anything that doesn't serve this goal or endangers it doesn't belong in it. The major restructuring will come, but later, out of understanding and in reversible steps, as described in modernization without a big bang. Whoever resists the temptation of the grand gesture in the first ninety days lays the foundation on which the grand gesture can succeed at all.

Trade-off. Forgoing the grand gesture means impressing less in the short term — in exchange for avoiding the risk that makes most takeovers fail.

Cost. You have to actively dampen expectations of big, quick results and endure the impatience of those who want to see the system transformed immediately.

When we decide differently. Where the system is failing acutely and continued operation would be irresponsible, the balance shifts; then you act sooner, but as reversibly as possible.

8. Common mistakes

The recurring patterns that make takeovers fail — almost all of them are variations on changing before you understand:

• Immediately improving whatever catches your eye, and in doing so removing a safeguard whose purpose you didn't know.
• Taking on responsibility and acting as if you had built the system, instead of closing the gap in understanding.
• Changing things before verified backups and sufficient observability are in place — working blind on something irreversible.
• Overlooking the forgotten edges — the rarely used service, the silent external connection — that cause the greatest damage during an intervention.
• Acting on assumptions about behavior instead of capturing today's behavior with evidence.
• Starting with a big, visible intervention instead of first proving control through small, reversible ones.
• Hastily restructuring what looks messy but serves a purpose not yet known.
• Promising quick, big results to the outside world that could only be achieved through risky interventions.

9. Decision checklist

To clarify, in order, for the first phase of a takeover:

• Understanding before change? Is understanding the declared main work of the first phase — not improving?
• Able to go back? Are there verified backups that you know you can actually restore?
• Able to see? Is observability sufficient to recognize how the system behaves and whether an intervention has disrupted it?
• Map? Have the load-bearing parts, the dependencies and especially the forgotten edges been made visible?
• Behavior captured? Is today's behavior evidenced, as a reference point for every change?
• Started small and reversible? Do the first interventions prove control rather than seeking the biggest impact?
• Deliberately refrained? Have the major restructuring, hasty reorganization and promises of quick results been deferred?
• Trust built? Do the first safe changes show the outside world that the system is in good hands?

Whoever can answer these questions has taken over someone else's system without endangering it — and laid the foundation on which the modernization can succeed.

FAQ

Why not fix the obvious flaws right away? Because in a system that has grown over time, much of what looks like a mistake is a solution to a problem you don't know yet. Change before you understand, and you may remove exactly the safeguard that prevented a silent failure. You note the oddities and fix them once you understand their context — not before.

What is the first thing you do with a system you have taken over? Put the safety nets in place: verified backups that you know you can restore, and enough observability to see how the system behaves. A system you cannot reset and cannot observe must not be changed. These nets make the system manageable even before you change anything.

What does characterization mean? Capturing the system's current behavior with evidence before you change it — as a reference point. In someone else's system, the current behavior is the only reliable truth, quirks included. Once it is captured, you see immediately whether an intervention has shifted something nobody wanted to shift — instead of hearing about it from a user first.

Why no major restructuring in the first ninety days? Because a rewrite or restructuring based on lack of understanding only repeats the mistakes whose causes you don't know. The first phase serves understanding and safety; the grand gesture comes later, out of understanding and in reversible steps. Whoever resists the temptation of the grand gesture lays the foundation on which it can succeed at all.

How do you know the takeover is complete? When small, reversible changes succeed reliably — when you can change things without breaking anything. That is the proof that the nets hold, the map is accurate and the captured behavior provides the reference point. Only then does the takeover move on to the actual modernization.

How long does this phase really take? The ninety days are a figure of speech, not a fixed measure. The phase lasts until the gap between responsibility and understanding is closed — shorter for a small, documented system, longer for a large, opaque one. It doesn't end after a deadline but when you have the system under control.

Further reading

• Legacy Modernization Without a Big Bang — what comes after the takeover: modernizing in small, reversible steps.
• Modernizing a Legacy Monolith — the playbook for the modernization itself.
• Observability Is Architecture — why you can't intervene safely without being able to see.
• Reversibility Over Prediction — why the first interventions have to be small and reversible.

The foundation is the Batunet Engineering Method: understand first, then change; design for failure; proceed in small, reversible steps.

Closing engineering principle

You don't take over someone else's system by immediately making it your own, but by earning the right to change it — through understanding, through safety, through proven control. The first phase delivers no feature and no grand gesture; it delivers something more valuable: a system you can change without endangering it. The most common reason modernizations fail is not the modernization itself, but a takeover that wanted too much too fast. Whoever devotes the first weeks to patience loses no time — they buy the safety that makes everything else possible in the first place.

A system you have taken over only truly becomes yours once you understand it. Until then, you are looking after someone else's work — and the only art is not to damage it while you learn.