Interactive systems demo · 03
Migration Control Room
Change the foundation without disrupting the business.
I led and personally implemented most of a live Create React App and Heroku migration toward Next.js and Vercel while leading a small product team. This exhibit reconstructs the engineering judgment behind the rollout: understand the system, prepare the escape route, rehearse, validate, gate production traffic, observe reality, and roll back when evidence says no.
What this makes visible
The migration was not a deploy button. It was a sequence of reversible decisions.
Build ≠ ready
A successful artifact does not earn production traffic. Environment, dependencies, rehearsal, health, critical flows, and rollback readiness are separate evidence.
Failure is a designed path
Break a health check, API contract, environment variable, rollback plan, or user flow. The system should contain risk rather than reward optimism.
Rollback can be success
If production evidence deteriorates, restoring the known-good system protects users and buys the team time to investigate without production pressure.
Guided migration walkthrough
See the decisions behind the migration while it runs.
Goal: move production from the legacy stack to the new one without dropping users — and stop the cutover if the evidence says it is not ready.
- 01ValidateProve it off the live path
- 02MigrateMove traffic on purpose
- 03VerifySee what production says
- 04ResolveStop before it gets worse
- 05CompleteStable on the new stack
What is happening now
Map it before touching production.
Every user is still on the legacy path. Before anything moves, the frontend, services, infrastructure, integrations, and deployment dependencies need to be understood.
Customers do not become the test plan.
Safeguard activated
Absolutely not, Brenda.
- Brenda attempted
- Move production traffic before every release gate was green.
- Control Room response
- Nope. Production stays on the known-good system.
- Why it stopped
- Something still has not earned a green light.
- Why that matters
- Shipping anyway would turn a known warning into a customer-facing problem.
- What happens instead
- Stop here, fix the blocker, then try again.
Mission report
Migration complete
The new stack is serving production. The gates are green and the evidence is still visible.
- Legacy traffic
- 0%
- Candidate traffic
- 100%
- Release gates
- 9 / 9 passed
- Still blocking
- 0
Migration simulation
Change the foundation without taking production down.
Verified project moments
Jump into conditions and decisions that were part of the real migration
Illustrative traffic ratios · rollout mechanics generalized · verified outcomes labeled separately.
What is happening
Start by understanding what production actually depends on.
Engineering decision
Production stays on the known-good system until evidence supports a change.
From the real project
We are not shipping that. Deployable ≠ production-safe.
Engineering inspector · serialized simulation state
The UI is driven from reducer state. Actions are explicit; DOM state is not the source of truth.
{
"phase": "discovery",
"trafficLegacy": 100,
"trafficNew": 0,
"gates": {
"systemMap": "unknown",
"dependencies": "unknown",
"backup": "unknown",
"rollback": "unknown",
"build": "unknown",
"environment": "unknown",
"rehearsal": "unknown",
"health": "unknown",
"userFlow": "unknown"
},
"signals": {
"api": "unknown",
"auth": "unknown",
"criticalFlow": "unknown",
"errorRate": "unknown",
"customerSuccess": "unknown"
},
"fault": null,
"brenda": false,
"decision": "Production stays on the known-good system until evidence supports a change.",
"story": "Start by understanding what production actually depends on.",
"eventSeq": 1,
"events": [
{
"id": 1,
"kind": "info",
"message": "Migration control initialized. Production remains on the legacy environment."
}
]
}Why this demo exists
Launch day should be verification, not discovery.
The original migration involved an unfamiliar live rewards platform, a fixed deployment-path deadline, thousands of daily users, and preserved Django, AWS, and external-system dependencies. I reduced risk by mapping the system before changing it, creating staging and test environments, preparing backups and rollback procedures, and validating the candidate platform through a temporary subdomain under production-like conditions.
Once the candidate behaved consistently, I used product analytics to choose a lower-traffic launch window. The final cutover was intentionally narrow: controlled DNS and environment changes followed by immediate API-log monitoring and Customer Success validation. That combination matters because dashboards can look healthy while a real customer is still telling you something important.
This reconstruction generalizes private infrastructure and operational details. The architecture and controls are here to expose the decision model, not to pretend the original production environment was a neat diagram.
Architecture direction
The control room is also our first reusable simulation engine.
Underneath the UI is a small Redux-style store contract: serializable state, explicit actions, a deterministic reducer, release gates, signals, faults, events, and outcomes.