Why Utility Network Migration Errors Are More Expensive Than You Think
Let’s talk about the elephant in your geodatabase.
You know Dirty Areas exist. Your team knows they exist. Everyone’s been sort of politely stepping around them like a puddle in the office hallway, assuming someone else will mop it up before migration day.
Here’s the problem: nobody’s mopping. And with ArcMap heading toward retirement and Utility Network migration increasingly inevitable, that puddle is now a lake.
The Geometric Network Was Too Nice to You
For years, the Geometric Network has been an easygoing coworker who lets everything slide. Connectivity errors? No problem, tracing still works. Duplicate geometry? Sure, whatever, analysis runs fine. Invalid junction-edge connections? Eh, we’ll deal with it later.
The Utility Network is not that coworker. The Utility Network is the new manager who actually reads the employee handbook. Every invalid connection, geometry hiccup, and logical connectivity violation creates a Dirty Area. And every single one of those Dirty Areas must be cleared before you can build subnetworks or perform critical network operations.
That’s not a suggestion. That’s how it works.
For gas utilities, this means your pressure system subnetworks won’t build. For electric, your circuit subnetworks fail to generate. For your project timeline? It means weeks or months of unplanned remediation while the leadership asks increasingly pointed questions about the budget.
Let’s Put Some Numbers on This
The data quality world has a handy little framework called the 1-10-100 Rule (thank you, George Labovitz and Yu Sang Chang). It goes like this:
- $1 to verify and prevent a data error at the source.
- $10 to find and fix it after it’s been created.
- $100 per record if you just… don’t.
Now apply that to a Utility Network migration. That service meter incorrectly connected to a transmission line? In your old Geometric Network, it was a minor annoyance. In the Utility Network, it’s a Dirty Area that blocks subnetwork creation. And if you don’t catch it until after migration, you’re fixing it in an unfamiliar editing environment, under deadline pressure, with a project manager breathing audibly behind you.
Industry analysts at Gartner* estimate poor data quality costs organizations an average of $12.9 million per year. For utilities specifically, the math gets ugly fast: migration projects routinely stall for months when data quality issues surface late in the process, and rushed remediation under time pressure means paying a premium for what could have been a straightforward fix.
The Severity Scale You Should Be Losing Sleep Over
Laurel Hill GIS developed a Utility Network Data Assessment whitepaper that classifies migration-blocking errors by severity on a scale of 1 to 5. Here’s where it gets real.
Severity 5 — the migration showstoppers:
- Logical Connectivity errors. Junction-edge violations, edge-edge violations, edge-edge-junction violations. These are the big ones. A service tap connected to the wrong conductor type. An overhead device on an underground line. Every single one creates a Dirty Area, and every single one must be corrected before migration. No exceptions, no workarounds.
- Invalid Geometry. Thirteen different flavors of geometry problems, and every one of them will stop you cold.
Severity 3 — the project derailers:
- Duplicate Geometry and Vertices. Stacked features that the Geometric Network never complained about will generate Dirty Areas that need to be cleaned up before you can establish network topology.
- Subtype and Subtype Domain Validation errors. Subtypes are the basis for Asset Types in the Utility Network. Get these wrong and your features migrate to the wrong places (or don’t migrate at all).
- Pressure and Phase Validation errors. These won’t necessarily create Dirty Areas, but they’ll silently sabotage your subnetwork creation. Gas pressure system subnetworks built on bad MAOP data? Electric circuit subnetworks with mismatched phasing at tie switches? Good luck explaining those to operations.
- Disconnected Edges, Overlapping Edges, Intersect errors — the list goes on.
Severity 2 — the slow burns:
- Domain validation, referential integrity, annotation issues. They might not block migration outright, but they’ll create cascading problems in your ArcGIS Pro project in the form of broken symbology, failed definition queries, and orphaned records.
Before vs. After: A Cost Comparison You Won’t Enjoy
Here’s a scenario based on real-world assessments. A mid-sized electric utility runs a pre-migration data quality check and finds:
- 186 junction-edge violations (overhead taps connected to underground conductors)
- 212 edge-edge errors at tie switches with mismatched phasing
- 300+ service connections violating voltage class rules
That’s roughly 700 errors that would each become Dirty Areas in the Utility Network.
Fixing them before migration means working in your current editing environment — the one your team has used for years, with established workflows, familiar tools, and institutional knowledge of the data. You have a clear understanding of which areas are likely to cause downstream issues and which are not.
Fixing them after migration means working in ArcGIS Pro with a Utility Network topology you can’t validate, subnetworks you can’t build, and a project timeline that’s already slipped. Your team is learning a new editing environment while simultaneously troubleshooting data errors they’ve never seen in this context. Meanwhile, every day the migration is delayed costs money — in consultant hours, staff overtime, and/or delayed operational capabilities like outage management integration.
The cost multiplier here isn’t theoretical. It’s the difference between a planned, systematic cleanup and a panicked, reactive scramble. One of those looks like good project management. The other one looks like your next all-hands meeting is going to be uncomfortable.
What Do You Actually Do About It?
This is where a strategic approach to data assessment changes the game. The goal is absolutely to clean up your geodatabase. Every last bit of it. But the smartest path to getting there is tackling the migration-blocking errors first, then working your way down the severity scale systematically rather than stumbling across problems at random.
GeoData Sentry was built specifically for this kind of triage. It connects to your geodatabase and automatically generates tests based on your existing connectivity rules, domain configurations, and subtype structures. No manual test configuration needed for the heavy hitters — it reads your Geometric Network rules and creates Logical Connectivity tests directly from them.
What makes this particularly useful for migration planning:
- Severity-based reporting lets you focus your limited time and resources on the errors that will block migration, rather than chasing every anomaly in the database.
- Automated scheduled testing means you can establish a baseline, start fixing, and track your progress over time with trend analysis — which is extremely handy for those stakeholder updates.
- Detailed error-level output (CSV, Excel, HTML reports) gives your editors precise ObjectIDs and locations so they’re not hunting for needles in a geodatabase haystack.
And once you’ve cleaned up the data and migrated, GeoData Modeler gives you comprehensive reporting on your new Utility Network configuration — schema details, asset groups, asset types, domains — so your whole team has a single source of truth for the data model going forward.
The Bottom Line
The Utility Network is a genuine leap forward for utility GIS, but it has zero patience for bad data, and “we’ll clean it up later” is the most expensive sentence in migration project management.
The utilities that are handling this well aren’t necessarily the ones with the biggest budgets. They’re the ones who ran a data assessment early, understood their severity profile, and started systematic remediation before the clock ran out.
The ones who aren’t handling it well? They’re about to have a very educational year.
* Magic Quadrant for Data Quality Solutions, published July 27, 2020, authored by Melody Chien and Ankush Jain
Ready to find out what’s lurking in your geodatabase before migration day? Download the Utility Network Data Assessment whitepaper or request a GeoData Sentry demo using your own data — because there’s no better reality check than seeing your own error counts.