The old system knows things the new team has not been told.

It may know them awkwardly: through code, exceptions, operating habits, and people who can explain why a particular detail matters.

A new team can see obsolete technology while missing accumulated business understanding. The established team can see risk while missing a useful new possibility.

Modernization needs a bridge between these views.

Separate the value from the form carrying it.

An existing implementation may need to change. The knowledge and capabilities embedded in it may need to survive.

Recognizing that distinction helps a group compare real alternatives. It can preserve something useful without making the entire old system untouchable. It can open new ground without assuming replacement is the only way to reach it.

Howard Pearlmutter's Goldmine & Greenfield model brings these questions into the same frame.

Give both technical cultures a shared problem to solve.

The experienced team understands operating behavior. The new team understands different platforms and techniques. Each can help the other examine what a transition would actually require.

Howard's work includes bridging mainframe-era and web-oriented environments, enterprise integration, healthcare migration strategy, and mentoring a COBOL-era team into enterprise Java technologies.

The challenge is partly technical and partly human: make the old knowledge available in a form the new work can use, while helping experienced people acquire the models needed to participate.

Use the future architecture to ask better questions about the present.

Which behaviors are essential? Which constraints belong to the current implementation? What interface could preserve a useful capability while allowing another part to change? What would a prototype have to demonstrate?

These questions can reveal an intermediate route between broad replacement and indefinite postponement.

At Goldman Sachs, Howard's Goldmine & Greenfield briefing helped address difficult legacy-migration questions. For a troubled financial-information service, his analysis connected existing code and architecture with future commercial options. See the investment case.

Carry understanding through the transition.

A migration is more workable when people know which meanings and responsibilities have to remain stable. That may require technical transfer, mentoring, architecture, and a phased approach alongside implementation.

Howard can contribute a bounded review or participate in the practical work where useful. The purpose should be specific enough for the organization to use the result.

Start with a capability people say must be replaced. Ask what value it carries and what room for change remains. The most useful bridge may appear in the relationship between those answers.

Continue with mentoring, merger integration, or an independent review.