Re-platforming 190 brand sites
The Diageo tooling story: when the deliverable isn't the migration, it's the machine that does the migrating.
Diageo has 190 brand websites. Guinness, Smirnoff, Baileys, Don Julio, Aviation Gin, and a long tail behind them, spread across several different CMS platforms accumulated over years of acquisitions and agency relationships.
All of them needed re-platforming. Several teams of developers were going to do it. Which means the interesting problem was never any individual site.
The arithmetic that changes the job
One site migration is a project. You do the content mapping by hand, you eyeball the result, you ship it.
At 190, every manual step in that sentence becomes a defect source. If checking a single site takes a careful hour, checking 190 takes five working weeks of somebody's undivided attention. The failure mode is not "it looks wrong", it is "an alt tag quietly went missing on a brand nobody checked."
So the deliverable stopped being the migration and became the tooling several teams would use to do the migrating.
What the tooling had to do
Map the data. Each source CMS modelled content differently. The mapping between old and new had to be expressible, reviewable, and re-runnable rather than performed once by hand.
Generate the code. Where 190 sites share a target architecture, the parts that differ are configuration. The parts that are the same should not be typed 190 times.
Prove the result. This is the part people skip. Crawlers walked the old site and the new one and compared them: content, metadata, alt tags. Not a visual diff, but an assertion that the things which matter for SEO and accessibility survived the move.
Fail loudly. A migration that silently drops content is worse than one that stops, because the loss is discovered months later by a brand team wondering where their page went.
Guinness.com as the reference
One site got built first, properly, as the test project. It was the reference implementation that proved both the tooling and the target architecture before the other brands followed.
This is the part worth stealing. A reference implementation is not a pilot. A pilot asks "does this work?" A reference implementation asserts "this is the shape, and here is one built to it." Every subsequent team then has something to diff against rather than a document to interpret.
The general rule
When the same migration is going to happen many times over, stop migrating and start building the thing that migrates. The tooling costs more than doing the first few by hand, and far less than doing all of the rest that way.
And the verification tooling, the boring crawler that compares old and new, is the part that turns "we think it worked" into something you can put in front of a brand team.