Utility Network GIS Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the migration get scoped as a schema conversion?

Because that is how it is presented. The platform change is real and technical, the target model is documented, and a plan that says convert the data and validate the topology reads like a complete project. It is a complete data project. It is half a migration.

The other half is the editing workflow, and it is where the money either shows up or does not. Your editors do not use raw geographic information software. They use the layer your utility built on top of it over fifteen years, which is why a new technician can place a padmount transformer correctly on their second day. Move the schema and leave that layer behind, and posting gets slower rather than faster, because the new model demands associations and terminal connectivity the old geometric network let people fudge.

The measurable target should be written into the project charter before anything is designed: the time it takes a technician to post one distribution job, and the number of days between a crew energising something and the model knowing about it. Almost nobody measures the second one deliberately, which is precisely why it drifts.

The fix is to fund the workflow layer as part of the migration rather than as a follow-on. Job and version management, assignment and ageing, a validation gate that refuses to post a version with unresolved errors on the affected feeder, and redline intake. If those are not in the plan, the migration will finish on time and change nothing anyone outside the geographic information team can feel.

What goes wrong when a geometric network has to pass validation?

Conversion is where the schedule actually goes, and the reason is that the old model tolerated things the new one will not. Devices sitting a foot off the conductor. Transformers with no bank association. Secondary that was never digitised. Structures carrying no attachment associations. Phase attributes populated three different ways because three different vendors ran three different conversion projects over two decades.

The failure pattern is predictable. A team treats conversion as a single cutover event, loads everything, gets an error report with tens of thousands of entries, and has no way to decide what to fix first or who owns it. Six months later the error count is roughly where it started because every fix was made in the converted copy rather than at the source, so the next load reintroduces it.

Run it iteratively instead: load, validate, produce an error report broken down by feeder and by error class, fix at the source, reload. Weekly, for months, with a named person accountable for the count going down and a chart that everyone can see. Assign each error class an owner, because a disconnected device is a different team's problem from a missing bank association.

And be honest about the part software cannot fix. If a third of your secondary is guessed rather than surveyed, you are buying a field verification programme, not a software project, and it should be budgeted and staffed as one.

Why do the downstream exports break after launch?

The network model has many consumers and each wants a different shape. The outage system wants connectivity, customer-to-transformer relationships and device normal states. The advanced distribution management system wants an unbalanced electrical model with impedances and phasing that will converge. Planning wants a feeder export that CYME or Synergi Electric can read. Work management wants an asset register keyed on your equipment numbers rather than internal object identifiers.

The default answer is a nightly extract per consumer, each written by whoever owned that project, each drifting silently. After the migration they drift faster, because the source schema changed underneath all of them at once. Then a phase correction posted in the geographic system appears in the outage system three days later, in the planning export next month, and in the analysis extract never. When the numbers disagree, three departments each defend their own copy and nobody can say which is right.

Build one export service with per-consumer projections from the same validated topology, a run log recording which model version produced each extract, and a nightly difference report so the outage team sees exactly what changed rather than discovering it during an event. Treat phase and device normal state as first class audited attributes, because those two fields cause more downstream argument than everything else put together. Then add the check that catches the rest: reconcile counts between the model and each consumer daily, and alert a named person when they diverge.

What happens when legacy tools are promised as a straight port?

Every migration proposal contains a sentence about carrying across existing customisations, and it is the sentence that produces the largest overrun. The tools do not port. The older interfaces are replaced by a different development model, and automatic update behaviours have no direct equivalent, so the honest replacement is attribute rules plus server-side logic with different execution and different failure behaviour.

The number nobody has is the count. Most utilities discover somewhere between 60 and 300 individual customisations when they finally inventory them, and roughly half are unused and nobody dares delete them. Paying to reimplement behaviours that stopped being used years ago is how a budget doubles without anyone deciding to spend it.

The second thing promised too easily is offline field editing. Field capture works well for inspection, redline and attribute collection, and it works poorly as a substitute for full network editing inside a version. Utilities that plan for crews editing topology directly discover the constraint late, after the field application has been designed around it.

Both fixes are the same shape. Inventory first, then triage: keep the twenty or thirty behaviours editors depend on daily, reimplement those properly, and formally retire the rest with the editors in the room. Design the field application around producing a proposed edit set that a technician validates and posts, rather than around direct topology editing. Anyone promising a full port either has not counted the customisations or intends to bill you for behaviours nobody has opened since 2016.

Should you build custom or configure what you already own?

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 represent decades of network modelling and rebuilding any of them is not a rational use of capital.

If you are a cooperative under roughly 40,000 meters with a stable system and one geographic information technician, go further: buy the platform, buy a configured vertical solution on top of it, and put the remaining money into verifying what is actually in the field. A configured product plus disciplined posting will serve you, and your constraint is data accuracy rather than tooling.

Build the layer around the platform when your workflows are the thing that differs and no vendor configuration expresses them. That is true when as-built lag stays above 60 days despite staffing changes, when more than about 50 legacy customisations are genuinely in daily use, when three or more downstream systems consume the model and disagree with each other, or when several operating companies bring construction standards that will never be reconciled. In those cases the platform is necessary and not sufficient, and the gap gets filled by people retyping.

How do hidden costs get into the quote?

The customisation count is the first, because it is usually unknown at quoting time. Insist the inventory happens before the number is fixed, or agree a rate for reimplementation per surviving behaviour so the commercial risk is shared rather than discovered.

Gas alongside electric is the second, and it is regularly priced as a second layer when it is a second domain. The pressure system and its data model are their own body of work. Water and wastewater added late looks easy and is not, because the tracing semantics differ.

Then multiple operating companies with different construction standards, each of which multiplies the configuration and the testing rather than adding to it. And the honest one: how much of your model was never verified against the field. That is not a software line item, and a proposal that does not raise it has not looked at your data.

Finally, watch for conversion priced as a single pass. It is iterative by nature, and a fixed price built on one load and one validation cycle will be renegotiated in month four.

What separates a build that works from one that fails here?

Pick two feeders and one district, run the whole loop on them including a real post and a real handoff to the outage system, and only then scale. Utilities that convert everything before anyone uses anything spend a year building confidence in a system nobody has touched.

Test domain understanding early. Ask the developer to explain associations rather than connectivity, meaning containment, structural attachment, and why a transformer bank is modelled the way it is. Someone who has done this answers in ninety seconds. Someone who has not will talk about points and lines, and you will be teaching them the domain on your budget.

Ask what their build does when a technician tries to post a version with topology errors on a live feeder, and what the outage system receives that night. If the export simply runs, they have not worked with an operations group that gets paged at 2am.

Then settle ownership in writing before kickoff, covering the repository, the enterprise configuration and the right to hire anyone else, because utility geographic systems outlive vendor relationships by decades. Ask for one reference where as-built lag actually dropped, and call them.