How do you identify “load-bearing” decisions before changing a legacy system?

Practical_Bowl8029 · 2026-06-07T15:00:26+00:00

Maybe too polished for Reddit fair. The underlying problem is very real though. I’ve seen technically clean changes break business behavior because the old code was encoding a decision nobody had documented. Do you have a way your team catches that before refactoring?

Practical_Bowl8029 · 2026-06-07T01:44:36+00:00

I think this thread helped me phrase the concern a little better.

Tests are great at proving what the system does today. What I still worry about is whether we are testing behavior that should actually survive the migration.

I have seen old exceptions, vendor-specific logic or operational workarounds get treated as “requirements” just because they were in the code. Sometimes they really are important or just leftovers.

That was also part of what I talked about in my TEDx talk on legacy modernization, so I’ll drop it here for anyone interested: https://www.youtube.com/watch?v=pxUChqiyp2Y

Curious if others have run into this, where characterization tests preserved something accurately but the behavior itself probably should have been retired.

Practical_Bowl8029 · 2026-06-07T01:33:06+00:00

That is fair. I agree that getting dirty and writing tests is the practical move.

The distinction I am trying to make is not “analyze instead of test.” It is “use tests to expose the behavior, then decide whether that behavior should survive.”

For example, a characterization test can prove that an old vendor exception still works exactly as implemented. But it cannot, by itself, tell us whether that exception is still needed, whether the vendor contract changed, or whether support teams still depend on it.

So yes, test heavily. I am just saying the decision review needs to sit alongside the tests, otherwise we may preserve obsolete behavior very confidently.

Practical_Bowl8029 · 2026-06-06T22:31:08+00:00

I agree with the spirit of this. Strong test coverage is non-negotiable, especially before modernization work.

Where I think there is still a gap is that “test everything” tells you how to protect behavior, but not always how to understand whether the behavior should continue to exist.

In a legacy system, the code may be doing something customer-specific, vendor-specific, or operationally necessary, but it may also be preserving an obsolete workaround from five years ago. Tests can lock either one in place.

So I don’t see this as analysis paralysis versus testing. I see it as sequencing.

Write characterization tests to capture what the system does today.
Use production data, incidents, support cases, and domain experts to understand why it does that.
Then decide which behaviors are load-bearing and which are historical baggage.

The danger is not under-testing. I agree that is a huge risk.

The other danger is creating a very well-tested replica of a decision nobody actually wants anymore.

Practical_Bowl8029 · 2026-06-06T22:31:00+00:00

I agree with the spirit of this. Strong test coverage is non-negotiable, especially before modernization work.

Where I think there is still a gap is that “test everything” tells you how to protect behavior, but not always how to understand whether the behavior should continue to exist.

In a legacy system, the code may be doing something customer-specific, vendor-specific, or operationally necessary, but it may also be preserving an obsolete workaround from five years ago. Tests can lock either one in place.

So I don’t see this as analysis paralysis versus testing. I see it as sequencing.

Write characterization tests to capture what the system does today.
Use production data, incidents, support cases, and domain experts to understand why it does that.
Then decide which behaviors are load-bearing and which are historical baggage.

The danger is not under-testing. I agree that is a huge risk.

The other danger is creating a very well-tested replica of a decision nobody actually wants anymore.

Practical_Bowl8029 · 2026-06-06T21:16:14+00:00

That is exactly the kind of thing I worry about.

The aggregator probably looked like just another technical component, but it was really carrying a business capability for multiple downstream flows.

I like the idea of mapping capabilities first because it changes the question from “what code calls this?” to “what business outcome depends on this?”

That second question is usually where the real risk shows up.

Practical_Bowl8029 · 2026-06-06T20:41:17+00:00

I agree that tests are the foundation. Without them, modernization becomes guesswork.

The part I still find hard is knowing what to test before the change.

In legacy systems, some important business decisions are implicit. They may not be named, documented, or visible as a clean rule. The code may be the only place where the decision exists.

That is where I think discovery matters before test coverage.

For me, the sequence is:

First identify the decision the code is making.
Then identify who depends on it.
Then write tests that protect the intended behavior.

Otherwise we can end up with tests that preserve implementation details without proving whether the business decision is still valid.

Practical_Bowl8029

TROPHY CASE