From a Ticket Logger to a >90% Upgradeable Federal Service Backbone

The situation

When ExeQut joined the program, ServiceNow was already installed and ITSM was in use, but mainly as a place to record tickets. The service desk had no shaped identity. There was no operating model behind it, no defined picture of how it was supposed to work in steady state, no service catalog vision, no roadmap, and no plan for the rest of the modules the license entitled the agency to.

In other words, the technology was on the floor; the program was not. ServiceNow was logging work, not running it.

Meanwhile, the agency had real operational weight to carry. ITSM needed to live alongside change, release, and asset workflows. Project governance had to plug into demand intake. Mission-specific work, including legal service delivery and operational tracking obligations unique to the agency, had to share a backbone with everyday HR and procurement requests. And all of it had to feed, eventually, into a tighter cybersecurity and Zero Trust posture.

The honest read of the starting point: a capable platform underutilized as a ticket queue, with no shared spine and no story for how it would grow into one.

The challenge

Several problems had to be solved in parallel rather than in sequence:

1. A ticket logger, not an enterprise service. ITSM was in use, but only to record tickets. The service desk had no shaped identity, no operating model, no service catalog vision, and no path from ticketing to enterprise service management.
2. Governance gaps across the IT lifecycle. ITSM, change management, release management, and asset and configuration management needed to be designed and stood up, then connected by the parts that immature implementations tend to skip: demand intake, prioritization, and release governance.
3. Mission-specific workflows that did not fit a vanilla template. A custom weapons tracking solution, a custom HR request tracker, and Legal Service Delivery all needed first-class support, not workarounds.
4. Security operations data scattered across the estate. CyberArk, Forescout, SCCM, and vulnerability management tooling were producing valuable signal in places where ITSM and change records could not see it.
5. Upgradeability debt waiting to happen. Without disciplined platform stewardship, the customizations needed to support the mission would quietly turn into a wall between the agency and every future ServiceNow release, and by extension, the Zero Trust roadmap that depended on them.

The approach

The operating model

The first call was structural. We stood up an Agile delivery cadence backed by a clear ideas-to-demands-to-projects governance flow, with a Change Control Board owning the gates between intake, build, and release. That sounds like ITIL boilerplate; in practice it was the part of the engagement that did the most work. It gave the federal program owners a single front door for any new request, gave platform engineers a way to push back on customizations that would not survive an upgrade, and gave the vendor management side a way to see what was actually in flight.

Consolidation is a governance problem before it is a technical one. The demand-to-project plumbing matters more than the module selection.

Configuration over code, backed by training

A ServiceNow platform stays upgradeable to the degree its owners are willing to adapt to the vendor's patterns. That part of the work was as much organizational as it was technical. The agency's OIT team and leadership invested in ServiceNow training, then they actually used it: where the platform's best-practice processes did not match the agency's existing way of working, the default call we made together was to update the agency's internal processes rather than rush to reshape the platform.

The working rule was configuration first. Custom code was treated as a legitimate but last-resort tool, used only when a requirement genuinely could not be expressed any other way. The instinct was always to learn the platform before bending it. When custom development was the right answer, it was written, reviewed, and maintained against the same vendor patterns as everything else, packaged into deployment sets, and promoted through the three-tenant pipeline so no change reached production without passing the same review gates the configuration changes did.

That discipline is, in retrospect, the entire reason the platform later scored above 90% on upgradeability. A score like that is not something you clean your way into. It is something you earn by not creating the debt in the first place.

The most upgradeable platform is the one whose owners are willing to adapt their processes to the vendor's patterns, not the other way around.

The scope call: how far to take ServiceNow

ServiceNow was always going to be the one system. The real call was how much of the agency's operational surface area to actually run on it. The answer became, over time, as much as the use cases could credibly support. ITSM, Change Management, Release Management, Demand Management, Project Management, HR workflows, Legal Service Delivery, and asset and configuration management were all brought onto the same platform, alongside the custom weapons tracker and the custom HR request tracker. The operating principle was simple: workflows that had to talk to each other should not have to integrate to do it.

That direction is what made the upgradeability number meaningful. A platform carrying that many modules, governed under a coherent configuration discipline, is a different and harder thing to keep current than a handful of point tools with their own integration patterns. Doing it on one platform is what turned the score from a clean instance into a clean enterprise.

The security operations integration layer

ITOM and security operations were treated as the same problem. ServiceNow was wired into CyberArk for privileged access signal, Forescout for endpoint visibility, SCCM and System Center for configuration and patch state, and the agency's vulnerability management tooling for exposure data. The integration target was not a dashboard; it was the change record. When a vulnerability moved, the change calendar saw it. When an endpoint disappeared from Forescout, an asset record knew about it.

A platform that integrates with CyberArk, Forescout, and SCCM stops being an IT tool. It becomes a control point in the agency's Zero Trust posture.

Deployment, release, and upgradeability governance

The release approach was the mechanical expression of the same discipline. Configuration changes were packaged into deployment sets and promoted through the three-tenant pipeline, so each change passed the same review gates before reaching production. CI/CD coordination kept that pipeline moving without sacrificing those gates. Release governance was tied back to the Change Control Board, so the same body that approved a build also owned its operational risk.

The result: "can we upgrade?" stopped being a project and became a property of the platform.

The outcome

By the time the engagement closed out, the agency was operating on a platform that ServiceNow itself assessed at a greater than 90% upgradeability score. Helpdesk, PMO, HR, and procurement were all running on that single platform. ITSM, change, release, demand, project, and asset and configuration management were operating against shared governance. Legal Service Delivery, the custom weapons tracker, and the HR request tracker were live and supporting their respective mission and operational owners. The ITOM and security operations integrations were in place and feeding the change and asset records they were meant to inform.

In other words: the platform was not just stood up, it was stood up in a state a successor team can build forward from rather than rebuild around. That is the part that does not show up in a status slide, and the part that matters most when an engagement closes.

Upgradeability is the quietest measure of a platform's health. The loudest is whether the people it was bought for are actually running their work on it. A 90%+ score earned against an enterprise workload is health. The same score on a platform nobody uses is shelfware.

What we took from it

A few generalizable lessons, useful whether you are running a federal program office or an ITSM practice in a regulated enterprise:

1. Treat upgradeability as a leading indicator, and weight it by adoption. A platform that cannot move with its vendor puts every modernization roadmap (Zero Trust, identity, automation) on borrowed time. A platform that scores high because nobody is using it is shelfware, not health. The number worth chasing is upgradeability earned against real, enterprise-wide workload.
2. Configuration first; code only when there is no real alternative, and only under managed best practice. The instinct should be to learn ServiceNow's best-practice processes and adapt to them, not to rush in and customize the platform to old habits. Custom code is a legitimate tool when a requirement genuinely cannot be configured, but it has to be written, maintained, and deployed under the same governance, deployment sets, and pipeline as everything else. Training the people who own the platform is what keeps that discipline honest past the first sprint.
3. Consolidate workflows, including the mission-specific ones, before you consolidate tools. The win is shared demand intake, shared change governance, and shared asset truth, with specialized trackers and service delivery modules living next to ITSM rather than off in a separate corner of the estate.
4. Design security operations integrations into the platform, not onto it. The point of integrating CyberArk, Forescout, SCCM, and vulnerability management is not visibility for its own sake. It is making the change record the place where security and operations agree on reality.
5. Close engagements the way you would want to inherit one. A handoff with strong upgradeability, clean governance, and a documented integration map is what separates a platform a successor team can build on from one they have to walk back.