The ship of Theseus: migrating a website without it becoming another one

A website has been in production for five years. The theme is dated, the visual editor weighs as much as a wardrobe and nobody dares to update anything. Someone says the sentence that opens every one of these projects: we need to rebuild it.

The question nobody asks in that meeting is the one that matters: when we’re done, will it be the same website?

The ship the Athenians wouldn’t let die

Plutarch writes in his Life of Theseus that the Athenians kept the ship in which the hero returned from Crete until the time of Demetrius of Phalerum. Whenever a plank rotted, they took it out and put in a new one. In time not a single original piece remained, and the philosophers of the day used it as a stock example: some said it was still the same ship; others, that it had become another.

Centuries later, in 1655, Thomas Hobbes gave it the twist that makes it uncomfortable. Suppose someone collects the old planks as they are removed and builds a second ship from them. Now there are two. One in the harbour, every piece new, that never stopped sailing. Another in a warehouse, made entirely of the original timber. Which one is the ship of Theseus?

Anyone who has lived through a migration knows both ships.

A website’s identity is not in its code

For the visitor, for Google and for the business itself, a website is a contract with the outside world:

• The addresses Google has indexed and someone bookmarked.
• The links other sites have pointed at it for years.
• The form that lands in the usual inbox, and the email that cannot go down.
• What the regular customer expects to find where it always was.

That is the ship. The code is the planks. You can replace every plank, including the language they are written in, and the site is still the same as long as the contract holds. And the other way round: you can keep every last line of code and break the identity in an afternoon by changing the routes without redirecting them.

The first ship: replacing planks without leaving the water

Plutarch’s ship never left the water. That is the key to the method, and in software it has a name: Martin Fowler called it the strangler fig, after the figs that grow wrapped around a tree until they take its place.

On a website it looks like this. The new system wraps the old one and starts answering for one part first: the header and footer, or the home page. Every other page still comes from the old system, inside the new wrapper. Then one page is migrated, then another. Each step ships on its own, each step can be undone, and there is never a D-day when everything changes at once.

It has a price, and it’s worth saying so: for months two systems live side by side. Some pages are half new and half old, and the site is never “finished”. It is uncomfortable to look at. But the ship sails the whole time, and if a new plank turns out bad, you notice it in that plank and not in the whole ship.

The second ship: the rewrite in the warehouse

The alternative is Hobbes’s: build the new site separately, complete, and on launch day swap one for the other.

In the meeting it sounds cleaner. No legacy, no coexistence, a fresh start. The trouble arrives on switch-over day, because that day there are two ships and someone has to decide which one is real. It almost never gets decided; it gets discovered. You discover that the new routes have different names and nobody prepared the redirects. That the form pointed to an inbox that no longer exists. That a page nobody remembered brought in half the visits from Google. That the old site was doing something nobody knew it did.

The new code is usually better than the old. What fails is the starting assumption: treating identity as if it lived in the planks. So it stays in the warehouse, along with the old timber.

When the warehouse does make sense

This is not an absolute rule. Sometimes the ship can’t be repaired: the hull is rotten, the old system won’t let itself be wrapped, or the contract with the outside world is so small it fits on one page. A five-page site with no organic traffic can be rewritten without drama.

What decides is the size of the contract, far more than the size of the code. The more indexed addresses, inbound links, integrations and user habits a site has accumulated, the more expensive D-day becomes and the more sense it makes to change planks in the water.

In the river and the stone the argument was that an application has to decide what flows and what stays still. A migration is that same decision at the scale of the whole site: the code flows, the contract stays still.

Before touching the first plank

Three things, in order:

• Inventory the contract. Every URL that exists and every URL that gets visits, the forms and where they land, the subdomains and the email. Whatever isn’t on that list is what breaks on switch-over day.
• Decide what will not change. Addresses above all. If one has to change, it gets its permanent redirect from day one, not “when there’s time”.
• Write down how to go back. A full copy before starting and the procedure to restore it. A rollback plan that isn’t written down doesn’t exist.

Plutarch didn’t solve the paradox, and it probably has no solution. But the Athenians didn’t need one either: they looked after the ship plank by plank for centuries and nobody ever stopped recognising it. A website works the same way. Whether it stays the same comes down to one thing: that nobody outside notices the day it stopped being the old one.