Changing the Foundation Without Disrupting the Business
At Onaroll, I mapped an unfamiliar production system, learned a new deployment platform, and implemented most of a live Create React App and Heroku migration to Next.js and Vercel without downtime or known production defects.
About three weeks after joining Onaroll, I learned that the flagship product had a countdown timer attached to one of its load-bearing technologies. The live rewards platform served thousands of people every day, and its Create React App deployment path on Heroku was being retired within months. This was not modernization for its own sake. It was a business-continuity problem with a fixed deadline: change the foundation beneath a transactional production system without disrupting the people who relied on it.
Controlled risk under a countdown
Changing the foundation without disrupting the business
Zero-downtime migration runway
- System mapping
- Staging and test environments
- Database backups
- Rollback plan
- Subdomain rehearsal
- Low-traffic launch window
- DNS and environment switch
- API and CS monitoring
Hidden risk · hidden potential
Understand first. Decide second.
System topology
Modernizing the frontend while preserving the wider system
Launch-day signals
Launch day was verification, not discovery.
The impact path
Inherited
Three weeks after joining, I learned that the flagship rewards product depended on a Create React App deployment path that was being retired within months.
Owned
I mapped the existing application, infrastructure, services, integrations, and deployment dependencies before changing the production foundation.
Changed
I began by building a reliable mental model of where the React application, Django services, AWS components, deployment configuration, and integrations lived and how they depended on one another.
Result
0 — Known launch defects
What I inherited
The problem and the reality around it
The problem
- Three weeks after joining, I learned that the flagship rewards product depended on a Create React App deployment path that was being retired within months.
- Thousands of people used the live system daily for transactional rewards activity, so a failed migration could interrupt access, transactions, and trust.
- The frontend was only one part of an unfamiliar production environment that also included Django services, AWS infrastructure, external integrations, and multiple deployment environments.
The constraints
- No downtime or loss of user access
- Existing Django, AWS, and external-system dependencies
- A fixed deprecation deadline
- A small team carrying concurrent product work
- I was learning Vercel while designing and implementing the migration
What I owned
My responsibility in the work
I mapped the existing application, infrastructure, services, integrations, and deployment dependencies before changing the production foundation.
I designed the migration path and implemented most of the Create React App and Heroku transition to Next.js and Vercel.
I owned rollout planning, staging and test environments, backups, rollback procedures, launch timing, production validation, and cross-functional coordination.
I continued leading the team, holding one-on-ones, onboarding a new engineer, and supporting ongoing product delivery throughout the migration.
I made my own evidence-based assessment of an engineer whose work had been undervalued rather than accepting an immediate performance-plan recommendation at face value.
How I approached it
Decisions, tradeoffs, and delivery
Before writing migration code, I mapped where everything lived. The React application was only one part of an environment that also included Django services, AWS components, external integrations, and multiple deployment configurations. I was learning Vercel for the first time, so I reduced risk through preparation rather than pretending familiarity. I created staging and test environments, researched and rehearsed every step, prepared database backups and rollback procedures, and used a temporary subdomain to validate the new platform under production-like conditions. When the system behaved consistently, I used analytics to choose a low-traffic launch window. The final cutover was intentionally simple: controlled DNS and environment changes followed by immediate validation through API logs and Customer Success monitoring. Launch day became verification instead of discovery.
- I began by building a reliable mental model of where the React application, Django services, AWS components, deployment configuration, and integrations lived and how they depended on one another.
- I created dedicated staging and test environments, researched each migration step, rehearsed the rollout, backed up the databases, and documented rollback paths before touching production.
- I used a temporary subdomain to validate the new platform under production-like conditions and tested as many failure scenarios as I could identify.
- Once the new environment behaved consistently, I used product analytics to identify a low-traffic launch window and reduced the final cutover to controlled DNS and environment changes.
- After launch, I monitored API logs and worked with Customer Success to catch both system-level failures and real-user problems that telemetry alone might miss.
- I helped an underestimated engineer find visible ownership around his strengths, including becoming the team’s Retool specialist. After layoffs ended my tenure, he later earned a promotion.
How I led
The team and stakeholder system
The migration was only one part of my role. I continued leading the team, holding one-on-ones, onboarding a new engineer, coordinating with product, design, infrastructure, QA, and Customer Success, and protecting ongoing product work. Very early in my tenure, I was encouraged to place an engineer on a performance improvement plan. I asked for time to make my own assessment. I discovered that much of his value had been hidden rather than absent. By helping create visible ownership around his strengths, including his work as the team’s Retool specialist, I helped make his contributions easier to recognize. After a company layoff ended my tenure along with the other recent hires, he later earned a promotion that I was genuinely happy to see.
Results
What changed
0
Known launch defects
The migration reached production with zero known defects. · Team outcome
No Downtime
User disruption
Thousands of daily users retained access to the transactional rewards product throughout the cutover. · Team outcome
≈ 30%
Delivery velocity improvement
Team delivery velocity improved by approximately 30% during my tenure. · Shared outcome
6 months
Hard delivery window
The migration completed before the existing deployment path expired. · Shared outcome
Leadership evidence
How I moved the people system
- — I balanced direct implementation with operational risk management, team leadership, onboarding, and ongoing product delivery.
- — I refused to make an irreversible personnel decision before gathering my own evidence and understanding the engineer’s actual strengths and contributions.
- — I helped create ownership and visibility around an underestimated engineer’s work; he later earned a promotion after my tenure ended.
- — I treated both production systems and people with the same discipline: understand first, decide second.
Technical evidence
How I moved the product system
- — System and dependency mapping across React, Django, AWS, Heroku, and external integrations.
- — Create React App-to-Next.js and Heroku-to-Vercel migration for a live transactional product.
- — Production-like rehearsal through staging, test environments, a temporary subdomain, backups, and rollback procedures.
- — Analytics-informed launch timing, DNS and environment cutover, API-log monitoring, and Customer Success validation.
Technical footprint
Technologies and system areas
What I took from it
The lesson I carry forward
The migration completed with no downtime and zero known production defects because the dangerous work happened before launch. The project reinforced that high-risk engineering is primarily an exercise in reducing uncertainty. Successful migrations come from understanding systems before changing them; responsible leadership comes from understanding people before judging them. In both cases, my approach is the same: investigate carefully, create visibility, prepare for failure, and act only when the evidence supports the decision. The best migrations are often the ones users never realize happened.
Featured work