Zero-Pain Upgrades: Migration Schematics That ng update Finds In short: A migration is worthless if never runs it. That takes an entry in the library's pointing at a — the step most guides skip, and the reason people's first schematic silently does nothing. You have deprecated , published warnings, and given teams six months. Now you are removing it in v12. Telling twenty teams to search and replace across their templates distributes a tax across the whole engineering department, and guarantees the upgrade gets deferred until the last possible moment. Push the fix, not the burden. How finds a migration Two files, and the first one is the one people forget. 1. The library's must declare where its migrations live: Without , upgrades the version and runs nothing. No error, no warning — it just silently does not migrate. If your first schematic seems to do nothing, this is almost always why. 2. maps versions to scripts: is the version at which the migration should run. Upgrading from 10.x to 12.x runs every migration whose version falls in that range, in order — so a team that skipped a release still gets all of them. Make sure both files are in the published package: Writing the migration A template rename is an HTML change, and HTML is where naive migrations do damage. Use Angular's own template parser rather than a regular expression: Why this beats a regular expression, concretely. A regex for will happily rewrite: — a different component that happens to share the input name. — inside a comment. — documentation showing the old API. — inside a string in an interpolation. The parser knows which element an attribute belongs to and gives you exact offsets. That is the difference between a migration teams trust and one that gets reverted. Test the migration A schematic that corrupts a template is worse than no schematic. Angular provides a test harness: The last two are the ones that catch real damage. The consumer experience The team runs their tests, reviews the diff, and merges. A week of coordinated work becomes a command and a code review. When to write one Not every change deserves a schematic: Change Write one? --- --- Renamed input or output Yes — mechanical and high volume Renamed selector Yes Renamed CSS custom property Yes — a CSS text migration Import path moved Yes — TypeScript AST Component removed with a replacement Yes , if the mapping is mechanical Component removed, no replacement No — a migration note Behaviour changed No — a warning cannot be automated away A change affecting one consumer No — just tell them The arithmetic: four hours writing a schematic against twenty teams spending two hours each is a good trade. Against one team it is not. "But I thought schematics were too much work for a small rename" For one rename in one repository, this is completely right — the schematic above is a couple of hours including tests, and a find-and-replace is five minutes. The calculation changes on two axes, and the second is the one people miss. Volume. Two hours of your time against twenty teams × two hours is 40 hours saved. But that number understates it, because those twenty hours are not spent in parallel by willing people. They are spent reluctantly, spread over months, by teams who deprioritise it — which is precisely how a codebase ends up eleven versions behind. Correctness. This is the bigger one. Twenty teams doing a manual find-and-replace produce twenty chances to: Miss an occurrence in a file nobody thought to search Rename on the wrong component Rewrite it inside a comment or a documentation block Do it correctly in and forget inline templates A tested schematic makes the same correct edit twenty times. And there is a cultural effect that is hard to quantify and very real. A library team that ships migrations is a team that can afford to improve its API — because the cost of a rename is bounded. A library team that does not becomes progressively unable to change anything, because every change is a negotiation with twenty stakeholders. The schematic is what buys back your freedom to refactor. Manual find-and-replace Migration schematic --- --- --- Library team effort 0 4 hours, once Consumer effort (×20) 2 hours each 10 minutes each Occurrences missed Some, in some repos 0 Wrong component renamed Occasionally Never Upgrade deferred Frequently Rarely Library team can rename again next quarter Reluctantly Yes The honest caveats: it does not cover inline templates safely (hence the warning), it does not cover dynamic bindings, and consumers still review the diff. It converts a migration from work into a review — which is the right shape. Recap in is the step people skip. Without it, silently runs nothing. maps versions to factories , and skipped versions still run in order. Include the schematics in or they are not published. Parse the template; do not regex it. The parser knows which element an attribute belongs to. Apply edits back to front so offsets stay valid. Test for other components…