Rebranding a shipped product feels terrifying because every component references the old colors somewhere. Done in stages, it is a two-day job.
Day one: pick the new palette in the generator. Lock the seed, lock the rule, run the contrast table against your existing surfaces (not white — your real backgrounds). Take a screenshot of the old hero, swap the brand colors, screenshot again. Compare side by side. Decide if the new primary needs a five-point lightness adjustment to match the visual weight of the old one.
Day two: introduce the new tokens alongside the old ones. Do not rename — add. Old tokens stay intact, new tokens get a v2 prefix or a separate file. Migrate components in batches: navigation, then primary CTAs, then secondary surfaces, then accent uses. Each batch is a separate PR. Rolling back is one revert per batch.
The trap is leaving the old tokens in place forever. Set a deadline in the same PR — 'old brand tokens removed by date X'. Add a CI check that fails if any new code imports the old token. The old tokens are now on a death timer.
Communicate visually, not in text. A Slack post with old palette URL and new palette URL, both clickable, generates more useful feedback in 30 minutes than a 2,000-word announcement. The team can hit randomize themselves and propose alternates.
For marketing assets, swap colors in the largest layout files first (homepage, pricing) and let the long tail (blog posts, changelog entries) update naturally. Search-and-replace on hex codes works for static content; dynamic content updates as components re-render.
The rebrand cost is mostly social, not technical. The new tokens take two days. The team conversation about whether the new palette is 'right' takes two weeks if you let it. Constrain it: pick a date, ship the staged migration, learn from the metrics.