ArcGIS Utility Network Migration: Why Your As-Built Model Never Matches What the Crew Actually Built

Why the network model decides what every other utility system gets wrong

Walk into a service center at a mid-size electric utility and look for the rack of job folders. Each folder is a finished construction job with a marked up print, red pen over a plot that was already out of date when it was printed. A GIS technician works that rack, and on a normal week the rack is three to four months deep. Meanwhile the outage management system is predicting off a model that still shows a recloser on the old pole and forty services hanging off a transformer that was cut over in March. Dispatch has quietly learned not to trust the prediction, so they roll a truck to look. Nobody in that building can tell you exactly which parts of the model are wrong. They can only tell you that some of it is.

That gap is the whole business case, and it is worth stating as a number before anyone talks about software. The as-built lag is how many days pass between a crew energizing something and the model knowing about it. At most utilities we have worked with it sits between 45 and 120 days, and nobody measures it deliberately. Everything downstream inherits it. The OMS calls the wrong customers. The ADMS switching order references a device that moved. The planning engineer runs a load flow on last winter's connectivity. The joint use team bills an attacher for a pole that was replaced. One stale model, five departments improvising around it.

Then the migration lands on top. Esri has moved the platform to the ArcGIS Utility Network, which is a genuinely better data model and also a hard break: services-based editing, branch versioning, network rules, terminals, containment and structural attachment associations, subnetworks with controllers and tiers. It is not a schema upgrade. It is a different way of representing your system, and every tool your utility wrote against the geometric network stops working on the day you cut over.

Problem 1: fifteen years of custom editing tools do not come across

Your editors do not use raw GIS. They use the layer your utility built on top of it. On ArcFM Solution that means Auto Updaters firing on create and update, Favorites that place a whole assembly with one click, Session and Design based editing, and a pile of ArcObjects code somebody wrote in 2011 who no longer works there. On a Smallworld shop it means Magik customizations that encode the same construction standards. That layer is not decoration. It is why a new editor can place a padmount transformer correctly on their second day.

None of it survives. ArcObjects is gone, replaced by the ArcGIS Pro SDK in .NET. Auto Updaters have no direct equivalent, and the honest replacement is attribute rules written in Arcade plus server-side logic, which is a different execution model with different failure behavior. Custom traces built on the geometric network get rewritten against the utility network trace configuration and its subnetwork definitions. If your migration plan says the tools will be ported, ask to see the inventory. Most utilities discover they have between 60 and 300 individual customizations, roughly half of which nobody uses and nobody dares delete.

What a custom build does here: it triages that inventory first, keeps the twenty or thirty behaviors editors actually depend on daily, and reimplements them as attribute rules, Pro add-ins and server-side validation rather than as a line-for-line port. The measurable target is the time it takes a technician to post one distribution job. If that number does not improve on the new platform, the migration was a schema exercise and your as-built backlog will be exactly as deep in December as it was in June.

Problem 2: the as-built backlog is a workflow problem wearing a data costume

Everyone treats posting backlog as a staffing issue. It is usually a handoff issue. The construction package leaves engineering as a design, the crew changes it in the field because the anchor would not go in where the print said, the redline comes back on paper or as a phone photo in an email, and the technician who posts it has to reconstruct intent from a smudged sketch. On the utility network that reconstruction is harder, not easier, because the model now demands associations and terminal connectivity the old geometric network let you fudge.

Esri gives you the pieces: branch versioning so a job is a version, validate network topology, the error inspector, dirty areas. What it does not give you is your utility's workflow around those pieces. Which jobs need engineering review before post. What happens to a version that has been open for eight months. How a phase correction gets pushed to the OMS the same day rather than the same quarter. That is the layer worth building, and it is unglamorous: a job queue with states, assignment, aging, and a validation gate that will not let a version post with unresolved errors on the affected feeder.

The one place AI does concrete work here is redline intake. Field redlines arrive as photos of marked prints. A vision model can read the annotations, match them to the design's proposed features, and produce a proposed edit set for the technician to accept or reject. It will not be right every time and it does not need to be. It needs to save the reconstruction step, because that step is where the hours go.

Problem 3: every downstream system wants a different shape of your model

The utility network is one model with many consumers, and each consumer wants something slightly wrong for the others. The OMS wants connectivity and customer-to-transformer relationships with device normal states. The ADMS wants an unbalanced electrical model with impedances and phasing that will actually converge. Planning wants a feeder export CYME or Synergi Electric can read. The engineering analysis group wants CIM. Work management wants an asset register keyed on your equipment numbers, not GIS object IDs.

The default answer is a nightly extract per consumer, each written by whoever owned that project, each silently drifting. Then a phase correction gets posted in GIS and shows up in the OMS three days later, in the planning export next month, and in the CIM extract never. When the numbers disagree, three departments each defend their own copy.

What a custom build does: one export service with per-consumer projections built from the same validated topology, with a run log that records which model version produced each extract, and a diff report so the OMS team can see exactly what changed overnight instead of discovering it during an outage. Phase and normal state get treated as first-class audited attributes, because those two fields cause more downstream arguments than everything else combined.

Problem 4: conversion is most of the project and nobody budgets for it honestly

The software work is the visible part. The data work is the larger part. Getting from a geometric network with twenty years of accumulated compromise into a utility network that will pass validate topology means resolving things your old model tolerated: disconnected devices sitting a foot off the conductor, transformers with no bank association, secondary that was never digitized, structures that carry no attachment associations, phase attributes populated three different ways because three different vendors did three different conversion projects.

Esri's asset package approach and the industry data models, including UPDM for gas, give you a target schema. They do not give you clean source data. Expect to run conversion iteratively: load, validate, produce an error report by feeder, fix at the source, reload. Utilities that treat this as a single cutover event fail. Utilities that run it weekly for six months, with a named person accountable for the error count going down, succeed.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category has a consistent shape. The workflow layer alone, meaning job and version management, as-built posting with validation gates, redline intake and the first two downstream exports, runs $90,000 to $200,000 and ships in 14 to 20 weeks. A full program that adds conversion tooling with repeatable error reporting, offline field capture, subnetwork exports for OMS and ADMS, and integration with Maximo or your work management system runs $250,000 to $700,000 phased over 9 to 18 months.

What drives the number up: the count of surviving legacy customizations, because each one is a conversation with the editors who depend on it. Gas alongside electric, because the pressure system and the UPDM model are a second domain, not a second layer. Multiple operating companies with different construction standards. Water and wastewater added late, which sounds easy and is not, because the tracing semantics differ. And the honest one: how much of your model was never actually verified against the field. If a third of your secondary is guessed, no software fixes that and you are buying a field verification program, not a GIS project.

What keeps it down: picking two feeders and one district as the pilot, running the whole loop on them including a real post and a real OMS handoff, then scaling. Utilities that try to convert everything before anyone uses anything spend a year building confidence in a system nobody has touched.

Build versus buy, and where buying is obviously right

Buy the platform. We will say that plainly even though it means less work for us. Esri ArcGIS Utility Network, GE Smallworld and Bentley OpenUtilities are the serious options and none of them should be rebuilt. If you are a small co-op with under about 40,000 meters, a stable system and one GIS technician, buy the platform, buy a configured vertical solution, and spend your money on field verification instead of software.

Build the layer around it when your workflows are the differentiator and the vendor solution cannot express them. That is true when your as-built lag is over 60 days and staffing has not moved it, when you have more than about 50 legacy customizations your editors genuinely use, when three or more downstream systems consume the model and disagree with each other, or when you run multiple operating companies whose construction standards will never be reconciled. In those cases the platform is necessary and not sufficient, and the gap gets filled by people retyping.

How to choose a developer for utility network work

Ask them to explain associations. Not connectivity, associations: containment, structural attachment, and why a transformer bank is modeled the way it is. A developer who has done this will answer in ninety seconds. A developer who has not will talk about points and lines, and you will be teaching them the domain on your budget.

Ask what they will do with your existing ArcFM Auto Updaters, by name and by count. The answer you want is a triage plan with an inventory, not a promise to port everything. Anyone promising a full port either has not counted them or intends to bill you for behaviors nobody has used since 2016.

Ask how they validate. Specifically, ask what their build does when a technician tries to post a version with topology errors on a live feeder, and what the OMS receives that night. If the answer is that the export just runs, they have not worked with an operations group that gets paged at 2am.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the ArcGIS Enterprise configuration, and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. Start there, then ask for one reference where the as-built lag actually dropped, and call them.