Eleven frontend repositories consume a design system published to a private registry. The median application is four minor versions behind and a token change takes seven weeks to reach every application. The team wants one monorepo. Give the sequence under live weekly releases, where state can diverge, the point of no return, and how long it really takes.

The sequence

1. Unify the toolchain before moving a line of code. Same TypeScript major, same lint config, same bundler major in all eleven repositories, each still releasing independently. This is where the seven weeks actually go, and every step is reversible because nothing has moved.
2. Create the monorepo and move repositories in with history (git filter-repo or subtree), one per week, each keeping its own pipeline. The design system keeps publishing to the registry. Nothing about consumption has changed yet.
3. Add build-graph scoping and a remote cache before the third application lands. Eleven applications rebuilt on every commit costs a CI bill and roughly 40 minutes of feedback, and teams route around it by skipping checks. Prove the scoping on a token change: it must rebuild the consumers and nothing else.
4. Flip one application to the workspace source dependency while the other ten stay on the published version. This is the dual-consumption window and the interesting part of the migration.
5. Move the remaining applications, then delete the registry publish.

Where state can diverge, and how you would know

During step 4 the same component exists twice: compiled in the registry artifact and built from source. A token fixed in source is still wrong in the published package until it is released, so in production two applications on the same page of the same product render different spacing. If any application also composes remotes at runtime, two copies of the framework can be loaded at once, which breaks context and hooks rather than looking slightly off.

Detection is visual, not unit-level: render the component gallery from both sources on every commit and diff the screenshots. A text test will not see a four-pixel difference that a designer will see immediately.

The point of no return

Deleting the registry publish. After it, no application can pin an old version, so a breaking change must be fixed for all eleven consumers in the same commit. That is the benefit — the seven weeks collapse to one review — and it is also the new failure mode: one bad change stops the line for everybody, so it must land with a working revert and a codemod, not with a migration note.

Rollback at each stage

Steps 1-3 revert by pushing to the old repository, which still exists and still builds. Step 4 reverts by changing one dependency specifier back to a version range. After step 5, rollback means re-publishing, so keep the publish pipeline dormant rather than deleted for a quarter.

How long it really takes

The code moves in days. The toolchain unification and the argument about a single version policy take a quarter, because the real object of the migration is the social agreement that upgrades are the owner's job, not the consumer's.

When not to do this

If the applications have genuinely different release cadences and regulatory sign-off — a bank's public site and its trading terminal — the pinning the monorepo removes is a control someone paid for. Keep separate repositories and fix the stalling upgrades with an automated dependency-bump bot and a deprecation deadline instead.