Most organizations treat go-live as the finish line. The ribbon gets cut, the implementation partner high-fives the project team, everyone eats the go-live cake — and then the very things that made the project succeed quietly disappear. The A-team rolls off to the next engagement. The governance boards stop meeting. The budget evaporates. And the backlog of everything the business wanted but didn’t get in Phase 1 sits untouched. That’s the trap: the platform was launched, but nobody built the engine to keep it moving forward.
This is not a tooling problem. It’s an operating-model problem. A ServiceNow platform delivers most of its value after launch, compounding over years as you extend it, adopt it more deeply, and bend it to the business. When the post-launch operating model is missing, value doesn’t just plateau — it decays. Adoption stalls, technical debt creeps in, the instance drifts away from the baseline, and within a few years someone is pitching a costly re-platform to fix a platform that was never actually broken.
This paper names the four mechanisms that spring the trap, explains why regulated, multi-product carriers in Property & Casualty insurance feel it more acutely than most, and lays out a Day-2 operating model you can stand up before you ever execute the go-live cut over. The thesis is simple: stop treating go-live as a destination, and start treating it as the day the real work begins.
Can we be honest about go-live for a moment? It’s intoxicating. Months — sometimes even years — of effort culminate in a single cutover weekend, and when the new platform comes up clean on Monday morning, it feels like the end of something. We celebrate, and we should. But the celebration hides a dangerous assumption: that the hard part is over.
It isn’t. I’ve helped more than thirty organizations deploy or extend ServiceNow, and the pattern is remarkably consistent. The projects that struggle rarely struggle at launch. They struggle six, twelve, eighteen months later — when the momentum that carried them through Phase 1 has dissipated and nothing durable was put in its place. The platform is live, but the organization has no reliable way to feed it, govern it, or grow it. That’s the moment the trap closes.
The data backs up the intuition. In a widely cited survey on digital transformation, McKinsey found that only about 16 percent of organizations said their transformations had both improved performance and equipped them to sustain those gains over the long term; the large majority fall short, and one of the recurring culprits is that the disciplines driving the change end when the project does. The launch succeeds. The transformation doesn’t.
For P&C insurers, operating across multiple lines of business, under state-by-state regulatory scrutiny, and increasingly on a mix of out-of-the-box ServiceNow applications and custom workflows. The stakes are higher and the trap is easier to fall into. A stalled transformation in a regulated vertical isn’t just a missed opportunity; it’s compliance risk, audit exposure, and operational drag that compounds quarter over quarter. Let me walk through how the trap actually springs, and then how to stay out of it.
The trap isn’t a single failure. It’s four reinforcing ones. Each is survivable on its own. Together, they’re how a successful launch becomes a stalled program.
On launch day, your platform is supported by the most knowledgeable group of people it will ever have — implementation partners who designed it and internal staff who lived through the build. Then the partner’s statement of work ends, the consultants fly home, and that knowledge walks out the door. If the organization hasn’t built its own muscle to replace it, capability falls off a cliff.
I’ve watched this play out in the worst possible way: a customer who didn’t invest in training their own people on ServiceNow, and also didn’t cover that gap with a managed-service contract. So at the exact moment the experts left, there was no one, internal or external, who actually understood the platform they now owned. That’s not a slow leak. That’s a recipe for disaster. Within months, simple enhancements were stalling, defects were piling up, and confidence in the platform was eroding for reasons that had nothing to do with the technology and everything to do with people.
Capability is a choice you make before go-live, not a problem you discover after. You either grow it internally, rent it through a managed service, or — ideally — blend the two. What you cannot do is assume it will materialize on its own.
During a Phase 1, decisions get made fast because everyone is in the room. After go-live, that room empties and if you haven’t formalized how decisions get made, you’re left winging it. This is the failure I see most often, because right-sized platform governance is genuinely hard to sell to customers. Standing up the three boards I always advocate for are a Demand board to triage what gets built, a Technical Review board to protect architectural integrity, and an Executive Steering board to align platform investment with business strategy feels like bureaucracy to an organization that just wants to move fast and start delivering value. So they skip it, and they wing it instead. That’s never good.
Here’s what winging it looks like in practice. On one program, the customer brought in a new platform owner right as we approached go-live, someone who simply would not listen to advice about the proper rigor around the DEV/TEST/UAT/PROD promotion process. When a defect appeared in production, his instinct was to be hyper-reactionary: just fix it directly in PROD. Fast, satisfying, done. Except every one of those direct edits quietly pushed the instance stack out of sync. The lower environments no longer matched production. So when the next batch of perfectly normal backlog work got promoted up the stack, it failed in ways nobody could predict because the foundation it was being deployed onto was no longer the foundation anyone had tested against. He set himself up for failure, one heroic hot-fix at a time. Proper governance and process rigor aren’t bureaucracy. They’re what make the platform predictable.
Every Phase 1 ships with a wish list. The business wanted ten things; you delivered the seven that mattered most, and the other three became ‘Phase 2.’ On go-live day, that wish list, plus the inevitable defects your users will surface, is your initial backlog. It is the single best signal of whether your transformation will keep delivering value.
And in a stalled program, it’s where good ideas go to die. With no intake process, no prioritization mechanism, and no team with the capacity to work it, the backlog stops being a roadmap and becomes a graveyard. The business learns, quickly, that asking for things is pointless. Adoption suffers — not because the platform can’t do the work, but because no one believes it ever will. Gartner has reported that a large share of software features go essentially unused after deployment; a neglected backlog is one of the quiet reasons why.
The final mechanism is the slowest and the most expensive. Without a Technical Review board enforcing an out-of-the-box-first discipline, every post-launch request gets solved the fastest way someone can think of, usually a customization. Each one seems reasonable in isolation. Collectively, they pull you further and further from the baseline, until you’ve customized yourself into a corner and every ServiceNow upgrade becomes a project of its own.
This is technical debt, and it is not free. McKinsey has estimated that technical debt can amount to roughly 40 percent of an organization’s IT balance sheet, and that companies pay a substantial ‘tax’ on the order of 10 to 20 percent on top of project costs to service it. On a ServiceNow platform, that tax shows up as brittle upgrades, regression risk, and the slow realization that you can no longer take advantage of the next innovation ServiceNow ships, because your instance is too far from baseline to absorb it. The whole point of buying a platform is to let the vendor innovate on your behalf. Tech debt creep quietly takes that away.
Everything above applies to any ServiceNow transformation. But Property & Casualty insurance concentrates the risk. Carriers rarely run a single, tidy process; they operate across personal and commercial lines, each with its own servicing, renewal, onboarding, and claims nuances. That breadth means more workflows, more integrations, and more surface area for debt and drift to accumulate after launch.
Layer on the regulatory reality. P&C carriers operate under state-by-state oversight, audit requirements, and tight expectations around documentation and traceability. A governance vacuum in this environment isn’t just an efficiency problem, it’s the conditions under which an undocumented production change becomes an audit finding. The PROD hot-fix story from Section 2.2 is an annoyance in most industries; in a regulated carrier, it’s a control failure.
This lack of governance and architectural rigor is precisely where carriers either escape the trap or fall deeper into it. ServiceNow’s Financial Services Operations (FSO) gives carriers a strong out-of-the-box starting point with P&C servicing and claims processes, and an insurance data model built for the industry. The mistake is treating that baseline as raw clay to be reshaped by making direct changes to business rules, flows, and script includes; the discipline is extending it through scoped applications that encapsulate new capability without ever touching the core baseline. When Naitiv builds something like Personal Lines Customer Onboarding, a Bordereaux Workbench, or a Policy Renewal Workbench, it ships as a scoped application layered cleanly on top of FSO, adding the workflow the carrier needs while keeping the platform fully upgradeable. Knowing how to extend the data model and the platform this way is what lets a carrier add value for years without ever customizing itself into a corner.
If go-live is the starting line, the Day-2 operating model is the engine. Here’s the practical part on what to put in place, ideally before you cut over, so the platform compounds value instead of decaying.
The single highest-leverage move is to design your post-launch operating model as a deliverable of the project itself, not as an afterthought once the team has scattered. Who owns the platform? How does work get requested, triaged, and prioritized? What’s the support model the day the partner leaves? If you can’t answer those questions a month before go-live, you are walking into the trap with your eyes open. Make the operating model a gated deliverable, reviewed and funded alongside the technical build.
Governance is the durable replacement for the all-hands energy of Phase 1. Right-size it to your footprint, a small carrier does not need the same machinery as a large enterprise, but do not skip it. A Demand board decides what’s worth building and protects the team from the tail wagging the dog. A Technical Review board protects architectural integrity and enforces the OOB-first discipline that keeps you upgradeable. An Executive Steering board keeps platform investment tied to business strategy and, critically, keeps the funding flowing. These boards are how you avoid winging it. Stand them up before launch and let them practice while the stakes are still low.
Once you’re live, your delivery rhythm changes. A predictable cadence — I’ve long favored a two-week cycle with batched update sets promoted up the stack together, rather than each developer promoting individually and clobbering each other’s work, keeps the instance stack in sync and changes predictable. And it makes the PROD hot-fix temptation unnecessary, because there’s always a near-term, disciplined path to production. The lesson from the platform owner who fixed defects directly in PROD is not ‘he was reckless.’ It’s that the absence of a trusted, fast promotion process is what made recklessness feel like the only option. Give people a disciplined path and most will take it.
Foundation data first. A platform sitting on incomplete or inaccurate foundational data will disappoint no matter how elegant the workflows on top of it are. Treat data quality as an ongoing operating responsibility, not a migration task you closed out at go-live. And pair it with a standing configuration-versus-customization discipline: every request gets evaluated against the baseline before anyone writes code. The willingness to say ‘No but here’s an out-of-the-box alternative’ is one of the most valuable habits a platform team can build.
Finally, change what you measure. ‘We went live on time’ is a project metric. It tells you nothing about whether the platform is delivering. Track adoption, backlog throughput, time-to-value on new requests, and the ratio of configuration to customization over time. These are the vital signs of a healthy post-launch platform, and watching them is how you catch the trap springing before it fully closes — while you can still do something about it.
The go-live trap is so common precisely because it’s disguised as success. Nobody sets out to under-fund governance or let capability walk out the door; it happens by default, because we mistake the launch for the destination. But a platform is not a project. It’s a long-lived capability that should be worth more to your organization in year five than it was in year one and that only happens if you build the engine to keep it moving.
So before your next cutover, ask the uncomfortable question: what happens the Monday after the cake is gone? If you have a clear, funded, governed answer — an operating model, three boards that actually meet, a delivery cadence, a tended backlog, and a healthy respect for the baseline, you’re not walking into the trap. You’re building for the decade, not the demo. That’s the difference between going live and staying alive.
[1] McKinsey & Company. “Unlocking success in digital transformations.” October 2018. mckinsey.com
[2] McKinsey & Company. “Tech debt: Reclaiming tech equity.” October 2020. mckinsey.com
[3] Gartner. Research on enterprise software feature utilization, 2024 (as reported in secondary coverage). Figures on unused software features should be treated as directional. gartner.com
[4] Pearson, C. “Right Sizing ServiceNow Governance.” ServiceNow Community, Developer Blog, February 2025.
[5] Pearson, C. “How do I get my code up there?” and “Agile Scrum – The Cool Kid on the Block.” ServiceNow Community, 2020 (steady-state delivery and promotion cadence).
.svg){kind=icon}
