Enterprises with material investment in legacy frontend stacks face a recurring choice when adding AI features: rewrite, bolt-on, or integrate. Two of those answers cost a year and a budget. The third is the one that actually ships — and the patterns that make it work without inheriting the mess.
Enterprises adding AI to legacy software are usually offered a binary choice — rewrite or bolt-on. Both lose. Rewrites stall at eighteen months while the legacy product keeps evolving; bolt-ons accumulate their own legacy by year two. The third option — strategic integration through a deliberate, typed boundary between the legacy host and modern modules — is what teams that ship reliably actually choose.
Almost never. Rewrites of enterprise products require rebuilding years of customer-driven, often undocumented behaviour while the original product continues to evolve. The two timelines diverge and the rewrite rarely catches up. Strategic integration — keeping the legacy shell and injecting modern modules through a typed boundary — ships faster and survives longer.
No. The transport mechanism matters less than the integration boundary. Module federation is one fit among several. The pattern that consistently works is a small, deliberately designed contract between host and modules, regardless of whether federation, single-spa, or a hand-rolled loader carries it.
Treat the integration boundary as an architectural decision with a named owner, not as a per-feature improvisation. Every new module integrates the same way. Bundle hygiene, versioning, and graceful degradation are platform-level concerns, not per-team. Most teams that end up with bolt-on legacy got there by skipping ownership of the boundary.