.webp)
Service management
Service Management That Outlives the Tooling
Service mapping, a CMDB that sticks, and incident response built to survive the Opsgenie sunset.
01
The challenge
When your service management platform has an end date, every process built on it does too. A multi-region logistics and fulfillment operator saw that coming and chose not to rebuild on borrowed time — so we stood up service management in Jira Service Management: a service-first CMDB, ITIL-aligned incident and problem management, and on-call, on a platform with a future.
Every major incident opened with a scavenger hunt: who owns this, what depends on it, who do we have to tell. Two CMDB attempts had already died as spreadsheets — both were inventories, and neither answered a question anyone asked at 2am. Customer status went out late, by hand, and only when someone remembered — so customers sometimes found out from their own customers. The brief: a service model the business would recognize with a CMDB that survives its own launch, incident and problem management matured to an ITIL-aligned standard, and alerting, on-call and status communications on a footing that lasts.
02
Our approach
Service-first, never inventory-first. Atlassian's own guidance is to start a CMDB from services, not servers — we took it literally. Six discovery workshops put business and technical stakeholders in the same room and produced the services the company sells, the technical services IT runs, and the applications underneath both. Every service got a named owner and an escalation path before we modeled a single attribute — a configuration item with no owner is a rumour with a hostname. The schemas went into JSM Assets as service → application → infrastructure → vendor, with dependencies mapped in both directions and governance built in: CI lifecycle states, a quarterly ownership review, a change gate, and a data quality dashboard the service owners actually see.
One decision mattered more than the rest: the brief asked for an Opsgenie build-out. We showed the client the April 5, 2027 end-of-support date instead — new schedules and escalation policies there would only get built twice — and stood up alerting and on-call natively in JSM Operations. Same capability, one migration avoided, and a smaller invoice than the one they arrived ready to sign.
Migrate the practices, not the problems.
03
What we built
- Service catalogue & CMDB in AssetsBusiness and technical services with named owners and criticality tiers; object schemas and a two-way relationship model.
- CMDB governance packLifecycle states, a review cadence and a data quality dashboard, so the data stays honest after we hand over the keys.
- Major incident playbookA severity matrix keyed to service criticality, MIM roles, a bridge process, and a communications cadence that runs on a timer instead of on somebody's nerve.
- Incident & problem workflowsTriage, SLAs, escalation, structured RCA templates, and a known error register with a monthly review that reads the RCAs rather than filing them.
- Alerting & on-call in JSM OperationsSchedules, rotations, escalation policies and monitoring integrations, mapped to the same services as the CMDB.
- Statuspage, triggered not typedComponents mapped one-to-one to catalogued services, with external updates and internal notifications fired from the incident record itself.
04
The results
16 weeks · major incident management live at week 9 · measured at the 90-day re-measure, every number naming its method.
- 63% faster impact scopingMedian time from incident raised to declared impact scope fell from 38 minutes to 14 on major incidents. JSM native reporting.
- 94% of P1/P2 raised against a named serviceUp from a 22% baseline on the legacy free-text field.
- 100% of services with an owner and on-call pathAcross the whole catalogue — a delivery gate, not a happy accident.
- 7-minute median to customer statusFrom incident declared to published status update, down from 41 minutes across the prior quarter.
05
In their words
We'd tried to build a CMDB twice. Both times it turned into a spreadsheet nobody opened. The difference this time was starting from the services we argue about at two in the morning, instead of from a list of servers. — Director of Service Delivery
They talked us out of work they could have billed for. We were ready to buy an Opsgenie build-out; they showed us the end-of-support date and built it in JSM instead. That is the entire reason they are still our partner. — VP of Infrastructure
Quotations used with permission. Speaker roles retained; names, employer and region withheld at the client's request.
ITIL and CMDB in JSM
Build service management that lasts
If your ITSM platform is approaching its end date — Opsgenie's is April 5, 2027 — migrate the practices, not the problems. We'll map your top services in a two-week readiness review.