A shell loads six runtime remotes. Four belong to one team of nine engineers who already deploy together, the shared framework singleton forces a coordinated upgrade window twice a year, the composed page ships about 1.9 MB of JavaScript, and the last three incidents were a remote that returned 404. Give the sequence for folding those four into the shell under weekly releases, where state can diverge, the point of no return, and how long it really takes.

The sequence

Each step is reversible on its own, and the first step is what makes the rest reversible.

1. Make the remote list data rather than code. The shell reads a manifest at boot that names each remote and carries a flag selecting runtime remote or locally bundled. Nothing changes behaviourally. This switch is the rollback mechanism for every later step.
2. Move the four remotes' source into the shell's repository as workspace packages, still built and published as remotes exactly as before. Consumers see no change. Reversal is deleting directories.
3. Add the local import path behind the flag, so the shell can resolve the same module either way. Prove the two paths are equivalent with screenshot diffs per route and a decoded-byte report per route, not with unit tests.
4. Flip one remote at a time: 5% of sessions, then 50%, then 100%, a week apart. The flag flip is the rollback and it takes seconds.
5. Delete the remote build targets and their federation configuration once all four are local and have held 100% for a full release cycle.
6. Delete the manifest flag after one more clean cycle.

Where state can diverge, and how you would know

• Module-scope singletons. A store created at module load used to exist once per remote and now exists once in total. The symptom is state leaking between areas that were accidentally isolated — a filter set in one section appearing in another. Detect it with a boot-time assertion counting store instances, and with a per-route error-rate comparison between the two flag arms.
• Stylesheet order. Runtime-injected CSS lands in a different order from bundled CSS, so specificity ties resolve differently. This is invisible to unit tests and obvious in a visual diff, and it is the single largest consumer of calendar time in this migration.
• Shared dependency versions. Two remotes may have been on different minor versions of a utility library and relying on the difference. Bundling collapses them to one, and a lockfile diff names every collapse first.

The point of no return

Deleting the published remote entry points. Until then both resolution paths exist and the flag is enough. After it, a rollback is a redeploy of a build target you have removed. Keep the old remote URLs serving their last good bundle for at least as long as your chunk retention window, because tabs opened before the deploy still resolve lazy imports against them.

The rollback at each stage

Steps 1 to 3 are additive and revert by deletion. Step 4 reverts by flag, per remote, per cohort. Step 5 reverts by restoring a build target from version control and redeploying, about a day of work.

How long it really takes

Six to ten weeks for the four, and the code move is not the long part. Two one-week soaks per remote cannot be parallelised safely if the remotes share surface area, and visual-diff triage routinely surfaces dozens of one-pixel differences that each need a human verdict. Budget 60% of the calendar to triage. A plan that claims two weeks has not counted the stylesheet ordering work.

When this is the wrong move

If the four remotes belonged to four teams on four release cadences, or if one were a third party whose source you cannot build, consolidating them trades an independence you need for bytes you can get another way. Keep federation for the two remotes nobody on your side owns. Runtime composition earns its cost only when the owners of the fragments genuinely cannot ship together. For every other case a single application plus a versioned shared component library is faster, smaller, debuggable in one stack trace, and rollbackable as one artefact — and that includes most organisations that adopted federation because four teams wanted to deploy without asking each other.