A rebrand is not finished when the new logo ships. It is finished when the last hardcoded old URL dies, and I have yet to see a site where that day has come.
I recently audited a site that had been through a name change or two. The current brand was in the interface. An earlier name survived throughout the internal documentation. The code repository carried a third name entirely. And scattered through the code: three different domains, each hardcoded as a fallback in a different place, one in the email system, another in the payment flow's return links, a third in the page metadata.
None of this shows up in a demo. All of it shows up somewhere worse.
A checkout that returns customers to a domain you no longer promote, at the exact moment of highest sensitivity, straight after someone has typed in a card number. Transactional emails whose links point somewhere off-brand, training people to distrust the messages you most need them to trust. Search engines splitting your ranking authority across canonical URLs that disagree with each other, quietly taxing the organic traffic you are paying elsewhere to earn. Each instance is small. Together they are a permanent, compounding drag on conversion and credibility, invisible on any report, because nothing is "broken".
The cause is always the same, and it is never carelessness. There was a single source of truth, a setting for the site's URL. But nothing enforced it. So every developer working to a deadline, needing a sensible fallback for the case where the setting is missing, hardcoded whatever domain was current that month. Each decision was reasonable. The codebase collected them the way a riverbed collects sediment: layer by layer, each one recording the era it was written in.
Two lessons come out of this.
Configuration only works when getting it wrong fails loudly. A rule that says "always use the setting" is a suggestion, and people under pressure do whatever works on their machine. If the setting being missing caused a visible failure rather than a silent fallback, there would be nothing to hardcode around. Make the right thing the only thing that works, or accept that the wrong thing will happen, occasionally, and always in the code written during the busiest weeks.
A rebrand needs an engineering workstream, not just a design one. The launch checklist should include the unglamorous lines: search the codebase for the old names and domains, sweep the fallbacks, check canonical URLs and email templates, redirect the old domains properly, and give someone ownership, because cleanup that belongs to everyone belongs to no one. An afternoon of searching at rebrand time, or a permanent tax on every checkout, email and search ranking afterwards.
The wider point goes past names. Every big change, a new pricing model, a new domain structure, a feature rename, leaves this kind of sediment unless someone owns removing it. Codebases remember everything a business has ever been. It takes deliberate work to keep them in the present tense.
If you are planning a rebrand, the technical side is worth scoping alongside the design.
Written by
Steven Noble
Steven Noble is the founder of Graphics Cove, a senior full-stack engineer with 19 years building web products for startups and established companies. He writes about engineering, delivery and running a technical practice.