A 14-Month Rebrand Timeline Is an Architecture Document
Read it as one and it tells you precisely where your design system is stored, which is the same thing it will tell you at the next rebrand.
A rebrand timeline counts update operations rather than creative work. Changing one brand color across a 120-site estate is 120 separate sequences of open, edit, test, QA, and sign-off, and that arithmetic is the timeline.
Where design tokens are stored decides everything downstream. Tokens held on each site require an update per site, and the QA cycles and approval routing scale with that operation count.
An enterprise running 150 connected sites moved design control to the platform level and reached up to 10x faster website creation and rollout. Standardized design now holds across all 150 sites regardless of what local content teams do.
The rebrand brief is signed. The new identity is complete, delivered on a three-month project schedule. The creative work is solid. Then the implementation timeline comes back: 14 months.
The project manager isn’t being unreasonable. 14 months is accurate given what the architecture requires: updating 120 sites individually, QA’ing each one, and routing approvals through stakeholders in each market. The creative work took three months. The implementation will take nearly five times as long, and none of that additional time adds creative value.
Enterprises that accept year-long rebrand implementations without questioning the architecture that produced the timeline will encounter the same estimate at the next rebrand.
What the Rebrand Implementation Timeline Is Actually Counting
The Design Decision Versus the Number of Destinations
The design decision to change the primary brand color took an afternoon. The implementation timeline for that change in a 120-site estate has nothing to do with the decision and everything to do with the number of destinations where the change must be executed manually.
How Design Variables Are Stored in a Traditional CMS
In a traditional CMS deployment, each site holds its own configuration of design variables: color values, typography definitions, spacing tokens, component styles. There is no mechanism for sharing these definitions across sites. When a design variable changes in the new identity, it changes at the source, but the source is replicated across every site in the estate. Someone must go to each one.
The Arithmetic of 120 Separate Operations
For a single color change in a 120-site estate, that means 120 separate operations: open the site, locate the variable, apply the change, test the rendering, QA the affected components, and get sign-off. That sequence repeated 120 times is the 14-month implementation timeline. The complexity is arithmetic.
How Design Token Storage Determines the Rebrand Timeline
Where the Variable Actually Lives
Design tokens are the smallest unit of a design system: the variable that holds the value “primary blue is #0047AB.” In most enterprise CMS deployments, that variable is stored locally on each site, which makes changing it a site-level operation. In a centralized design system, the variable is stored at a shared infrastructure level, and changing it once changes it everywhere.
Why QA and Approval Cycles Scale With Operation Count
The implementation timeline for a rebrand is determined by where the design tokens are stored, because tokens held on each site require an update on each site while centrally held tokens require one. The rest of the timeline, the QA cycles, the approval routing, and the stakeholder sign-offs, scales with the number of update operations. Reduce the operations and the timeline contracts.
What 10x Faster Rollout Looks Like Across 150 Sites
CANCOM, an IT services enterprise, manages 150 connected sites through centralized design management. Design changes that previously required individual updates at each site now propagate from a single point. The result was up to 10x faster website creation and rollout across the full estate. Larissa Engel, Team Lead Graphics and Design at CANCOM, explains:
Before, design changes required endless coordination and manual updates. Now, we can roll out improvements with a few clicks. It’s freed up our team to focus on creativity rather than maintenance.
Per-Site Tokens vs Centralized Tokens: What the Same Rebrand Requires
| Rebrand Element | Tokens Stored on Each Site | Tokens Stored at Platform Level |
|---|---|---|
| One primary color change, 120 sites | 120 open, edit, test, QA, sign-off sequences | One token update, propagated automatically |
| QA cycles | Scale with site count | Scale with component count |
| Approval routing | Stakeholders in each market, per site | Once, at the design system level |
| Phase structure | Staged by site count | Staged by design system component |
| Brand state during transition | Old and new identity live simultaneously | Estate updates together |
| Typical timeline against 3 months of creative work | 11 to 14 months | Weeks |
None of the rows on the left describe creative difficulty. They describe an operation count, which is why the estimate arrives from the implementation team rather than the design team.
What Centralized Design Control Looks Like at 150 Sites
Tokens Stored at the Platform Level
Design tokens and global style variables live at the platform level rather than the site level. A change to any token propagates to every site that references it without additional operations.
Shared Component Definitions and Templates
Component definitions and templates are shared across sites, so a structural change to a component updates everywhere the component is deployed.
Role Separation Between Design and Content
Role-based permissions separate design control from content control. Local teams manage their content within approved component boundaries, without access to modify the design variables those components use.
CANCOM implemented this structure across 150 sites spanning multiple internal teams and external agencies. The design outcome is consistent across the full estate despite the distributed operational model, because standardized design is automatically guaranteed across all 150 websites regardless of what local content teams do. For a rebrand, that structure turns the implementation of a new identity into a series of token and component updates applied once, rather than a coordination project requiring 150 separate executions.
Why a Phased Rebrand Is a Concession to the Operation Count
What the Phase Structure Is Really Managing
Most year-long rebrand implementations are organized as phased projects: the flagship site and primary markets in phase one, regional and division sites in subsequent phases. This is presented as risk management. In practice, it’s a concession to the operation count.
The Inconsistency Window It Creates
The phased structure means the brand is inconsistent during the transition period, with the primary markets carrying the new identity while the secondary and tertiary sites still carry the old one. The brand fragmentation the rebrand was intended to resolve is replaced by brand fragmentation between the old and new identities running simultaneously across the estate.
How Centralized Deployment Changes the Phase Structure
A centralized design architecture changes the phase structure. Updates deploy to all sites simultaneously when the token changes. The implementation is still staged by design system component, though no longer by site count. The transition window is shorter, and the inconsistency window closes.
The Architecture Decision That Set the Timeline
An 11-Month Estimate and Where the Tokens Were Stored
In 2021, I was reviewing the implementation scope for an enterprise rebrand. The design team had built a full identity system. The implementation team had mapped every site that needed to change. The project estimate was 11 months.
When I asked where the design tokens were stored, the answer was: in each theme, locally on each site. Eleven months was the correct estimate for what the architecture required.
The Decision Made Three Years Earlier
The decision that produced that estimate had been made three years before I saw it, when the sites were originally built and nobody had prioritized centralized style management because rebrands weren’t on the roadmap. This year’s rebrand will get the same answer if the 2021 architecture is still in place.
How to Read Your Rebrand Estimate as an Architecture Signal
Ask Where Design Tokens Will Be Stored
Before the next platform selection or site build, ask explicitly where design tokens and global style variables will be stored. If the answer is locally on each site, that answer is your future rebrand timeline.
Split the Timeline Into Decisions and Deployment Operations
When evaluating the scope of a rebrand, separate the implementation timeline into design decisions and deployment operations. If deployment operations account for more than 30 percent of the total timeline, the architecture is the constraint rather than the design complexity.
Treat the Estimate as a Measurement
An 8-month estimate on a 100-site estate is a signal about where style control lives, and project management has very little room to move it.
Question What Drives the Phase Structure
If a phased rebrand is being proposed, ask what drives the phases. A structure driven by site count rather than design complexity is a workaround for per-site architecture.
This analysis applies to enterprises managing more than 20 sites under a shared brand identity. Single-site rebrands have different constraints.
A 14-month implementation estimate tells you exactly how the design system is stored. The rebrand just revealed it.
