Nobody's Tearing It Down: What Old Buildings Teach You About Old Products

You own a legacy product. Something that works, has users, and carries years of old decisions baked into it. The instinct is to rip it out and start clean. But look at what architects are doing right now with dead infrastructure, and you get a better playbook. Let me catch you up on what old buildings can teach you about your old product.

Keep the bones, add only what earns its place

The strongest moves in this batch of projects share one habit: cut the plan down, not up. When A.CO.LAB reactivated an abandoned sewage plant in South Korea, the team dropped its own proposal from ten condensing tanks to five. Less new stuff, more of the existing structure left visible. They used cheap, removable materials like timber and steel plates so nothing competed with what was already there.

That is a discipline, not a shortcut. It kept them inside a tight budget and kept the site's character intact. For your product, the parallel is direct. Before you add a new layer, ask what the current system already does well that you are about to bury. Add the staircase and the skylight. Leave the load-bearing walls alone.

The rewrite that nearly fell down

Here is the cautionary tale. In Midtown Manhattan, a Gensler office-to-residential conversion of the old Pfizer headquarters started buckling mid-construction. Support columns on the 21st floor were failing and upper floors were sagging. It is the largest office-to-residential conversion in the city, 1,600 apartments planned, and they were making structural changes to a steel tower built in the 1960s.

The lesson for a legacy product is not "don't touch the structure." Sometimes you have to. The lesson is that when you change what holds the weight, you have to know exactly how the old thing was built and where the stress goes. A big conversion can look great in renderings and still fail because someone underestimated what the original structure was doing. Respect the load path in your codebase the same way.

Constraints are the design, not the obstacle

The teams doing the best work stopped treating the old function as a problem to hide. In Reykjavík, Terta turned a decommissioned power station into a learning site by mining the plant itself for ideas. They repurposed sections of concrete pipe as play structures and pulled the whole color palette straight from the utility's own color-coding system. The old machinery became the story.

Snøhetta did the same at Aalto's 1930s Paimio Sanatorium, turning patient rooms into hotel bedrooms and reopening the sun balconies that later owners had glassed over. Founding partner Kjetil Trædal Thorsen called each intervention "carefully considered, preserving the building's integrity while allowing it to evolve." Your product's odd constraints, the workflow users learned, the data model you inherited, are often the thing worth keeping, not the thing to apologize for.

Openness is the whole point of the redo

Why do the conversion at all? To let more people in. When David Chipperfield Architects reworked a historic Santander bank into a museum, the studio built a circulation spine linking to an arch on the facade, a move they said marks the shift "from former bank headquarters to a generously proportioned public space for the city." A closed building became a public one. Nine years of work aimed at that single idea.

Hello Wood pushed the same goal in Zurich, building a cultural hub on a former railway freight yard that lead architect Balázs Szelecsényi wanted to "pop out from its industrial and colourless surroundings." The old site was walled off and dead. The redo made it walkable and shared. When you rebuild a legacy product, name the openness you are buying: fewer steps to value, more people who can actually use it.

The deep cut

The fast projects were the modular ones. Hello Wood finished Remise Rosa in five months because they prefabricated the timber structure off-site with CNC cutting, so assembly was quick and clean. Terta and A.CO.LAB both leaned on removable, common materials that don't lock you in. That is the reusable takeaway for your roadmap: the reason a legacy rewrite drags on is rarely the old code. It is that the new work is monolithic, poured in place, impossible to reverse. Build your changes as parts you can prefabricate, test, and pull out. You move faster, and when a column starts to buckle, you fix that piece instead of evacuating the block.

Three questions for your team

1. What does our legacy product already do well that our rewrite plan is about to bury or throw away? Name it before we scope the work.
2. Where are the load-bearing pieces, the parts other systems depend on, and do we actually understand how they were built before we change them?
3. Can we ship this rebuild as removable, testable parts instead of one big pour, so a failure in one area doesn't take down the whole thing?