A Drupal upgrade is mostly not about changing the core version number

Situation

In a large, older Drupal system, it is easy to describe an upgrade as the task of reaching a higher core version. In practice, every custom module, contrib package, Composer constraint, PHP version and external integration participates in the decision. In March there were several cases where core itself could move forward while the surrounding environment was not ready yet.

Approach

Instead of forcing one large update through the system, I built a compatibility map. True blocking dependencies were separated from deprecations that were warnings rather than immediate blockers, and custom code touching changed APIs was identified explicitly. I did not treat Composer's solver result as the final answer either; the resolved dependency graph still had to make sense at runtime.

Outcome

The upgrade broke down into smaller, verifiable steps. Compatibility blockers were removed first, deprecations followed, and only then did the core transition become appropriate. That looked slower than one large update command, but it produced far fewer rollbacks and production-adjacent surprises.