May 18, 2026 · 1 min read
Migrating a B2B platform from AngularJS to Angular 16
What actually decides a large migration: not the framework upgrade, but how you slice the work so twenty-five engineers can ship in parallel without blocking each other.
The CPQ platform I worked on had been running on AngularJS for the better part of a decade. It worked. Sales teams used it daily, and nobody was allowed to stop using it while we replaced the engine underneath.
The instinct on a migration like this is to plan a big rewrite and hold a launch date. That plan fails quietly: the codebase keeps moving while you rewrite it, and by the time the new version is ready it is already behind. What worked instead was slicing the application into micro frontends and moving one slice at a time, with both versions running side by side behind the same shell.
Slicing is the real design work. A slice has to be small enough that a pair of engineers can finish it inside a sprint, and self-contained enough that it does not need three other slices to land first. Where the old app shared state freely, we had to draw a boundary and make the contract explicit before anything could move.
With twenty-five engineers across time zones, the constraint was never typing speed — it was coordination. Every ambiguous boundary turned into a meeting, and every meeting cost a day. The slices that shipped fastest were the ones where the interface was decided before the work started.
The test strategy carried the risk. We held Jasmine/Karma coverage at 80% on migrated code, not because the number matters, but because it forced each slice to be testable in isolation — which is the same property that made it safe to ship on its own.