Skip to main content
Khang/eng
April 20, 2025 2 min read

From React/Redux to Angular: Lessons from a Solo Migration

I rewrote a fragmented multi-app React frontend into a single Angular application. The initial load dropped from 7 seconds to under 1. Here's what went right and what I'd do differently.

Angular React Migration Architecture

PRIMUS was the premium recruitment platform at Navigos Group. When I joined as the sole frontend developer, the frontend was several React applications written in plain JavaScript, connected by messy Redux stores. Initial page load took 7 seconds. Switching between features took about 3.

I rewrote it as a single Angular application. The load dropped to under 1 second. Cross-feature navigation dropped to under half a second. This post is about what went right, what surprised me, and what I’d do differently with hindsight.

Why Angular, not React

The obvious question. The existing React apps were in plain JavaScript with tangled Redux. The issue wasn’t React. It was the implementation: no TypeScript, no module boundaries, shared global state that nobody understood.

Angular was the right choice for this specific project for two reasons. First, its opinionated structure (modules, services, dependency injection) enforced the boundaries that the React codebase lacked. I needed guardrails more than I needed flexibility. Second, I was the only frontend developer. Angular’s built-in solutions (routing, HTTP, forms, RxJS for state) meant fewer decisions and fewer dependencies to evaluate. When you’re solo, reducing decision fatigue matters more than picking the theoretically best tool for each job.

The migration strategy

I didn’t do a big-bang rewrite. That would’ve meant months with no shipping. Instead:

  1. New features shipped in Angular from day one
  2. Shared functionality got extracted into Angular services as I touched it
  3. Legacy React screens got rewritten when they needed significant changes
  4. The Redux stores were replaced one at a time, starting with the ones that caused the most bugs

The whole process took about 18 months alongside feature work. 89 Jira tickets, all completed solo.

The tracking system

This was the most interesting technical challenge. Product managers had zero usage data. They made decisions about feature priority based on gut feeling and customer complaints.

I built an event-driven tracking system that let any component hook into the tracking workflow. A component could register a tracking handler that modified the payload before it shipped. So a “page view” event could be enriched by the active module (which candidate pipeline stage), the current search context (what Boolean query), and the user’s permission level, without the tracking system knowing anything about any of those.

The system was composable. You could add, modify, or filter events from anywhere. Product managers got real usage data for the first time.

What I’d do differently

I wouldn’t pick Angular again. Not because Angular is bad. It worked well for this project. But today I’d use SvelteKit or Next.js. The ecosystem has moved, and Angular’s verbosity (decorators, modules, DI configuration) adds real overhead when you’re solo.

I also wouldn’t wait 18 months for a gradual migration. The dual-framework period (React and Angular running side by side) was the most painful stretch. If I could redo it, I’d push for a 6-month focused rewrite with feature freeze on the legacy side.

The product was eventually discontinued for business strategy reasons. Not technical ones. The code was solid. Sometimes that’s how it goes.