In a Utility Network, the data model isn’t a description of the system. It is the system.
For most of the ArcMap era, a utility’s data model documentation was a nice-to-have. The Geometric Network didn’t care much what your fields were called or what values they held. As long as lines snapped to points, the network worked. The model lived in a Visio diagram from the original implementation, a spreadsheet someone maintained for a while, and the memory of two or three people who had been there since the beginning.
That arrangement doesn’t survive contact with the Utility Network. In ArcGIS Pro, the data model is no longer a passive description. Asset groups, asset types, terminals, network rules, and attribute rules are the mechanism through which the network operates. Get the model wrong and the network doesn’t merely look untidy. It refuses to trace, refuses to build subnetworks, or refuses to accept the data at all.
That shift changes what data model management has to do. Documentation is still part of it, but it’s the least of it. This post is about the rest: how GeoData Modeler supports the bridge from legacy models to ArcGIS Pro, keeps the model honest while it’s changing, and holds up as Esri’s platform keeps moving.
Why the Utility Network is a data-model problem
It helps to be concrete about what changed. In a Geometric Network, the model was a handful of feature classes with whatever fields the utility chose, connected by a network that only understood geometry. In a Utility Network, the model has to answer questions the old one never asked:
- What is this feature? Every feature is classified by asset group and asset type, and those classifications drive which network rules apply.
- What can it connect to? Connectivity rules define, explicitly, which asset types may join which others and at which terminals. A connection the rules don’t allow is an error, not a connection.
- What role does it play? Subnetwork controllers, tiers, and categories are model definitions. A breaker only controls a circuit because the model says a breaker can.
- What values are valid? Attribute rules enforce domains, calculations, and constraints at edit time. They’re written against specific field names and specific codes.
Every one of those answers is a schema decision, and every schema decision has consequences that show up somewhere else: in an attribute rule, in a network rule, in a SCADA integration that reads a field by name, in a map that symbolizes on a code. The model is now a web of dependencies, and a change anywhere in it can break something far away.
Bridging the legacy model to ArcGIS Pro
Migration starts with a question most utilities can’t answer with confidence: what exactly is in our current geodatabase? Not what the implementation documents from years ago say. What’s actually there, after a decade of field additions, contractor projects, one-off fixes, and integrations that quietly added columns.
GeoData Modeler starts by documenting the as-is model directly from the geodatabase: every feature class, field, domain, subtype, and relationship class, as they exist, not as they were designed. That inventory is the foundation for the mapping exercise that follows:
- Field-by-field mapping from legacy classes to Utility Network asset groups and types. A single legacy feature class with 14 subtypes might become several asset groups with dozens of asset types. Each mapping has to be recorded and defended.
- Identifying what to retire. Fields nobody has populated in years, domains with values that no longer exist, relationship classes that were superseded. Every one carried forward is complexity the new model has to support.
- Identifying what’s missing. The Utility Network needs attributes the old model never captured: terminal configurations, phase designations that were implicit, pressure values that lived in a separate system. Gaps found during mapping are gaps found early.
- Preserving the rationale. Six months into the project, someone will ask why a legacy field was mapped to one asset type rather than another. If the answer lives in a person’s memory, it may not be available.
The value here isn’t the documentation itself. It’s that the documentation is generated from the database and maintained alongside it, so the mapping is built on what’s real.
Supporting the model while it’s changing
Utility Network migration is not a single design decision followed by a single load. It’s an iterative process. The first version of the target model goes through a pilot load, subnetworks fail to build, rules get adjusted, asset types get split or merged, and a second version goes through the same cycle. Three, four, five iterations are normal.
That’s where informal documentation breaks down. The Visio diagram was accurate for version one. By version three, nobody is sure which fields were renamed, which domains were consolidated, or which attribute rules were rewritten. The integration team is building against a schema that no longer exists.
GeoData Modeler treats the model as something that changes, and manages the change:
- Version comparison. Two snapshots of the model, whether documented designs or live geodatabases, can be compared to produce a precise list of what differs: added fields, dropped domains, changed subtypes, modified relationship classes.
- Drift detection. The documented model is compared against the deployed geodatabase to catch the changes nobody recorded: the field a developer added during testing, the domain value a contractor introduced, the subtype that was supposed to be removed and wasn’t.
- Automated documentation updates. When the geodatabase changes, the documentation is updated from it rather than rewritten by hand. The model of record stays the model that’s actually running.
- Impact visibility. Because integrations, reports, and rules are tracked against the fields they depend on, a proposed schema change can be evaluated for what it will break before it’s made.
The practical effect is that every team working on the migration (GIS, integration, field operations, reporting) is working from the same current model, and the difference between the design and the database is a report rather than a surprise.
Validation, not just description
It’s worth being specific about the word “validation,” because it means something different here than it does in a data-quality tool like GeoData Sentry. GeoData Sentry validates the data: does this feature’s pressure value match its neighbors? GeoData Modeler validates the model: does the schema the geodatabase is running match the schema everyone believes it’s running?
Both matter, and they fail differently. Bad data in a good model produces errors that are visible and fixable. Good data in a drifted model produces failures that are baffling: an integration that starts returning nulls, an attribute rule that stops firing, a report that silently omits a category. The data is fine. The model underneath it moved.
Model validation is what turns those baffling failures back into ordinary ones. When the documented model and the deployed model are compared on a schedule, the drift is caught as a schema difference, which is a thing a GIS administrator can act on immediately.
Keeping pace with Esri’s platform
ArcGIS Pro and ArcGIS Enterprise release on a regular cadence, and the Utility Network itself has moved through multiple versions, each with schema changes, new capabilities, and new requirements. A utility that migrates today will upgrade its Utility Network version more than once in the life of the implementation.
Each of those upgrades is a data model event. Some are small. Some restructure how terminals or associations are stored. Either way, the same questions come back — what changed, what depends on what changed, and what has to be updated as a result. A utility that has been managing its model with GeoData Modeler since migration answers those questions with a comparison report. A utility that hasn’t is back to the Visio diagram.
The same is true for the systems around the GIS. Advanced distribution management, outage management, SCADA, asset management, customer information systems: every one of them integrates against the geodatabase schema, and every one of them is on its own upgrade cycle. Integration management, which is a core function of GeoData Modeler, exists precisely so that the schema dependency between GIS and those systems is explicit and tracked rather than rediscovered every time something breaks.
Future-proofing the architecture
There’s a strategic version of this argument that goes beyond upgrades. Utilities are being asked to do more with their network data than ever before: grid modernization programs, distributed energy resource integration, advanced analytics, and, increasingly, machine learning models that consume network data at scale. Every one of those initiatives depends on a data model that is understood, stable, and documented well enough for a data scientist or an integration developer to build on without a GIS analyst sitting beside them.
The utilities that will move fastest on those initiatives are the ones whose data model is an asset they manage rather than a mystery they inherited. A model that’s documented from the database, versioned as it changes, validated against what’s deployed, and mapped to everything that depends on it isn’t just easier to migrate. It’s easier to build on for the next decade.
From documentation to architecture
GeoData Modeler began as a documentation tool, and it still does that job well. But in a Utility Network implementation, documentation is the starting point, not the deliverable. The deliverable is a data model that stays correct while it changes, and a team that can see the consequences of a change before making it.
If your utility is planning a Utility Network migration, in the middle of one, or maintaining a network that has already gone live, Laurel Hill GIS can show you how GeoData Modeler fits into that work.
Contact us for a demonstration.