Flagship · Enterprise modernization

Modernizing 150+ enterprise sites without breaking what made each one work.

Restoring mobile access meant changing live, revenue-bearing experiences without losing the branding and program rules clients depended on. My role was to make that change safer for participants, clients and the team delivering it.

Illustrative scene · AI-generated

My role: Initiative lead · design & delivery
Scope: 150+ live program sites
Timeline: Six-month rollout

1What was at stake

A decade of custom themes, and participants who could not use their phones.

An enterprise loyalty and incentives platform ran more than 150 branded program sites for its clients. Many sat on older templates with bespoke styling and program-specific rules, built up over relationships that in some cases went back a decade. Several clients paid seven figures a year and ran multiple programs each.

Participants on some of those programs could not use the mobile apps at all. Those clients were frustrated, and some were signalling they might leave. Every migration was a change to a live, revenue-bearing experience.

2Why I sequenced by participant access

Sequenced by who was locked out, not by who paid the most.

The programs arrived pre-ordered by the previous year’s gross profit. Following that order would have been the easy thing to defend internally.

Constraint: Migration capacity was limited, and the revenue-ranked order put the largest accounts first regardless of how well their sites currently worked.
Decision: I re-sequenced with the team by participant impact and churn risk. The single highest-revenue program was held at medium priority because it was stable and low-risk. Programs whose participants could not reach the mobile experience went first.
Consequence: The most visible harm was addressed earliest, and the at-risk relationships were the ones that saw movement soonest. The cost was that the biggest account waited, which had to be explained and agreed rather than assumed.

3How I let two designers change 150 live sites safely

Guardrails in the theme system, not instructions in a document.

The risk was not that a teammate would work carelessly. It was that 150 bespoke themes offer a hundred ways to break a program that nobody would notice until a participant did.

Constraint: Two designers new to the platform had to edit production themes for major clients, at pace, without a staging environment per program.
Decision: I split the theme system so the safe surface was the only convenient one: brand variables they were expected to change, a theme configuration layer they were told not to touch, and a separate space for sanctioned custom work. Demo sites became the staging area, with the client previewing there before anything reached production, and production sites had to be locked before any edit.
Consequence: Less freedom per site, and a slower first week while people learned the runbook. In exchange, the common ways to damage a live program stopped being reachable by accident.

V5 migration runbook — excerpt

Transcribed from the migration runbook I wrote for the team. Client names, program names, colleague names and internal system paths removed.

Staging: Build on the demo site. Copy to production only after the client previews and confirms.
Production: Lock the site before any edit. Unlock only when the work is complete and approved.
Safe to change: Brand variables, prefixed --brand-, carry the client’s branding.
Do not change: Theme Config variables. Ask before removing any template token.
Custom work: Create Designer Variables for overrides; do not fork the base theme.
Scope: Public CSS in the public banner, private CSS in the private banner, so a change lands on the intended pages only.
Check: Every page styled to the client’s brand, with no UI or responsive defects, before hand-off.

How the team was brought up

Kickoff, then a shadow session migrating the first site while both watched
Sites assigned individually only after that walkthrough
Revision requests routed through account managers to the assigned designer
I stayed on point for technical questions throughout

4When the rollout cannot move forward

A safe release includes a path to pause.

Missing assets, access problems and delayed approval change the work. The journey connects those interruptions to the people and gates that keep an unfinished change from reaching participants.

This new reconstruction brings together the runbook, training and meeting notes. Documented rules are separated from inferred recovery loops and unanswered rollback questions.

5How the rules can be tested

Turn release guardrails into explicit checks.

The migration notes make release safety concrete: demo and production have different controls, and production stays locked until the work is complete and approved. A small rule model makes those dependencies inspectable.

This newly developed example exercises incomplete work, delayed approval, failed QA and the ready state. It illustrates how documented UX and operational requirements can become unit tests; it is not evidence of automation in the historical platform.

Source-informed example · TypeScript + Vitest

Release gates as executable rules

New portfolio code developed from the notes—not original product code or historical test coverage.

Demo preview does not require a production lockpreview-demo
Production must be locked before editinglock-before-editing
Incomplete work stays lockedkeep-locked
Waiting for the client stays lockedkeep-locked
Failed QA stays lockedkeep-locked
Complete, checked and approved work can be unlockedeligible-to-unlock

Read the executable unit test

The scenarios above run as parameterized tests. This focused test also runs verbatim in the local suite.

it('keeps unapproved production locked', () => {
  expect(releaseDecision({
    environment: 'production', locked: true,
    updatesComplete: true, qaPassed: true,
    clientApproved: false,
  })).toBe('keep-locked');
});

The runbook supplies the lock, completion, approval and QA requirements. Their combination into a pure function is a new reference model—not the platform’s original release mechanism.

Migration runbook · E1 ↗

6What actually happened

All 150+ sites moved, over six months.

Every program site moved to the responsive framework across a six-month rollout. Participants on programs that had been effectively desktop-only got a mobile experience that worked, and theme-related support requests were noticeably quieter afterwards.

7Reflection & next steps

Make safety repeatable—and define success before the rollout.

The strongest part of this approach was connecting participant access to release decisions. Prioritization addressed the most immediate harm, while a constrained theme system and client-preview gates gave a growing team a safer way to deliver.

The tradeoff was less freedom per site and a slower first week. The measurement gap also matters: a quieter support queue is an observation, not a quantified result. I would build the baseline into the next modernization effort rather than try to reconstruct it afterwards.