The old asset and the new possibility can belong in the same plan.

A modernization discussion can become a contest between people defending the existing system and people arguing for a new beginning.

The contest may conceal a more interesting set of choices: preserve, deepen, extend, combine, replace, or explore in parallel.

Howard Pearlmutter's Goldmine & Greenfield framework gives those possibilities a place in the conversation.

Two sources of opportunity

The goldmine image directs attention toward value already present: knowledge, working capability, relationships, or assets whose potential is not fully used.

The greenfield image opens room for a different possibility, with fewer inherited assumptions.

Neither image decides the case. The comparison helps people notice what their preferred framing may have left out.

An existing system can carry expensive constraints and valuable domain knowledge at the same time. A new architecture can open options while introducing obligations the attractive demonstration does not show.

The framework traveled across professional contexts.

Valtech's Nick de Toustain described attending a Goldman Sachs executive briefing where Howard applied Goldmine & Greenfield to difficult legacy-migration issues.

Hillel Glazer separately described the framework's relevance to investment, responsiveness, process improvement, and agility. His relationship with Howard included repeated hiring, co-creation, teaching, mentoring, and coaching.

These are different witnesses and contexts. They show an idea being useful across technical and business conversations, rather than a slogan confined to one software product.

An illustrative choice

Imagine an established service whose interface is difficult to change. The first proposal is a full replacement.

Before choosing, the team separates several questions. Which information and rules express durable knowledge? Which difficulties belong to the interface? Which constraints come from the platform? What could a small new component make possible without carrying all the old design forward?

The comparison might support replacement. It might support a new interface over retained capability, a staged migration, or an experiment that clarifies a key uncertainty.

This is an illustration, not a claim about a particular client or a recommendation for every legacy system. Its purpose is to make the range of choices visible.

Actual work has required that wider reading.

A troubled financial-information project involved more than seventy million documents, years of effort, and a multimillion overrun. Howard's remit included cancellation, disposition, or resuscitation.

He examined architecture, code, markets, throughput, and stakeholder perspectives. A new direction preserved value and opened alternatives. Investigation, recommendations, and rearchitecture planning took one week; a successful launch came later.

Read the financial-information case.

The case matters because the existing implementation and the value of the information asset deserved separate examination. Treating them as one indivisible question could have hidden a useful future.

Keep the comparison connected with action.

For each option, ask what it preserves, what it changes, what it depends on, and what examination would improve the next choice.

The answer can lead to a small experiment, a deeper assessment, a prototype, or a deliberate stop. Different parts of the undertaking can deserve different responses.

Explore what to keep, what a stop could preserve, and what to test.

Begin with the opportunity and the current framing.

A second reading is valuable when it makes more of the real choices available.