Migration guides for major versions
Why it matters
A breaking change without a migration guide forces every existing user to diff the changelog, read source code, and guess at the new equivalent. A CHANGELOG entry that says 'BREAKING: removed fetchData()' with no explanation of what replaced it is effectively a notice to abandon the project. For libraries and SDKs, major version bumps without migration guides directly translate to production outages when users upgrade: the old code fails, the new code is unknown, and the documentation provides no bridge. iso-25010:2011 analysability requires that version transitions be documentable without source inspection.
Severity rationale
High because missing migration guides force users to discover breaking changes at runtime rather than upgrade time, turning routine version bumps into production incidents for every downstream integrator.
Remediation
Create a migration guide for each major version in docs/migration/ or UPGRADING.md, with before/after code for every breaking change:
# Migrating from v2 to v3
## Breaking Changes
### `fetchData()` renamed to `query()`
**Before (v2):**
```ts
const data = await client.fetchData('users')
After (v3):
const data = await client.query('users', { format: 'json' })
The format parameter is now required.
Every breaking change must have its own before/after section. Link the migration guide from both CHANGELOG.md and the docs navigation. A changelog that names a removed API without showing the replacement fails this check.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Developer Documentation Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.analysability
Taxons
History
- 2026-04-18·v1.0.0·Initial import from developer-documentation·automated