Utility Network migrations are taking too long
Esri's materials suggest a 3–6 month Utility Network migration. In reality most utilities take 12–18 months, and the established partners are spending years per project. It may sound like a hot take, but it's really a simple math problem — and the math says something has to change. Here's the throughput gap, the complexity trap that created it, and the lens that gets you live in months instead of years.
How long does a migration actually take?
Esri's marketing materials suggest 3–6 months for a Utility Network migration. That timeframe is real — but only for a small, clean network. In practice, timelines scale with complexity, and many utilities land somewhere between 12 and 18 months. The most established implementation partners are spending years per engagement. The gap between the brochure and the reality has become one of the hottest topics in the industry.
Here's the uncomfortable version: Utility Network migrations are taking too long. It may sound like a hot take. It's actually a simple math problem.
The math doesn't lie
There are roughly 3,000 electric utilities in the United States, and Esri is estimated to be used in some capacity by more than 80% of them. At the time of this writing, fewer than 100 utilities are live on the Utility Network across all commodities — with roughly 21 months remaining before ArcMap goes out of support.
Work the arithmetic and the picture gets stark.
| The input | The number |
|---|---|
| Electric utilities in the U.S. | ~3,000 |
| Share using Esri in some capacity | 80%+ |
| Live on the Utility Network today (all commodities) | < 100 |
| Months until ArcMap support ends | ~21 |
| Electric utilities that must go live per month to hit the deadline | ~114 |
About 114 utilities would need to go live every single month to clear the electric backlog in time — and that's before you account for gas, water, wastewater, and telecommunications. Measured against current throughput of two to five years per implementation, the deadline isn't tight. It's arithmetically out of reach.
The numbers don't lie: something has to change.
The throughput problem in one line
The most established Utility Network implementation partners are spending years on these projects and constantly growing their organizations to try to meet market demand. Unfortunately, simply throwing more people at these engagements won't move the needle. The industry needs a fundamentally different approach — one that produces faster timelines, more predictable costs, and ultimately more successful outcomes.
Important
Headcount is not throughput. Adding people to a years-long project mostly adds coordination overhead — more handoffs, more review cycles, more ways for the data to drift. The constraint isn't how many hands are on the project. It's how the project is scoped and how the work gets validated.
The complexity trap
Part of the problem is how these projects have been framed. As the mystique around the Utility Network has grown over the past decade, so have the scopes, timelines, and budgets. And as budgets have grown, so has the pressure to justify them — which leads organizations to layer on additional objectives that push timelines even further out.
flowchart TD
A[UN mystique grows]:::flow --> B[Scope and budget grow]:::risk
B --> C[Pressure to justify<br/>the budget]:::risk
C --> D[Add more objectives<br/>ADMS, integrations, redesign]:::risk
D --> E[Timeline pushes out<br/>further]:::bad
E --> B
The complexity trap is a loop, not a line. Every added objective justifies the budget that invites the next added objective — and the go-live date keeps receding.
It's worth being precise about how this happens, because no one sets out to build a four-year project. It accretes. A modest migration gets a data-model refresh attached because "we're in there anyway." The refresh justifies a larger budget. The larger budget invites a systems-integration workstream. The integration work raises questions that are easier to answer if you also stand up the new analytics platform. Each step is individually reasonable. The sum is a timeline measured in years and a go-live date that keeps sliding to the right.
A common example: bundling a Utility Network implementation with an ADMS implementation, or deliberately extending the design-and-build phase to accommodate what ADMS might need someday. Planning ahead is smart. But consider the trade-off honestly:
The question to ask out loud
Would you rather have a Utility Network that's probably ready to support your ADMS after a four-year project — or one that's fully operational in under six months? Scope creep is the silent killer of these projects, and the industry has normalized it.
A different lens
There are two legitimate ways to approach a Utility Network implementation, and both are valid. The trouble starts when a project tries to be both at once without admitting it.
| Transformation | Risk mitigation | |
|---|---|---|
| The mandate | Modernize everything at once | Land safely on a supported platform |
| The goal | Reimagine how the org operates | Protect existing workflows and data |
| The scope | Data model, integrations, redesign | Faithful translation, then build |
| The horizon | Multi-year | Months |
The first lens treats the migration as a transformational initiative — a once-in-a-generation opportunity to modernize your data model, integrate systems, and reimagine how your organization operates. If that's genuinely your mandate, go for it, eyes open about the timeline.
The second treats it as risk mitigation. Your current system is going out of support. Your goal is to protect your organization, maintain your existing workflows, and land safely on a modern, supportable platform. With that lens, the path forward is far more direct: translate your existing data and products as faithfully as possible into the new system, and build from there.
Pick your lens before you pick your scope
Most schedule blowups aren't a single bad decision — they're a transformation project wearing a risk-mitigation deadline. Decide which one you're actually running first. The scope, the budget, and the timeline all fall out of that one choice.
The Utility Network is a powerful platform with capabilities your current system simply can't match. But your existing system didn't reach its current form overnight — it evolved over years of incremental improvement. There's no reason your Utility Network can't do the same. Getting live on a supported platform and then improving it is not the lesser path. For most utilities facing the ArcMap deadline, it's the only one the math actually allows.
Don't let "someday" hold "supported" hostage
Every capability you defer until after go-live is a capability you can still add on a modern, supportable platform. Every capability you bolt onto the migration is a month you spend on the unsupported one. The risk you're managing is the deadline in front of you — not the wish list behind it.
Get live. Get stable. Then grow.
The honest read of the throughput numbers is that the industry can't deliver multi-year transformations fast enough to beat the support deadline — so for most utilities, the multi-year transformation was never the right scope to begin with. Translate faithfully. Land on a supported platform. Stabilize. Then take on the modernization, one deliberate increment at a time, exactly the way your current system earned its capabilities in the first place.
Get live. Get stable. Then grow.
Facing the ArcMap deadline and watching your Utility Network timeline stretch past it? The fastest safe path is a faithful translation you can trust — and keeping that migrated data correct, attributable, and audit-ready is where the months usually go. Talk to us about getting live without the multi-year detour.