There's a pattern I've been seeing more frequently across Angular codebases since standalone components became mainstream.
A team migrates away from NgModules. They discover loadComponent. It's simpler, requires less boilerplate, and feels aligned with where Angular is heading. So they start replacing loadChildren calls across the routing configuration — one by one, sometimes all at once.
The build passes. The application behaves exactly as before. Bundle reports may even suggest the migration was a success.
The problem is that routing decisions are judged by what happens immediately after deployment. Architectural decisions are judged six months later.
I've reviewed migrations where every loadChildren route was replaced with loadComponent in a single PR. The application kept working. Six months later the route structure no longer reflected the application's feature boundaries. Ownership became harder to understand. Shared concerns started leaking across routes. The routing configuration became flatter — but not simpler. One of those reviews turned into a two-sprint refactor that the team hadn't budgeted for.
