From pilot to portfolio

Source · CMS snapshot (seed) — this blog body is served from content/generated/cms-snapshot.json, not the code catalog alone. Staff path: Content Studio (:3030 /experience/sites) → Blog tab → publish → MCV_CONSOLE_URL=http://localhost:3030 pnpm --filter @mcv-tech/marketing-shell content:seed → rebuild :3050. Offline: MCV_CMS_SNAPSHOT_FILE=… pnpm content:seed.

Nobody credible replatforms a portfolio in one move

The operators who get durable value from a shared platform do not start with a portfolio-wide migration. They start with a pilot that is small enough to reason about and real enough to matter.

What a credible pilot looks like

• One workflow, one owner. A bounded process — say, location-level approvals for one brand — with a named operator accountable for it. The pilot rollout checklist turns this into a sequence.
• Explicit proof criteria, written down first. What number or behavior has to change, by when, for this to count as working?
• Existing systems stay authoritative. During the pilot, the current system of record keeps its job. The platform earns authority; it is not handed it.
• A review date on the calendar. Expansion is a decision made on evidence at a known time — not something that drifts into place.

What expansion looks like

When the pilot proves out, the next unit inherits everything: the sign-on, the data boundaries, the approval gates, the audit trail. That is the entire economic argument for a shared platform — the second brand costs a fraction of the first, and the tenth costs less than the second.

When the pilot does not prove out, you have lost one bounded workflow's worth of time — not a portfolio migration.

What we will not tell you

We will not tell you a rollout takes X weeks, because we have not seen your operation. The honest version is the method above — and the method is what the product is built around.