Standalone Without Turning NgModules Into a Villain

The better question#

In a mature Angular app, the standalone conversation should not start with 'how do we remove every module?'. Start with a smaller question: where does this feature's boundary live today, and would standalone make that boundary easier to read, load, and test?

Angular components are standalone by default in current Angular. That changes the default for new code. It does not mean a stable internal library, a third-party integration, or a legacy feature module must be rewritten before the next release.

I would keep a stable LegacyPaymentsModule if it wraps a third-party SDK, exposes a known public API, and is not blocking lazy loading, ownership, or tests. That is not nostalgia; it is scope control.

The decision table#

A route is a better boundary than a slogan#

The useful standalone migration is often a route migration. A route can lazy-load a component, scope providers, and become the place where the team sees the feature boundary without opening a module file first.

If every provider stays at root and every component imports a giant shared bucket, the code is not meaningfully more modular. It only removed a layer of ceremony.

export const routes: Routes = [
  {
    path: 'billing',
    providers: [BillingFacade],
    loadComponent: () =>
      import('./billing/billing-page.component')
        .then(m => m.BillingPageComponent),
  },
];

What to avoid#

Avoid a migration branch whose only promise is 'remove NgModules'. That kind of branch tends to touch too many files, create review fatigue, and produce little product value.

The better move is narrower: use standalone as the default for new code, migrate modules that block lazy loading or hide dependencies, and leave stable modules alone until the team has a reason to touch them.