IT Infrastructure

How to Build an IT Service Catalog That Survives Reorgs

How to Build an IT Service Catalog That Survives Reorgs

Every reorg claims a casualty nobody budgeted for: the service catalog. A perfectly usable IT service catalog gets built during a platform push, gets maintained diligently for a quarter or two, and then a team splits, merges, or gets renamed — and half its entries now point to Slack channels, managers, and teams that no longer exist. Two reorgs later, most of it is fiction that nobody trusts enough to use for incident routing, onboarding, or a compliance audit.

The catalog isn’t the problem. The design assumption underneath it is: a catalog built around today’s org chart is guaranteed to be wrong the moment that chart changes, and in most engineering organizations that happens sooner than anyone plans for. Gart’s platform engineering services team builds catalogs and the developer portals around them specifically to decouple from team structure, so they don’t need rebuilding after every reorganization. This guide walks through why catalogs break, the design principle that fixes it, and the governance habits that keep it fixed.

What Is an IT Service Catalog (and Why Reorgs Keep Breaking It)

An IT service catalog is the single, authoritative list of every live IT and business service an organization runs, along with each one’s ownership, status, and how it’s requested or supported. Per the official ITIL 4 Service Catalogue Management practice guide, a well-run catalog maintains two linked views: a business-facing catalog written in plain language for the people requesting a service, and a technical catalog mapping each one to the underlying components, dependencies, and infrastructure that deliver it.

Neither view mentions a team name in the ITIL definition — and that’s exactly where most real-world catalogs go wrong. In practice, teams build the ownership field as “Team Nebula owns this,” not “the payments-integration function owns this.” Team Nebula is a fine label right up until the reorg that splits it into two teams, merges it into another, or renames it entirely. The service didn’t change. The org chart did. And because the catalog encoded the org chart instead of the service boundary, the entry is now wrong.

Why Service Catalogs Collapse During Reorgs

Reorgs aren’t a rare disruption you can design around once and forget — they’re a recurring input the catalog has to withstand on a schedule you don’t control. That schedule has gotten noticeably tighter in recent years:

The pace of change is the real design constraint: Gartner research found the average employee absorbed 10 planned enterprise changes in 2022 — restructures, operating-model shifts, tooling replacements — up from just 2 in 2016, and only 32% of business leaders report their organizations are actually managing change adoption well. A service catalog built to survive one reorg per year is being designed for a pace of change that no longer exists.

When a reorg lands on a catalog that encodes team names instead of service boundaries, the damage shows up in predictable places. A handful of signs reliably mean a catalog has already broken and nobody has noticed yet:

  • Support tickets for a service keep landing on a team’s queue months after that team stopped owning it.
  • Nobody can say, without asking around, who currently owns a service’s on-call rotation.
  • The catalog’s “owner” field still lists a manager who left the company or moved teams last quarter.
  • A new hire’s onboarding checklist points to a Slack channel that was archived in the last restructuring.
  • The last full catalog review happened before the org chart it describes was last redrawn.

The Core Design Principle: Decouple Ownership From the Org Chart

The fix isn’t a better spreadsheet or a stricter update policy — it’s a different data model. A reorg-resilient catalog separates two things that a team-name field collapses into one: the service boundary (durable, rarely changes) and the current owning function (a pointer that gets reassigned whenever the org chart moves, without touching the service’s identity at all). This is the same separation of concerns behind Team Topologies-style organization design — teams are the changeable implementation detail, and the service or capability is the stable unit the business actually cares about.

Mature developer-portal implementations solve this with an annotation pattern: a service entity carries a fixed identity and a set of pointers — current owner, on-call channel, escalation contact — that live as metadata attached to, but separate from, the entity itself. According to lessons from building developer portals for more than 100,000 engineers, these annotations are deliberately kept swappable so that reassigning ownership after a reorg is a metadata update, not a rewrite of the catalog entry itself. You don’t need a full internal developer platform to borrow the pattern — the same separation works in a spreadsheet, a wiki table, or an ITSM tool, as long as “what the service is” and “who currently owns it” are two distinct, independently updatable fields.

What a Reorg-Resilient Catalog Entry Actually Contains

Every field below has to answer one test: does this survive a reorg, or does it need to be rewritten the moment the org chart changes? Fields that fail the test get replaced with a pointer instead of a static value.

FieldWhy It’s Reorg-ResilientWho Keeps It Current
Durable service IDAssigned once, never renamed to match a team — survives every restructure by designCatalog steward (see governance below)
Business capability / domainDescribes what the service does for the business, not which team built it — capabilities rarely disappear even when teams doService catalog steward, set at creation
Current owning function (pointer)A reassignable pointer to a role or function, not a person or team name — updated independently of the entry itselfWhoever inherits the function after a reorg, within an agreed SLA
On-call / escalation channelPoints to a rotation or alias, not a named individual or a channel tied to one team’s naming conventionCurrent owning function
SLA / criticality tierDescribes the service’s business importance, which doesn’t change just because its owning team doesService catalog steward, reviewed annually
Last-verified dateMakes staleness visible instead of silent — the single field that turns “probably fine” into a measurable factCurrent owning function, on a recurring cadence
What a Reorg-Resilient Catalog Entry Actually Contains
Same reorg, same service — only the ownership model changes the outcome

A Step-by-Step Process for Building One

None of this requires a big-bang platform rollout. The sequence below produces a working, reorg-resilient catalog in a few weeks, starting from whatever fragmented inventory already exists:

  1. Inventory what actually runs today, not what should exist on paper. Pull from CI/CD pipelines, cloud billing, DNS records, and monitoring dashboards rather than asking teams to self-report — self-reported lists miss retired services still consuming budget and forget new ones nobody wrote down. A full infrastructure audit is usually the fastest way to establish this baseline in one pass.
  2. Assign a durable service ID before anything else. This ID never changes, even if the service is renamed, re-platformed, or handed to a different function. It’s the one field every other field hangs off of.
  3. Map ownership to a business capability or function, never a team name. “Payments Platform” or “Customer Identity” survives reorgs; “Team Nebula” or “Sarah’s squad” does not.
  4. Add a reassignable owner pointer, kept separate from the service definition. This is the field that changes after a reorg — nothing else in the entry should need to.
  5. Publish it somewhere genuinely discoverable. A spreadsheet on a shared drive is where catalogs go to die quietly. A developer portal, wiki with structured metadata, or ITSM catalog module all beat a spreadsheet because they’re the tool people already open, not one more place to remember to check.
  6. Put a recurring ownership-verification cadence on the calendar, tied explicitly to the reorg cycle. Every reorg announcement should trigger a catalog review as a standing step, not an afterthought someone remembers three months later.

Governance: Keeping It Alive After the Next Reorg

A catalog built well on day one still decays without ownership of the catalog itself, separate from ownership of the services inside it. Three habits do most of the work:

Name a catalog steward who isn’t tied to any one team. This role — often a platform engineering or IT operations function — owns the catalog’s structure and health, not any individual service. Because the role sits outside any single team’s reporting line, it survives reorgs that would otherwise leave the catalog itself ownerless.

Make catalog review a mandatory line item in every reorg checklist, not a follow-up task. The single highest-leverage governance change most organizations can make is moving “update the service catalog” from “eventually, if someone remembers” to a required step alongside updating org charts and access permissions.

Track staleness as a metric, not a feeling. The same discipline that catches drift in an access review left running on autopilot applies here: an unowned or unverified service entry is a standing liability that nobody notices until an incident forces the question. Report the percentage of entries verified in the last quarter and the count with a blank or clearly stale owner field — both are simple enough to put on a monthly dashboard, and both make catalog decay visible before it causes an outage.

Tooling Options, Compared

The right tool depends far more on team size and existing stack than on any feature checklist. All three approaches below can implement the durable-ID-plus-owner-pointer model — the difference is how much automation and discoverability comes built in.

ApproachBest FitTrade-off
Developer portal (Backstage-style)Engineering orgs with 50+ services and a dedicated platform teamRequires ongoing platform investment to configure and maintain, but automates discovery and keeps ownership annotations current with the least manual effort
Enterprise ITSM suite catalog moduleLarger organizations already running ServiceNow, Jira Service Management, or similar for their broader ITSM and monitoring stackStrong workflow and SLA enforcement, but heavier to configure and slower to stand up than a lightweight option
Structured wiki or lightweight metadata tableSmall or lean IT teams without spare platform capacityFastest to start and cheapest to run, but requires real manual discipline — no automated discovery or drift detection

Whichever tier you pick, the ownership model matters more than the platform. Backstage — the open-source developer portal framework donated to the Cloud Native Computing Foundation — now has more than 3,000 public adopters, which says less about any one tool being mandatory and more about how many engineering organizations have independently converged on “durable service catalog with reassignable ownership” as the right shape for this problem. Teams already running AIOps-driven ITSM integrations often find the catalog becomes the missing link that makes automated incident routing and dependency mapping actually reliable, since both depend on knowing who currently owns what.

Common Mistakes

A small set of design choices accounts for most service catalogs that quietly stop being trusted:

  • Encoding the org chart directly into the catalog. Team names, manager names, and team-specific Slack channels are exactly the fields a reorg invalidates first — they should never be the primary ownership field.
  • Treating the catalog as a one-time project instead of the operational layer it actually is. A catalog built once and left alone is a snapshot of a moment in time, not a system of record.
  • No single owner for the catalog itself. Every service can have a clear owner and the catalog can still decay if nobody owns the catalog’s structure, completeness, and staleness metrics.
  • Skipping the “last verified” field. Without it, a stale entry looks identical to a current one — staleness has to be visible to be fixable.
  • Building it in a tool nobody already opens. A catalog that lives in a spreadsheet on a shared drive gets checked once at launch and never again; discoverability inside an existing workflow is what keeps it alive.

Rebuilding your service catalog after every reorg gets expensive.

Gart Solutions designs service catalogs and the developer portals around them so ownership survives organizational change — durable service IDs, function-based ownership, and the governance habits that keep the whole thing trustworthy a year later, not just at launch.

10+ Years in DevOps & Cloud
50+ Enterprise clients served
4.9★ Clutch rating
Platform Engineering IT Infrastructure Consulting Infrastructure Audit DevOps Consulting SRE Services
Talk to a Platform Engineering Expert →[cite: 6]

You might also like

Fedir Kompaniiets

Fedir Kompaniiets

Co-founder & CEO, Gart Solutions · Cloud Architect & DevOps Consultant

Fedir is a technology enthusiast with over a decade of diverse industry experience. He co-founded Gart Solutions to address complex tech challenges related to Digital Transformation, helping businesses focus on what matters most — scaling. Fedir is committed to driving sustainable IT transformation, helping SMBs innovate, plan future growth, and navigate the “tech madness” through expert DevOps and Cloud managed services. Connect on LinkedIn.

FAQ

What is an IT service catalog?

An IT service catalog is the authoritative list of every live IT and business service an organization runs, including each one's status, ownership, and how it's requested or supported. Per ITIL 4, it maintains a business-facing view for people requesting services and a technical view mapping each one to its underlying infrastructure and dependencies.

Why do service catalogs break during reorgs?

Most catalogs encode ownership as a team name, manager name, or team-specific channel. When a reorg splits, merges, or renames that team, every entry pointing to it becomes wrong at once. A reorg-resilient catalog separates the durable service definition from a reassignable owner pointer, so a reorg only requires updating the pointer, not rewriting the entry.

Who should own a service catalog after a reorganization?

The catalog itself should have a steward role — typically sitting in platform engineering or IT operations — that isn't tied to any single team's reporting line, so it survives the same reorgs that reshuffle the services inside the catalog. Individual service ownership is then a separate, reassignable pointer maintained by whichever function inherits that service.

How do you keep a service catalog updated after a reorg?

Make catalog review a mandatory line item in every reorg checklist rather than a follow-up task, and track a staleness metric — the percentage of entries verified within a set window and the count with a blank or outdated owner field — on a recurring dashboard so decay is visible before it causes an incident.

What is the difference between a service catalog and a CMDB?

A service catalog lists live, requestable services with their ownership, SLAs, and support channels — it's the customer- and requester-facing layer. A CMDB (Configuration Management Database) tracks the underlying configuration items, such as servers, applications, and their dependencies, that deliver those services. The two are linked but distinct: the catalog answers "what can I request and who owns it," while the CMDB answers "what components make this service actually run."

When should you rebuild a service catalog instead of updating an existing one?

Rebuild when the catalog's ownership model is fundamentally tied to team names or individuals rather than durable service IDs and reassignable functions — patching individual entries won't fix a structural design flaw. If the underlying data model already separates service identity from current ownership, a reorg only requires a targeted update, not a rebuild.

How often should a service catalog be reviewed?

At minimum, quarterly, plus a triggered review after every organizational reorganization rather than waiting for the next scheduled cycle. Gartner research found the average employee experienced 10 planned enterprise changes in a single year, so a catalog reviewed only annually is being maintained on a far slower cycle than the org chart it's supposed to reflect.

Where does service catalog ownership most commonly break down first?

On-call and escalation fields tend to break first, since they're often hard-coded to a team-specific channel or rotation name rather than a reassignable alias. Support ticket routing breaks next, as tickets keep landing on a queue for a team that no longer owns the service.
arrow arrow

Thank you
for contacting us!

Please, check your email

arrow arrow

Thank you

You've been subscribed

We use cookies to enhance your browsing experience. By clicking "Accept," you consent to the use of cookies. To learn more, read our Privacy Policy