This is Part 4 of a 6-part series on Angular Schematics.

• ✅ Part 1 - Understanding Angular Schematics: Architecture & Core Concepts
• ✅ Part 2 - Creating Custom Generators with ng generate
• ✅ Part 3 - Building Installation Schematics with ng add
• Part 4 - Writing Migration Schematics with ng update ← You are here
• 🔜 Part 5 - Testing Schematics with Angular DevKit
• 🔜 Part 6 - Advanced Patterns, Publishing & Nx Integration

🤖 A note on this article: I used Claude to help reformat and structure the content to make it clearer and more presentable for publication.

References

• Angular CLI - ng update - Official CLI reference for ng update
• Angular DevKit Schematics - Full README - Complete reference for @angular-devkit/schematics
• Angular Update Guide - How Angular ships its own migrations
• TypeScript Compiler API - TypeScript AST documentation

In Part 3 we built an ng add schematic that configured a library on first install. In Part 2 we built ng generate schematics for on-demand code scaffolding and operational tasks.

Both of those are developer-triggered - a human decides when to run them. Part 4 is about the third and final mechanism: ng update, where the CLI automatically applies code transformations the moment a developer upgrades a package version.

This is the mechanism Angular itself uses to ship breaking changes. When you run ng update @angular/core and your code is automatically rewritten to use the new API - that is a migration schematic at work. The same infrastructure is available to every library author.

By the end of this article you will have built a complete migration schematic that:

• Detects a renamed component selector across all template files
• Rewrites a changed input property binding using the TypeScript Compiler API
• Updates an app.config.ts provider registration to match a new API
• Runs automatically and in the correct order when consumers run ng update @acme/ui

Table of Contents