I stepped into a live product migration shortly after joining the company. The product was already in daily use by thousands of users, so the work had real stakes from the beginning. This was not a quiet internal refactor or a low-risk technical cleanup. It was a live platform move with a hard deadline.
The main issue was that the Create React App buildpack for Heroku was sunsetting. The team had about six months before the existing deployment path would stop working. Vercel was already part of the company’s technology stack, and Next.js was already being used on another platform, so the direction made sense: move the app from Heroku and Create React App to Next.js and Vercel.
But even when the technical destination is clear, a live migration is still a risk-management project.
I was new to the company, so I had to get up to speed quickly on the product, the architecture, the deployment flow, and the surrounding systems without destabilizing anything. The product was active, users depended on it daily, and once the rollout started, the migration had to happen without a single user losing access.
I drove and implemented most of the migration hands-on while coordinating across product, design, engineering, and infrastructure. My team was focused on other product work at the time, so I kept the migration moving directly and pulled in one developer near the end of implementation to help speed up the final push.
The work involved more than moving frontend files from one place to another. I had to build out the supporting architecture for the new deployment path, coordinate with AWS services, monitor and update Django, validate that existing behavior still worked, and make sure the new platform could support the product reliably.
Because the product was live, I treated the migration as a controlled rollout instead of a big-bang deploy. I used testing plans, staging environments, QA checklists, side-by-side validation, incremental migration steps, and rollback planning. I also researched product usage metrics to identify the lowest-traffic window for launch, so the rollout could happen when the smallest number of users would be affected.
The goal was simple: users should not feel the platform move underneath them.
During the monitored cutover and release-validation window, the team observed no downtime and no launch defects. Users kept access to the product, although they needed to log back in after the transition.
After launch, the move also improved the technical foundation. The product had better deployment confidence, stronger platform consistency with the company’s existing Next.js and Vercel stack, easier maintenance, improved developer workflow, and a better foundation for future product velocity.
During that same role, I was also supporting the team around the migration work. I coached a junior engineer from a performance plan to promotion, onboarded a new engineer, and kept coordination moving across product and engineering while the platform transition was underway.
This project is a good example of the kind of technical work that should feel boring to users precisely because it was handled carefully. A successful migration is not just the new stack. It is the planning, validation, communication, fallback options, timing, and calm execution that protect the people relying on the product.
