"Wait," you might say. "Why should we mess with things that are working just fine?"

Because no connected system operates in isolation, and most people are only in control of a subset of the infrastructure, not all of it. There's an illustration we use to drive this point home.

Imagine, if you will, all the different pieces of your analytics infrastructure as pegs on a pegboard. Every individual aspect of your infrastructure — Tableau Server, the Tableau Support contract, the hardware it's running on, Tableau Desktop, database drivers, the data warehouse itself, authentication configuration (I'm looking at you, Snowflake) — these are the individual rows of holes on the pegboard.

The versions of those components are the columns—and versions tend to increase over time, so you can also imagine the columns as "when was this version released." Some components iterate slowly (like Tableau Server's supported version) and some iterate quickly (like Tableau Server itself), which shows up as peg holes being closer together on some rows and farther apart on others.

The pegs themselves are placed in the holes for which versions are relevant for each component. Remember, you probably only control some of these pegs.

Now, imagine rubber bands looping around the pegs that need to work together.

If the versions of the components are compatible, those pegs are closer together, and the rubber band can fit around all the pegs without snapping. It might be totally slack, with room to give as things change. Or it might have a little bit of tension, but nothing the rubber band couldn't handle. As long as the tension in the rubber band isn't too much to handle, everything works.

But when one of those pegs drifts too far — especially the ones that aren't in your control — the rubber band stretches and, eventually, snaps. And if you've ever been hit by a rubber band when it snaps… it doesn't feel good.

That is the situation organizations find themselves in when deferred maintenance finally catches up: a down server, no vendor support, and a team scrambling to reconstruct years of configuration decisions from memory.

Not all updates are created equal. Two factors determine how much work any given update actually requires:

Scope describes the types of things that change from your current version to the target version.

• A patch release typically carries only bug fixes — small changes, narrow impact.
• A minor release introduces new features, and may require a bit more: it may contain several bug fixes you need to communicate to your stakeholders, but it also contains new functionality to assess and potentially implement. Users love new features!
• A major release with backwards-incompatible changes may require an adjustment to your infrastructure's architecture, or configuration reviews — and as a result, it probably requires more planning and preparation than the other two scopes.

Size describes how many of those changes accumulate before you act.

• If you update monthly, a given release might carry a few bug fixes and one small feature.
• If you update yearly, you're handling 12 months of patches, features, potential regressions, and breaking changes.

Together, scope and size reflect the amount of work required to perform the maintenance, as well as the potential amount of risk that work carries. A sustainable maintenance strategy keeps both as small as possible.

When you defer updates long enough, something beyond technical debt accumulates: organizational debt. The team member who understood the original configuration moves on. Documentation grows stale. And when something eventually breaks — because something always eventually breaks — no one knows where to start.

Consider the practical math. A customer running a 2021 version of Tableau Server who needed to reach a current 2025 release was technically dealing with one upgrade. But that upgrade contained four years of accumulated changes:

• dozens of individual patch releases rolled into one,
• over 200 new or updated features,
• more than 20 features deprecated,
• all in all, roughly 315 items to consider (excluding bug fixes).

That is a fundamentally different undertaking than a routine maintenance window.

The organizations that handle Tableau Server best are not necessarily the ones with the most sophisticated environments.

They have a maintenance schedule. They stick to it. And if something goes wrong, it doesn't take a ton of effort to remediate, because the size and scope of the maintenance was appropriately constrained.