The Breakdown
- The Six-Week Estimate Is Actually a Measurement of Your Architecture
- How Platform Architecture Determines Deployment Speed
- How Coordination Scales With Site Count in a Per-Site Model
- Per-Site Architecture vs. Centralized Propagation
- Why Sprint Velocity Doesn't Solve an Architecture Constraint
- What Four Months of Incomplete Rollout Looks Like
- How to Audit Your Deployment Architecture
The Six-Week Estimate Is Actually a Measurement of Your Architecture
Every deployment postmortem treats this delay as a resourcing or coordination problem. The claims below explain why it’s actually a property of the platform.
Global rollout time is set by the number of per-site operations the architecture requires.
Adding staff compresses individual site timelines slightly, but the total operation count, and the calendar, stays fixed.
Centralized template propagation collapses hundreds of individual deployments into one operation, cutting rollout time by an order of magnitude, as one enterprise IT services company’s shift to shared templates demonstrated.
In a per-site CMS, a single global design change requires one separate deployment operation per site. Adding staff compresses the timeline slightly but leaves the operation count unchanged. An enterprise IT services company that switched to a centralized propagation model reduced rollout time by 10x and cut coordination steps by 60%. The gain came from the architecture. Deployment velocity is an architectural property, which is why platform evaluations that skip a live demonstration of global template propagation consistently miss the constraint that will determine every future rollout.
The Two-Day Design Behind a Long Rollout
When the central brand team approves a design update to the header component and the primary action color, and the change needs to go live across 80 regional sites, the project manager’s estimate comes back at six weeks.
Nobody disputes the estimate; six weeks is accurate. But what is rarely examined is what those six weeks are actually counting.
The design work took two days. The six weeks that follow are deployment time: the hours required to execute the same change across 80 separate site instances, each touched individually, tested individually, and approved individually.
Adding a Designer Doesn’t Halve the Timeline, Here’s Why
In a traditional CMS deployment model, each site holds its own copy of the template. There’s no mechanism for propagating a style change across all instances. Someone must make the change at each destination, in the correct context, without breaking the surrounding configuration. In an estate of any significant size, that work is distributed across a team, but the total volume is determined by the site count regardless of the complexity of the change.
So you see, the six-week timeline stays close to six weeks regardless of team size, because the bottleneck is the number of separate operations the architecture requires for a single change. The timeline is measuring the architecture.
How Platform Architecture Determines Deployment Speed
The Per-Site Model’s Structural Behavior
The time required to deploy a global change across an enterprise estate is a direct output of how the platform stores and propagates templates.
Platforms built on separate site instances require separate update operations, and that is the structural behavior of the system. Governance workflows and QA checklists can be layered on top to reduce errors, but they don’t reduce the operation count. Each governance layer adds its own overhead to an architecture that already requires one separate operation per site.
What Centralized Propagation Changes
A platform designed for centralized propagation holds shared templates at a single point. When a style changes, it changes everywhere the template is applied, without individual operations at each destination. The deployment calendar is determined by the time required to approve and publish once, not by the number of sites in the estate.
CANCOM manages 150 connected sites through a shared template infrastructure using Greyd.Suite. Design changes that previously required individual updates and approvals at each site now propagate centrally. The result: up to 10x faster website creation and rollout, and 60% fewer coordination steps. Larissa Engel, Team Lead Graphics and Design at CANCOM:
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.
The 10x result is the arithmetic difference between executing one central change and executing 150 individual changes. There’s no process improvement that closes a gap of that size.
How Coordination Scales With Site Count in a Per-Site Model
The Fixed Cost per Operation
Every site in a per-site deployment model adds fixed coordination overhead to every global update: notification, execution, testing, approval, sign-off. For a 10-site estate, this is manageable. For a 150-site estate, a global update requiring 30 minutes per site plus two hours of coordination overhead consumes roughly 375 hours of labor before the change is complete.
The Error Surface at Scale
The error surface scales with the operation count. When 150 teams or agencies execute the same change, some execute it incorrectly, some are mid-sprint on another client, and some miss the notification entirely, leaving the estate with 147 of 150 sites updated and three still carrying the old design three weeks after the deadline. That outcome is the expected result of a model that required 150 separate executions of a change that needed to happen once.
Arthur Zwirner, Manager Content and Campaigns at CANCOM, described what changed in practice:
Finally we don’t have to edit each and every site individually if there’s a new partner or event. We edit that content centrally and can be sure it gets distributed automatically.
Per-Site Architecture vs. Centralized Propagation
| Dimension | Per-Site Architecture | Centralized Propagation |
|---|---|---|
| What triggers a global design change | Manual update at each site instance | Single change to shared template |
| Operation count (80-site estate) | 80 separate operations | 1 operation |
| Coordination overhead | Scales with site count | Fixed, independent of site count |
| QA passes required | One per site | One global pass |
| Error surface | Scales with operation count | Resolved at source |
| Timeline for a global update | Weeks | Hours to days |
| Effect of adding staff | Marginal timeline compression | Architecture eliminates the bottleneck |
| What drives the deployment calendar | Site count × time per operation | Approval and publish time |
Why Sprint Velocity Doesn’t Solve an Architecture Constraint
What Process Improvement Actually Changes
The instinct in most enterprises facing slow deployment cycles is to improve the process: tighter project management, clearer briefing templates, faster agency SLAs, more developer capacity. These interventions reduce error rates and improve predictability. They don’t reduce the number of operations the architecture requires.
An enterprise can run an excellent deployment process on a per-site architecture and still spend six weeks pushing a button color change across 80 sites. Optimizing execution doesn’t change the number of executions the architecture demands. The deployment calendar stays the same.
The Strategic Question Worth Asking Before the Next Project
Before committing budget to the next deployment improvement initiative, the first question is whether the bottleneck is in the execution or in the number of executions the architecture requires. If it’s architectural, process investment produces diminishing returns. Six weeks compresses to five, then stays there.
What Four Months of Incomplete Rollout Looks Like
A 70-Site Estate, Five Sites Behind
In 2022, I was reviewing the deployment backlog for an enterprise managing about 70 sites. The backlog contained a design change that had been in progress for four months. The change was complete on 65 of the 70 sites. The remaining five were managed by agencies with different sprint cycles, and the update had been deprioritized three times.
How Incomplete Rollout Stops Looking Like a Problem
The brand was running two versions of its visual identity in five markets, and nobody had flagged it as a business problem because four months had made it seem normal. The design had been fine from day one. The architecture was what had made four months feel like an acceptable timeline.
How to Audit Your Deployment Architecture
Timing Your Last Global Update
Measure your last global update from approval to live across all sites. If the answer is measured in weeks, the bottleneck sits in the platform rather than the process.
Evaluating Your Platform’s Propagation Model
Ask your CMS vendor how a global template change propagates across all sites. If the answer involves per-site operations, you have a per-site architecture. Add deployment velocity to the scoring criteria in your next platform evaluation and ask for a live demonstration of a global template change across a large site network.
Building the Cost Case for Architecture Change
When estimating the cost of a platform migration, include the deployment calendar of your current platform as the comparison baseline. The efficiency gain from a propagating architecture compounds over the migration cost over time.
This analysis applies to enterprises where a single design standard is intended to apply across multiple sites. Single-brand, single-site deployments have different constraints.
Learn more about Greyd.Suite!
