**A platform stays maintainable only if its stack keeps moving: I kept Canvas's framework and dependencies current for years as a steady background practice, so downstream squads inherited an up-to-date base without ever inheriting an upgrade emergency.** ## Outcome I kept Canvas's framework and dependencies current for years as a steady practice, so downstream squads inherited an up-to-date base without an upgrade emergency. ## Context This was a multi-year contract on Canvas, Pfizer's global enterprise content platform, where many squads depended on the same Laravel framework and dependency base. I drove the currency work with the platform and downstream squads whose releases depended on that base. ## Problem Canvas is Pfizer's global enterprise content platform that other product squads build on, and a shared platform's dependency stack decays quietly. Framework releases ship, security patches land, and libraries deprecate whether or not anyone acts. Left alone, that decay compounds into the worst kind of debt: a base too far behind to patch safely and too entangled to move quickly, on a codebase many teams depend on daily. The job was to keep the platform's framework and dependency stack current across the whole engagement, without turning that currency into breakage that stalled the squads shipping on top. ## Constraints - Downstream blast radius: many squads consumed the shared platform, so an upgrade that changed behavior underneath them was an outage for teams that did not ask for it. - Regulated environment: dependency changes moved through change control and had to be provably safe before cutover, with no unreviewed jumps. - Continuous delivery: product squads shipped throughout, so upgrades had to happen alongside feature work, never as a stop-the-world event. - Everything here is described under NDA, so specifics are anonymized and any figures are relative. ## Decisions and trade-offs **Incremental upgrades over the big-bang jump.** The tempting shape was to let versions accumulate and clear the backlog in one large campaign. Rejected: a big-bang upgrade bundles every breaking change into a single high-risk merge, is nearly impossible to review or roll back cleanly, and freezes downstream teams while it lands. I moved the stack forward in small, frequent, independently reviewable steps instead, each a change control could reason about and revert on its own evidence, so risk stayed bounded per step rather than pooled into one event. **Continuous currency over freeze-and-rot.** The other default was to freeze the stack for stability and defer upgrades indefinitely. Rejected as the more dangerous path: freezing feels safe and quietly accrues the exact debt that later forces an emergency rewrite under security pressure. I treated staying current as an ongoing practice, close enough to supported releases that each hop was small, which is what kept every individual upgrade cheap and boring. **Protecting the downstream contract over pure internal cleanliness.** An upgrade is only done when the teams on top do not feel it. Each step leaned on the platform's test gate to prove behavior downstream squads relied on was preserved, and breaking changes were absorbed behind stable internal seams rather than passed through. When a jump did touch consumers, it was staged and communicated, never sprung. ## Implementation I moved versions forward in small, independently reviewable and reversible changes, used the platform test gate with downstream squads to preserve behavior, and staged and communicated any consumer-facing change instead of passing breaking changes through. ## Results The platform's framework and dependency stack stayed current across the four-plus-year engagement instead of drifting toward a forced rewrite, and it stayed current as a steady background practice that did not interrupt the squads delivering on it. That is the consistency answer a buyer looks for: upgrades handled as routine, bounded, reversible steps rather than heroics, so the platform never accumulated the key-person-fragile, all-at-once migration that stalls product teams and signals a maintenance function that only works when one person is watching. ## Takeaways Currency is cheaper when it is continuous. Keep each upgrade bounded and reversible, and protect downstream contracts so maintenance work remains invisible to product teams.