Every client has one. A feature that came up in a meeting three years ago, went into a quote, and never came out of it. Not because it was impossible. Because on the current setup it would cost more to maintain than it would ever return.

For Galant Architectes, a Brussels architecture firm that has been regularising buildings since 1999, that feature was a map.

They had 156 completed projects across the 19 communes of Brussels. Written down, that is a number in an about page. Nobody could see what it represented.

Why a list is the wrong shape for a portfolio

Think about what a homeowner with a permit problem actually does. They are not browsing architecture. They are frightened, they have a letter from the commune, and they want to know one thing: has this firm already solved this, near me?

A portfolio list answers that question badly. You scroll, you read addresses, you try to remember which of them was in your neighbourhood.

A map answers it before you read a word.

That is not a design preference, it is the difference between a page that proves a track record and a page that merely claims one. More than twenty five years of work in a list looks like content. The same work on a map looks like coverage.

Possible, but not reasonable

The old site ran on WordPress, and the map existed there in a limited form, through a third party plugin.

Nothing about the ambitious version was technically impossible. It was just not reasonable:

The data lived in the CMS, so every filter combination meant a database query on request, for every visitor.
The map depended on a plugin whose roadmap was not ours. A feature we needed could arrive, or never arrive, or arrive behind a licence upgrade.
Every change meant custom development on top of a theme, a page builder and a plugin stack that all had to keep agreeing with each other after every update.

So the map stayed in the quote, year after year.

This is the part of legacy platforms that rarely shows up in a report. It does not appear as a bug or a slow page. It appears as ideas that never get built, because the cost of building them on the current foundation is never justifiable in the moment.

Changing the foundation first

In 2026 we rebuilt the site on Astro, generated at build time and served statically from Cloudflare Pages. The production dependency list is three packages, so there is no framework runtime shipped to the browser and very little to keep patched.

The point was not the stack. The point was what the stack made affordable.

When the projects live as data at build time instead of rows queried on request, a map of all of them is no longer an expensive feature. It is the same data, rendered twice: once as cards, once as pins.

The rule: not one URL moves

Before any new feature, the migration had to be invisible to Google. The firm’s rankings were the business. A rebuild that quietly dropped a third of its URLs would have been a redesign that cost them leads.

So the rule was absolute: every page keeps its exact address.

206 pages in the migration scope were rebuilt at their original URLs.
3,018 assets kept their original upload paths, down to the year and month folders WordPress had created.
An automated parity check runs before every deploy. It compares each built page’s title, meta description, canonical, robots directive and H1 against a capture of the WordPress originals, and refuses to publish on a single mismatch.

That last one is the part we would repeat on every migration. A checklist is a promise. A gate that blocks the deploy is a guarantee. The sitemap holds 211 URLs today, the extra five being articles published since the move.

Across the main queries we examined, average positions stayed close between the four weeks before the migration and the four weeks after. That is the whole objective of a platform migration: the audience should never notice it happened.

Then the map, in the layout people already know

The projects page borrows a pattern every visitor has used before, on Airbnb or on a property portal: results scrolling on the left, a map holding still on the right for the entire scroll.

Under that familiar surface:

156 projects, each a real server rendered card. The listing is fully crawlable and the cards stay readable with JavaScript switched off. A portfolio that only exists after a script runs is a portfolio search engines cannot count.
Filters on commune, property type, surface band and year, plus free text search on any address, with a live result count on every option so nobody lands in an empty set.
A custom Leaflet explorer with clustering, replacing the plugin. Cards and pins are built from the same project data, so they can never disagree.
A “Situer” button on every card that flies the map to that address.
List and map views that toggle on mobile, where a split screen does not fit.

Two days after the new foundation was ready, the 156 projects were on the map.

We are careful with that number, because speed is the least interesting thing about it. The two days were only possible because the migration work before them had already put the data in the right shape.

What it costs in performance

This is the heaviest page on the site: 156 cards plus an interactive map. Measured live in September 2026 it scores 93/100 on mobile and 97/100 on desktop, with 100/100 on accessibility, best practices and SEO. The home page scores 95/100 on mobile and 100/100 on desktop.

A map is not free. It is just no longer expensive enough to matter.

The lesson worth taking

The usual argument for a modern framework is performance. Page speed, Core Web Vitals, a greener Lighthouse panel.

That argument is true and it is boring. Speed is table stakes. Every serious stack can be made fast.

The real return is different: a foundation where the good idea is cheap enough to build. Galant did not get a faster website. Galant got more than twenty five years of work that a visitor can take in at a glance, and a firm whose expertise is now visible instead of merely described.

Which raises the question we would ask of any site that has been running for a few years. How much expertise is still sleeping in your pages, waiting for a feature that was always possible, just never reasonable?

If that question lands, the full Galant Architectes case study has the rest of the numbers, and our migration service page explains how we move a site without moving its addresses.