VCS Reset vs. Re‑run ng update After a Half‑Migrated Angular Upgrade

Short answer

Roll back to the last good commit and re-run ng update from a clean tree. A forced retry with --force or --allow-dirty cannot reliably resume a half-finished migration, because Angular migrations are not idempotent and the CLI does not track which transformations already ran.

Why the reset is the predictable path

Migration schematics are written and tested against the pre-upgrade source tree. They assume, for example, that a particular import still exists or that a config key has its old shape. When ng update stops midway, earlier migrations have already rewritten files while later ones are pending. Re-running on that polluted tree gives you three bad outcomes:

• Double-applied edits: a schematic rewrites code that was already transformed, producing corrupt or duplicated output.
• Silently skipped steps: a schematic sees what looks like a post-migration state and does nothing, leaving a transformation permanently missing.
• False success: the update completes, but subtle damage only surfaces at build or runtime.

Neither flag fixes this. --force only overrides npm peer-dependency conflicts during package installation. --allow-dirty only suppresses the clean-working-tree check. Both let the update proceed; neither makes migrations re-runnable or repairs the tree.

Recovery sequence

1. Preserve anything worth keeping: git status and git stash or commit work that exists only in the working tree. Remember git reset --hard discards tracked modifications, and untracked files survive unless you also run git clean — check before doing either.
2. Reset to the pre-upgrade commit: git reset --hard <last-good-commit>. This restores package.json and the lockfile along with the source.
3. Reinstall from the old lockfile: delete node_modules and run npm ci (or your package manager's frozen-lockfile install) so the baseline dependency set exactly matches what the migrations expect.
4. Fix the root cause before retrying. If peer-dependency conflicts stopped the first run, upgrade or pin the offending package first — do not lean on --force, which can leave an inconsistent dependency set that breaks later migrations or the build.
5. Re-run ng update and let it complete uninterrupted.

Verification

• Confirm ng update exits cleanly and git diff shows only the expected migration changes — no duplicated blocks or half-edited files.
• Run ng build and ng test on the re-migrated tree.
• Compare package.json and the lockfile against the dependency set expected for your target Angular release.

Caveats

Exact flag behavior and migration idempotency vary by Angular version, and third-party package schematics can behave differently from official @angular/core migrations. The one diagnostic detail that could change this advice: if the failure happened before any source files were modified (e.g., it died during dependency resolution), a plain retry after fixing the peer conflict is safe — check git status to see whether the tree was actually touched.