The new logo is approved. The presentation looks good. Then a customer clicks an old advert, lands on an unfamiliar website and asks whether the business has changed ownership. That is the moment a rebrand becomes an operational project rather than a design project.
A rebrand rollout checklist should connect the identity to every place a customer needs to recognise, find or trust the business. Our proposed approach is to treat continuity as a launch requirement: people should understand what changed, what did not, and what they need to do next.
Start with a brand asset audit. It can help distinguish a cue worth preserving from one that exists only in the brand guidelines. This article focuses on executing the approved change, not deciding whether the company needs a new identity in the first place.
Define the scope before setting a date
Write down exactly what is changing: visual identity, public name, domain, product names, positioning, packaging or some combination. Keep legal entity changes separate from marketing language and have the relevant advisers review their implications. A visual refresh does not inherently require a domain migration.
Specify the customer-facing explanation in plain language. “Our name is changing; your subscription and support contact remain the same” answers a practical question, provided it is true. A slogan about a new chapter does not tell an existing customer whether an invoice or renewal email is legitimate.
Assign one accountable launch owner and separate owners for design, website, customer support, sales, packaging and measurement. Every task needs a due date and evidence of completion. “Website updated” is not evidence that checkout, password reset and confirmation emails still work.
Create a touchpoint inventory with priorities
Walk through how someone discovers, buys, uses and recommends the business. Capture search results, social profiles, ads, landing pages, checkout, invoices, contracts, email templates, app listings, retailer pages, support articles and physical signage where applicable.
Prioritise by confusion risk, not visual prominence. A rarely visited investor presentation may be less urgent than an automated payment email still using the old name. A recognisable storefront sign may matter more than replacing every historic social post before launch.
Use four fields for each touchpoint: owner, intended change, verification method and fallback. For a confirmation email, the verification might be a completed test purchase. For a retailer listing, it might be a dated screenshot and confirmation from the account manager. Keep the list specific enough that another colleague can check it.
If URLs change, treat search migration as a separate workstream
Google’s site-move guidance recommends mapping old URLs to their new destinations, updating internal links, redirecting directly to the final location and monitoring the move. It also advises separating major changes where possible and warns that rankings can fluctuate while pages are recrawled.
Build a URL map before launch and test representative journeys, including linked images and downloads. Check canonical tags, sitemap URLs and indexing settings on the destination. Do not redirect every removed page to the homepage simply because it is convenient. Use an appropriate replacement where one exists and the correct error response where it does not.
Keep the old domain operational for the redirects and plan its ownership and renewal explicitly. A completed logo project is not a reason to let an old domain lapse. Migration timing and search recovery are not guaranteed; give the technical team responsibility for monitoring rather than promising “zero SEO loss” in the launch deck.
Rehearse a customer journey before announcing the change
Use a controlled pre-launch environment to follow the journeys that earn trust: visit a landing page, ask a question, make a purchase, reset a password, request support and download a document. Check mobile as well as desktop. Use test accounts and approved test payments rather than real customer records.
Ask someone outside the project team to explain which business they think they are dealing with at each step. If the website says one name, the payment descriptor another and the email a third, decide how the relationship will be explained. Some differences may be necessary, but they should not be accidental.
