Killing the internal NuGet feed is what pays for a monorepo migration

Price one field added to a shared DTO under a private package feed. You open a PR against the shared library, bump the version, then open one PR per consuming service to pick the new version up ^[4]. The post describes five terminals and five slightly stale READMEs ^[3], so call it five services: six pull requests and a version bump to move one field ^[21]. The count is irritating rather than fatal. The drift is the defect, because there is always a service running a few versions behind the contract because nobody got round to bumping it ^[5]. Consolidation turns that dependency into an internal project reference, and skew has nowhere left to live ^[6].

The migration itself is a history-rewriting job, which is where the cost sits. FilmTailor used git-filter-repo, the tool the Git project now points people towards in place of filter-branch, which is slower and carries enough sharp edges that the docs discourage it ^[16]. On macOS that is a brew install ^[17]. Because the tool rewrites rather than edits, a typo is durable, so the post's own discipline is to work in a throwaway clone, never your working copy, and to keep the result off any shared branch until you are happy with it ^[18]. It also specifies a fresh clone of the service repo rather than your existing checkout, since that checkout is about to have its history rewritten ^[19]. The destination is a new repository initialised with a README and pushed ^[20]. The text supplied to me breaks off mid-sentence before the command sequence ^[1], so read the flags there, not here.

What copying files in destroys is specific: git blame, bisectability across the service's whole lifetime, and tags and releases ^[13]. The author concedes the shortcut is faster and that nobody is going to fire you for it ^[14], and says outright that if none of those three matter, copy the files and skip the exercise ^[15]. In my context the ranking is not equal. A bisect that cannot cross the move date can be worked around by keeping the old repo readable and switching to it for old regressions. Blame is the query you run weekly, and a blame wall dated the day of the move is the artefact you cannot reconstruct afterwards.

Whether the rest of the case transfers depends on your stack. Aspire, which Microsoft now calls just that, having dropped the .NET prefix ^[8], wants to orchestrate an entire solution from one AppHost ^[7], and multi-repo is not officially supported, with maintainer David Fowler placing it mid-term rather than short-term on the roadmap ^[9]. Teams bridge that with uber solutions that clone every repo into sibling folders, with git submodules, or by shipping the shared bits as NuGet packages ^[10]. Strip Aspire and the private feed out of the ledger and you are paying a rewrite plus a CI overhaul for editor ergonomics.

That CI overhaul is the line the whiteboard drawing leaves off. The promised follow-up covers tag-triggered selective builds so a change to one service does not kick off a full pipeline run for all of them ^[22], which tells you what the default looks like the morning after you merge: every push builds everything. That bill arrives immediately, while the preserved blame history pays out over years.