The Chapel That Stood While the Ground Disappeared: Santa Luzia and Software Architecture
How engineers preserved Santa Luzia Chapel while excavating underneath it—and what this extraordinary project teaches us about legacy systems and safe migrations.
Voices depend on your browser and device; some require internet access. Code blocks are not read aloud.
The chapel that remained standing while the ground disappeared: Santa Luzia's basements and software architecture
A century-old chapel, eight deep foundation piles, and a massive excavation in São Paulo. The Cidade Matarazzo project illustrates how to preserve what matters while transforming the structure underneath.
Imagine receiving this requirement: build several underground levels on a dense urban site, fully preserve a chapel inaugurated in 1922, and keep the historic building precisely where it is. In software, this sounds familiar: replace the infrastructure and redesign a critical system without breaking the service that people depend on.
That was the extraordinary challenge at the former Matarazzo Hospital near Avenida Paulista. Photographs from 2018 show a little church seemingly floating above a deep excavation. Yet it was not physically lifted by 31 metres. Its original position was preserved while the soil underneath was removed after its load had been transferred to a new deep-foundation structure.
This distinction matters. The image is spectacular, but the engineering decisions are even more compelling.
AI-generated cover illustration for ernani.dev (OpenAI, 2026). Artistic concept, not a photograph or a faithful reproduction of the actual architectural drawings.
1. Understanding what could not be lost
Santa Luzia Chapel belongs to the historic Umberto I Hospital and Maternity complex, widely known as Hospital Matarazzo. Designed by Italian architect Giovanni Battista Bianchi—also known as João Bianchi—it opened in 1922. The wider site reflects the history of Italian immigration, healthcare and urban transformation in São Paulo.
The buildings received state heritage protection in 1986, subsequently complemented by municipal protection. These designations fundamentally shaped the Cidade Matarazzo redevelopment into a complex of hospitality, culture and commercial activities. Preserving only an attractive façade was not enough: the chapel required comprehensive conservation.
Architect Roberto Toffoli describes the building's solid brick masonry, lime-based mortar, wooden roof framing, stained glass, sculptures and historic interior finishes in Revista Restauro. This material heritage made the building especially sensitive to settlement, vibration and structural interventions.
The first requirement was not “build eight underground floors.” It was preserve the historic structure. Development came second.
Software architects face the same distinction. Starting with “which framework should we use?” is often a mistake. A more useful question is “which data, contracts, business processes and guarantees must remain intact?” Legacy systems often carry obligations that are not obvious from a new architecture diagram.
Historical visual record: Photographs published by VEJA in 2018, credited to Heitor Feitosa/VEJA. Those original images, rather than the artistic illustrations in this article, show the actual construction site.
2. Replacing a foundation without removing the building
Excavating around the chapel sounds straightforward until one remembers that the ground was supporting its shallow foundations. Removing that soil without an alternative load path would place the whole building at risk.
The original foundation was approximately 1.5 metres deep. The new underground program required a much deeper excavation. Engineers Mário Franco and Carlos Eduardo Moreira Maffei contributed to the structural solution, while construction work was directed by Maurício Bianchi.
Different documents report slightly different engineering figures, and they should not be artificially harmonised. A 2018 VEJA account cites an estimated chapel mass of about 1,075 tonnes and eight 54-metre piles. A 2019 technical presentation by Maffei Engenharia refers to an estimated 1,000 tonnes-force, eight one-metre-diameter deep piles approximately 50 metres long, and a design load of 470 tonnes-force per pile. Both sets describe the same principle from different reporting and engineering contexts.
That principle was to build a strong new support system, transfer the chapel's weight to it, and only then remove the soil that had previously carried the load.
AI-generated explanatory section for ernani.dev (OpenAI, 2026); not to scale or an execution drawing. Original engineering sketches by Mário Franco/JKMF appear on pages 38–41 of the Maffei Engenharia presentation at the Brazilian Institute of Engineering (September 23, 2019).
A digital analogy: establish the new path before disabling the old one
Consider an application managing payments and millions of records on an aging database. Replacing that database may be a valid goal, but switching everything off and hoping the replacement works would be reckless.
A progressive replacement strategy, sometimes called the Strangler Fig pattern, builds the new path alongside the legacy system, tests it and gradually transfers responsibility. The new foundation was the replacement infrastructure; the chapel was the public contract that could not fail.
Concrete and code are not interchangeable. Still, the logic of risk-controlled migration translates remarkably well.
3. Construction sequence: order is part of the design
In this project, a technically correct operation performed at the wrong moment could cause irreversible damage.
Phase 1 — Site preparation and retaining structures
Before deep excavation, engineers prepared the site and constructed retaining elements to limit soil movement. The work took place among historic neighbouring structures with constraints on access, vibration and underground water.
Maffei Engenharia's 2019 presentation describes excavations around 28 metres deep for areas of eight basement levels, with the water table around 13 metres below the surface. News reports from 2018 repeatedly cited a depth or apparent height of 31 metres. These values can reflect different reference points, areas and project stages, so neither should be presented as a single universal measured depth.
In software terms, this phase resembles setting up backups, monitoring, service isolation and rollback procedures before making structural changes.
Phase 2 — New deep foundations
Engineers constructed eight deep piles around the chapel. Together they formed an alternative route for vertical loads to reach more stable soil layers. Their construction had to limit vibrations and displacement to protect old masonry.
The digital lesson: introducing replacement infrastructure can itself damage the system being replaced. Compatibility, load testing and staged deployment are vital.
Phase 3 — The transfer structure
Reinforced-concrete beams and a substantial slab formed the bridge between the old building and its new supports. VEJA reported a platform approximately 19 by 17 metres and 1.15 metres thick. The 2019 engineering presentation describes a transfer system spanning approximately 16 metres between the new foundations.
This is the most powerful architectural parallel: having both the old and new components does not guarantee a safe migration. A transition layer must redistribute responsibilities and preserve critical invariants. In software it might be an adapter, a compatibility API, an anti-corruption layer or a replication service.
Phase 4 — Actual load transfer
Even with the new slab in place, the original foundation still made some contact with the soil. Engineers used carefully controlled high-pressure water jetting to remove a thin layer—reported at roughly seven centimetres—and complete the shift in support.
This was the structural cutover. Declaring that a migration is ready is not enough; one must establish that the replacement is genuinely carrying the load.
In a database migration, cutover is the moment the new database becomes authoritative. Common dangers include diverging writes, incomplete transactions and overlooked dependencies.
Phase 5 — Gradual excavation and continuous stability
Once the chapel rested on the new system, excavators could remove the soil below it. However, the structure also had to remain safe during intermediate construction states.
A particularly important point in the Maffei presentation is that slabs at levels N-0, N-2, N-4 and N-6 were constructed as excavation progressed to prevent buckling of the increasingly exposed deep columns. These temporary structural configurations were not incidental; they were essential to the sequence.
This disproves the simplistic idea that engineers merely placed a church on eight legs and dug a hole. The load-bearing behaviour changed throughout the works.
The same happens during a software migration. Running two data systems, temporary replication, legacy and new APIs, and asynchronous queues may create transitional states that are more complex and less resilient than either final architecture. Those states deserve explicit design and testing.
Phase 6 — Final foundations and integration
The technical presentation also reports that the pile-columns required additional foundation blocks to support final design loads, creating a mixed foundation solution. Temporary construction needs and final operating needs are not always the same.
There is also an important reporting nuance. In 2018, articles described plans associated with eight underground levels across the relevant complex. A 2021 report about the chapel's reopening referred to five basement floors beneath the chapel. These counts should not be presented without distinguishing the wider project, a specific area and different dates.
AI-generated editorial infographic for ernani.dev (OpenAI, 2026). A conceptual account of the sequence, not a photographic chronology or a construction specification.
4. Six lessons for software architecture
First: non-functional requirements are architectural requirements. The apparent objective was underground capacity; the governing constraint was heritage preservation. In software, security, availability, integrity, latency and auditability often outweigh individual features.
Second: invisible dependencies are the dangerous ones. The ground looked like material to remove, but it was the existing support. Legacy platforms likewise contain undocumented jobs, shared databases, hidden integrations and operational knowledge. Understand what something supports before removing it.
Third: the migration plan belongs in the architecture. Before-and-after diagrams hide the riskiest period. Model each transitional state, its capacity, failure modes and acceptance criteria.
Fourth: observability is a safety mechanism. The 2019 engineering presentation contains settlement-monitoring data collected from points on the chapel. Software engineers need the equivalent in metrics, traces, logs, alerts and reconciliation reports.
Fifth: cheapest is not the same as lowest risk. Roberto Toffoli notes that less expensive techniques were considered, while the project chose a more technically elaborate intervention. This is not an argument for unlimited spending. It is a reminder to assess cost, risk, reversibility and preserved value together.
Sixth: preserve guarantees, not immobility. The chapel still underwent restoration and alterations. Likewise, preserving a production system's business guarantees does not mean never changing its components.
5. A practical migration playbook inspired by the chapel
For a critical digital system, I would turn these principles into seven decisions:
- Define what must survive: data, external contracts, SLAs, business workflows and regulatory constraints.
- Measure before changing: error rates, consistency, latency, capacity, queue backlogs and audit trails.
- Construct the replacement support: infrastructure, services, data models and compatibility interfaces.
- Prove the new system can carry its load: benchmarks, fault testing, reconciliation and explicit go/no-go criteria.
- Transfer responsibility progressively: controlled routing, feature flags, shadow traffic and safe migration mechanisms where applicable.
- Support temporary configurations: contingency paths, controlled replication and bounded coexistence of old and new parts.
- Decommission only after verification: demonstrate stability, remove dependencies and document the resulting system.
Not every project needs every technique. The point is universal: do not eliminate an existing support until its replacement can reliably assume the load.
6. Beyond engineering: a city and its memory
The engineering achievement also raises a public-interest question. How should historical preservation, public access, urban mobility and private commercial redevelopment be balanced? Cidade Matarazzo is a private multi-use development, and its technical innovation does not remove the need for civic scrutiny.
Still, the chapel's religious role returned. In November 2021, news reports documented its reopening for services. The lasting result was not merely a viral photograph, but the survival of a cultural asset through a major transformation of its urban setting.
Mário Franco, who died in 2019, helped develop a project combining structural calculation with unusual technical imagination. Alongside Carlos Eduardo Moreira Maffei and the construction teams, the solution illustrates that preserving an old system is not the opposite of innovation. Sometimes preservation is precisely what drives the most innovative ideas.
Conclusion — Intelligence lies in the order of decisions
To a passer-by, Santa Luzia seemed to float. To engineers, the image represented load paths, retaining systems, settlement, buckling, inspections and carefully controlled risk.
To a software architect, it can represent something else: an infrastructure migration performed without taking away the support of the main service.
Good architecture is not defined by adopting the newest technology. It is the discipline of recognising what should remain, what must change, and how to move safely between those realities.
Before excavating your system's future, make sure its present has somewhere safe to stand.
Sources, photographs and image credits
- Maffei Engenharia / Institute of Engineering (2019): Technical presentation on the Cidade Matarazzo foundations, including Mário Franco/JKMF subfoundation sketches on pages 38–41, construction photos and settlement monitoring data.
- Roberto Toffoli, Revista Restauro (2019): Works and adaptive reuse of the former Matarazzo Hospital. Historical images and foundation diagrams are credited there to the Cidade Matarazzo Archive.
- João Pedroso de Campos, VEJA (2018): Luzia nas alturas, photographs by Heitor Feitosa/VEJA and original explanatory graphics.
- Fillipe Mauro, Folha de S.Paulo (2018): Initial construction reporting.
- Folha de S.Paulo (2021): Reopening report, featuring a reopening photograph credited to Danilo Verpa/Folhapress.
- Illustrations on this page: AI-generated original conceptual visuals (OpenAI, 2026), created for ernani.dev. They are not documentary photos or engineering drawings. Third-party historical photographs are linked to their original publishers rather than reproduced without permission.
Methodological note: excavation depths and basement-floor counts differ across reporting dates, areas and engineering presentations. Distinctions between plans, construction records and later accounts have been maintained.
