Rewriting an Angular App to React Without Stopping Development
How we migrated from Angular 14 to Next.js 16 while keeping the live app running — and the lessons we learned about incremental rewrites.
Rewriting a production frontend is risky. Users don't care about your tech stack — they care that the site works. Here's how we migrated from Angular 14 to Next.js 16 without downtime and without slowing down feature development.
Why Rewrite
The original hrva.cc frontend was built in Angular 14 with Material Design components. It worked, but the development velocity was slowing down. Adding new features required navigating Angular's module system, dependency injection, and RxJS streams. The team wanted React's simpler mental model, Next.js's server-side rendering for SEO, and the broader ecosystem of React components.
The Dual-Deploy Strategy
We deployed the new React frontend to app.hrva.cc while the old Angular app
remained at the root domain. During the transition period, both apps were live. The backend
API served both — the API was already versioned, so both frontends could coexist. Users
who found the new app at app.hrva.cc could use it immediately, while existing
bookmarks to the root domain still worked.
What We Kept
The backend API stayed unchanged during the rewrite (it was already well-designed with RESTful endpoints). The data model, authentication flow, and business logic were identical. The rewrite was purely a frontend concern — the backend didn't know or care whether Angular or React was talking to it.
What We Redid
The entire UI was rebuilt from scratch with a new design system — glassmorphism cards, amber accent colors, dark theme by default, responsive layout. We replaced Angular Material with Radix UI primitives and Tailwind CSS. The state management went from RxJS to TanStack Query. The build system went from Angular CLI to Next.js with TurboPack.
The Switch
After a month of parallel operation, we switched the root domain's DNS to point to the new frontend. The old Angular app was decommissioned. The entire migration took 3 months from decision to completion, with zero user-facing downtime. The key lesson: a gradual, coexistence-based migration is less dramatic than a big-bang rewrite, and it's safer.