Everyone sells the cutover. The industry quietly admits the truth: projects stumble after go-live, when editors start touching a live network and bad edits silently corrupt connectivity. That's not a migration problem — it's a forever problem. And it's the strongest AI argument for a durable business: always-on agents that validate the network continuously, catching bad edits before they break it.
The whole industry is organized around a single moment: the cutover. The proposal builds to it, the plan counts down to it, the celebration happens on it. Go-live. The old system goes dark, the new one comes up, everyone exhales. The project is, on paper, done.
And then the editors log in.
Because a network model isn't a painting you hang on the wall when it's finished. It's a living record that hundreds of people edit every day — adding a service, re-routing a main, splitting a feeder, retiring an asset. Each of those edits is a chance to quietly break the thing you just spent a year getting right. The migration ends at go-live. The bad edits are just getting started.
The cutover is the moment everyone sells. The day after is the one that decides whether the project actually worked.
What the countdown clock never shows
The cutover is a milestone, not a finish line
Talk to anyone who's actually run a post-go-live network and they'll tell you the real work starts after the party. The industry has a polite phrase for it — "stabilization period" — which is a euphemism for the months we spend finding out what the live editors broke.
The reason is structural, not careless. A migration validates the network once, at a single point in time, under controlled conditions. Operations edits it continuously, in the open, under deadline:
- A new service tie gets snapped to the wrong main — geometrically fine, but the connectivity is now wrong.
- A main replacement leaves a gap of a few inches — invisible on the map, a break in the network trace.
- A phase gets transposed during a feeder edit. Nothing looks wrong. The model is now lying.
- An asset is retired but its downstream still references it — an orphan that a trace will walk straight into.
None of these throw an error. The edit saves. The map looks right. And the corruption sits there, silent, until an outage trace returns the wrong customers or a planner builds on a connection that was never real.
Important
The expensive failures aren't the edits that get rejected — those you catch. They're the edits that save cleanly and are wrong. A network model degrades one plausible-looking edit at a time, and by the time someone notices, you can't tell which of ten thousand changes started the drift.
Why this is a forever problem, not a project problem
Here's the part that reframes the whole business. A migration is bounded — it has a start, an end, and a fixed scope of data. The integrity of a live network has none of those. Every day of operation adds edits; every edit is a fresh opportunity for silent corruption. The surface area never stops growing.
| Migration | Live operations | |
|---|---|---|
| When it happens | Once, bounded | Every day, forever |
| Who touches the data | A controlled project team | Every editor, under deadline |
| Validation today | Heavy, up front, then over | Mostly nobody, after go-live |
| The failure mode | Load rejects bad rows | Bad edits save silently |
| The cost curve | Ends at cutover | Compounds indefinitely |
Look at that last column. The thing that threatens the network most is the thing no one is watching, precisely because the project that everyone was watching is over. The attention ends at go-live. The risk doesn't.
Note
This is why "we cleaned your data" is a weaker promise than it sounds. Clean data is a snapshot. A clean network is a process — it has to stay clean through every edit, or the cleanup you paid for decays back to noise within a few quarters.
The reframe: an always-on validator, not a one-time tool
Stop thinking about AI as the thing that gets you to go-live. The durable version is the thing that keeps the network honest after it. Not a migration utility you run once and uninstall — an always-on agent that watches every edit, validates connectivity the moment it changes, and catches the bad ones before they corrupt the model.
The shift is from batch to continuous. Instead of validating the whole network once, under project conditions, you validate each edit the instant it lands — at the only moment it's cheap to fix, before anything downstream has been built on top of it.
flowchart TD
A[Editor commits a change<br/>service, main, feeder]:::human --> B[Agent validates the edit<br/>connectivity, phase, traceability]:::flow
B --> C{Edit integrity}:::flow
C -->|Valid| D[Pass — commit clean]:::good
C -->|Suspicious or breaking| E[Flag before it propagates]:::risk
E --> F[[Editor sees the break<br/>in context, fixes in place]]:::human
F --> B
D --> G[(Append to<br/>network integrity log)]:::audit
E -.every flag.-> G
Validation moves to the moment of the edit — the only point where a bad change is cheap to catch. Pass it through clean, or hand it back before it corrupts anything downstream.
Three properties make this an operations layer rather than a project deliverable:
- It runs on every edit, indefinitely. Not a campaign with an end date — a standing check that's there for edit number ten and edit number ten million.
- It validates the network, not just the geometry. Snapping looks right and is wrong all the time. The agent checks connectivity, phase, and traceability — the properties a human eye can't see on a map.
- It catches the break at edit time. The whole value is in the timing. Caught now, it's a one-line fix by the person who made it. Caught in six months, it's a forensic project.
The cheapest moment to fix a bad edit is the moment it's made
The editor still has the context — they know what they were trying to do. Hand them the break right then, in plain terms, and the fix is trivial. Every day you wait, that context evaporates and the cost of the fix climbs.
Validation rules you can read and version
What counts as a "bad edit" shouldn't live in someone's head. It should be configuration — legible to operations, reviewable in version control, and the same artifact you point to when someone asks what does the agent actually check?
version: 1
agent: integrity-watch
runs_on: every_edit # continuous, not a batch job
# Connectivity is the thing maps hide. Validate it on every change.
checks:
connectivity:
no_dangling_services: true # a service must tie to a real main
no_geometric_gaps: 0.0 # endpoints must actually meet
trace_must_resolve: true # every node reaches a source
electrical:
phase_continuity: true # no silent phase transpositions
lifecycle:
no_orphaned_downstream: true # retiring an asset can't strand its children
# What happens when a check fails — catch it before it propagates.
on_violation:
block_silent_commit: false # don't reject the editor's work outright…
flag_for_fix: true # …surface the break in context, immediately
escalate_if: affects_trace # network-breaking changes go to a reviewer
evidence:
retain_integrity_log: append_only # every check + result, keptThe point isn't this exact schema. It's that the network's definition of "healthy" becomes explicit and enforced on every edit — instead of tribal knowledge that retires when your best editor does.
Audit-ready, because integrity is a claim you have to prove
A network that looks clean proves nothing. The value is being able to show, on any day, that every edit was validated and every break was caught and resolved. So each check leaves an entry behind — written once, never edited:
{
"check_id": "int_5c9b20",
"edit": { "type": "service_tie", "id": "SRV-90412" },
"rule": "connectivity.no_dangling_services",
"result": "flagged",
"detail": "service endpoint 0.4ft from nearest main — no connection",
"caught_by": "agent:integrity-watch@v3.0",
"surfaced_to": "editor:r.cole@nutility.example",
"resolution": "reconnected",
"resolved_at": "2026-06-18T15:12:44Z",
"trace_restored": true
}Read it the way an operations manager would: the agent caught a dangling service at edit time, told the editor who made it, and the trace was restored the same minute. That's not a cleanup project. That's a network that defends itself.
The failure mode to design against
The dangerous pattern isn't an edit that gets rejected — it's an edit that's wrong but indistinguishable from a good one in your history. Once bad edits blend into the stream of normal changes, you can't scope the damage, can't find the origin, and can't trust a trace. Continuous validation exists to keep that stream clean as it flows, not to clean it up after it's pooled.
Where the value quietly leaks away
The temptation is to treat validation as a periodic sweep — run it monthly, fix what it finds. Don't. By the time a monthly sweep runs, bad edits have already propagated into traces, plans, and downstream edits. The corruption isn't in one record anymore; it's in everything built on it. Continuous is not a nicer version of periodic. It's the only version that prevents the damage instead of cataloguing it.
The durable-business case hiding in all of this
Now the strategic point. A migration is a one-time engagement — valuable, but it ends, and so does the revenue. Continuous network validation does not end, because the thing it protects never stops changing. That's not a project line item. That's an operations-and-maintenance service with a reason to exist every single day the utility is open.
Note
The strongest argument for putting AI in front of a network isn't that it speeds up the migration. It's that it gives you a durable reason to be there afterward — a standing job that compounds in value as the network grows, rather than a deliverable that ends the relationship the day it ships.
This is the part that should change how the business is framed. Sell only the cutover and you've sold a finish line — a great project, and then goodbye. Sell the always-on validator and you've sold the thing the customer actually needs forever: a network that stays correct under the relentless pressure of daily edits. One is a project. The other is a franchise. The bad edits never stop — which is exactly why the business built to catch them doesn't have to either.
Anyone can get you to go-live. The durable business is the one still catching the bad edits a thousand days later.
Why "after the cutover" is the whole opportunity
The migration is the easy story to sell. The hard, durable one is keeping the network correct every day after — every edit validated, every break caught before it propagates. That standing job is what Nutility is built for. Talk to us about what your network looks like the day after go-live.