KM-201a · Module 1

The Taxonomy Lifecycle: Extend, Refactor, or Start Over

4 min read

No taxonomy is permanent. Organizations change: they add business lines, they reorganize, they acquire companies with different knowledge structures, they discover that the categories they designed two years ago do not reflect how the business actually works now. A taxonomy that cannot evolve will either be abandoned or will decay into inconsistency as contributors work around a structure that no longer fits their work.

The taxonomy lifecycle has three phases: extension, refactoring, and replacement. Extension is the addition of new categories or tags within the existing structure without changing the fundamental organization. This is the routine operation — adding a new product category, creating a subcategory for a new team, adding a facet tag. Extension should be a low-friction process with clear ownership but not requiring committee approval.

Refactoring is the reorganization of existing categories: merging categories that have become redundant, splitting categories that have grown too large, moving categories to different locations in the hierarchy. Refactoring requires migration work — every document in a renamed or moved category needs its taxonomy updated — and it requires communication, because users will have developed navigation patterns based on the old structure.

Replacement — starting over — is appropriate when the taxonomy has fundamental structural problems that cannot be fixed incrementally. The classic trigger is a taxonomy designed around the org chart that is now failing because the organization has reorganized twice and the knowledge structure no longer matches anything. Replacement is expensive: it requires migrating and reclassifying a large corpus, retraining users, and updating any integrations that depend on the taxonomy structure. It is almost always better to refactor incrementally than to start over, unless the fundamental design principle was wrong and incremental fixes are just delaying an inevitable collapse.

The decision framework is straightforward. If you need to add a new area that the current structure can accommodate, extend. If you have categories that no longer make sense or are the wrong size, refactor. If you find yourself adding workarounds and exceptions to avoid the structural problem, and those workarounds now exceed the base cases, replace.

Do This

  • Establish a formal taxonomy review process on a fixed cadence (annually at minimum)
  • Track taxonomy health metrics: categories with no documents, categories with 200+ documents, documents with no category
  • Make extension low-friction and refactoring deliberate — distinguish the two clearly in governance
  • Document the rationale for taxonomy decisions so future changes can be made with full context

Avoid This

  • Allow ad-hoc category creation without a naming convention — you'll have 40 near-identical categories within a year
  • Wait until the taxonomy is visibly broken before addressing structural problems
  • Refactor without migrating existing documents — orphaned content is worse than wrong categorization
  • Replace the taxonomy because it needs updating — refactoring is almost always the right answer
  1. Annual Taxonomy Audit Once per year: pull a report of all categories, document counts per category, and documents with no category. Flag categories under 3 documents (candidates for merging) and over 100 documents (candidates for splitting). Review top-level structure against current organizational priorities. Make a formal decision: extend, refactor, or flag for replacement planning.
  2. Refactoring Protocol When refactoring: document the before state, document the rationale for the change, execute the migration (rename/move categories and update all affected documents), communicate the change to contributors with a redirect map, and update any external integrations that reference category names or paths.
  3. Replacement Trigger Criteria Initiate a replacement project when: (1) more than 30% of documents require workaround categorization to fit the existing structure, (2) the taxonomy requires organizational context to navigate that new employees don't have, or (3) the structure cannot accommodate a major organizational change without breaking the navigation model entirely.