Key takeaways:
- A Utility Network migration moves the meaning and behavior of your network, not just its records, so data that loads successfully can still fail to validate, trace, or build subnetworks.
- Assess source data completeness, consistency, geometry, and relationships before you start, because data readiness is one of the biggest drivers of project scope and timeline.
- Fix known connectivity and geometry problems before migration, since features that look connected on a map may fall outside Utility Network tolerances and generate topology errors.
- A six-step pattern (trim attributes, enrich, map schema, build topology, build associations, apply final adjustments) gives every migration a clear, testable structure.
- Build a configuration-driven migration framework rather than one-off workspaces, so a changed source or a new dataset means updating parameters instead of rebuilding.
On paper, migrating a valve to the Esri Utility Network looks trivial: a legacy valve becomes a Utility Network valve. Then the questions start. Is the source record complete and valid? Which asset group and asset type should it become? Does another system depend on its existing ID? What does it connect to, and will those connections validate against the network rules?
Multiply those questions across thousands or millions of interconnected assets, and a simple migration stops being simple. Let’s discuss why Utility Network migrations become complicated, how to assess whether your data is ready, and a repeatable FME workflow for getting legacy data into a working network.
For a deep dive into this topic and demos, watch the webinar we co-hosted with Locus, Getting Esri Utility Network Migrations Right: Lessons from the Field.
Why move to the Utility Network now?
Most legacy utility GIS systems were built to show where assets are. Tracing and network analysis often relied on custom scripts and manual work. The Utility Network models how assets connect, interact, and behave, with connectivity rules, containment, structural attachment, subnetworks, and tracing built in. That supports smarter questions (e.g. “which customers are affected if this line goes down?”), stronger data governance, a more standardized model, and closer integration with enterprise systems.
Furthermore, Esri retired ArcGIS Desktop, including ArcMap, on March 1, 2026, and geometric networks are read-only in ArcGIS Pro. Organizations still managing networks that way need a path forward.
The catch is that the smarter the target model, the harder the migration. A legacy feature with a handful of attributes may now need an asset group, asset type, identity, connectivity, associations, and rule compliance.
4 pitfalls in almost every migration
Data quality. Legacy data hides years of inconsistent codes, missing values, duplicate IDs, invalid geometry, and broken relationships. Migration exposes them, which is a chance to fix them before they reach production.
Schema mismatch. Legacy models and the Utility Network are rarely one-to-one. Many legacy feature classes might collapse into a few Utility Network classes distinguished by asset group and asset type, so you are translating meaning, not just moving fields.
IDs and relationships. If a source valve ID is replaced by a new GlobalID, everything that referenced that valve has to follow. Break the chain and you break the relationship.
Topology and validation. The network still has to validate, connect, trace, and recognize subnetworks after loading. Data successfully loaded does not mean a network successfully migrated.
Pre-migration checklist
Before designing the migration, measure the maturity of your source data across GIS and asset management systems. An automated assessment can report on:
- completeness (null values, missing IDs)
- consistency (unexpected or inconsistently used codes)
- geometry (invalid or duplicate features, or points that land in Antarctica because of bad coordinates)
- relationships (missing references and broken links)
The results tell you whether you need a straightforward one-to-one migration or a cleanup project as well, and they inform the Utility Network design itself. Data readiness is one of the biggest factors in a migration timeline. Sometimes, getting the data ready becomes a project of its own.
If an assessment has already surfaced problems, fix them first. Network rules define which assets may connect (for example, a 15 kV wire to a 15 kV junction attached to a pole), and where connectivity is based on geometry, features must coincide within the geodatabase’s x,y tolerance. Features that look connected on a map can be disconnected from the network’s perspective, producing a flood of topology errors after loading. Finding and correcting those gaps beforehand is far cheaper.
6-step migration workflow
At a high level, a migration reads data from source systems, enriches it, maps it to the target schema, builds topology and associations, and writes the result to an asset package (the file geodatabase Esri uses to stage a Utility Network’s schema and data for loading). Esri describes data migration as an iterative process, so stages that can be developed and tested independently make each run, inspect, and adjust cycle faster.
- Shape attributes early. Add the fields the Utility Network needs and drop the rest at the start. With millions of features, every unnecessary attribute is baggage carried through every downstream step.
- Enrich the data. Join GIS features with asset management records (for example, with a FeatureJoiner) to build a fuller picture of each asset. In an electric network, circuit information from another system can later drive associations and subnetwork tracing.
- Map the schema with a shared table. Migration teams are mixed, and not everyone is a GIS specialist. Keeping the source-to-target mapping in a spreadsheet gives the whole team one place to review and update it. In FME, a DatabaseJoiner pulls the mapping into the workspace, so changing a mapping is a spreadsheet edit rather than a rebuild.
- Build the topology. Make sure features connect and behave as a network under the Utility Network rules by fixing gaps, overlaps, duplicates, and features attached to the wrong asset. Geometry repair works best iteratively: an automated pass fixes most problems (such as closing legacy substation outlines into polygons with transformers like the AreaBuilder and TopologyBuilder), and the rest go back to the data owner. Apply the 80/20 rule here; the last few oddities, such as a “substation” that turns out to be a CAD markup arrow, are rarely worth automating.
- Build associations. Where features coincide spatially within tolerance, the Utility Network infers connectivity from geometry. Containment and structural attachment, however, need explicit association records. Derive them from IDs that already link assets in your source systems, or infer them spatially, for instance with a PointOnAreaOverlayer to find which devices sit inside each substation.
- Make final adjustments and check the rules. Reserve a stage just before writing the asset package for the inevitable late changes to field names and table requirements. It is also the place to check associations against the rules in the asset package’s B_Rules table before anything is loaded.
Where automation saves time
Automating a migration pays off in four places:
- data preparation becomes repeatable
- each test iteration is a rerun rather than a manual redo
- validation happens automatically on every run
- the process can be reused when source data changes or another dataset needs migrating
The goal is to remove the repetitive, error-prone work. With one dataset that is useful; with dozens or hundreds, it becomes decisive.
Build a framework
The most important design decision is to avoid building Migration A, B, and C and solving the same problem three times. Instead, build a framework driven by configuration: source, target, mappings, datasets, regions, and parameters. When something changes, you update the configuration rather than the workflow.
The same six steps hold for a small proof of concept and a large multi-domain project; larger migrations simply apply the same building blocks at greater scale, with topology building usually varying most between organizations. Over time, this turns a one-off migration into a reusable process, and eventually into an enterprise capability that can assess, transform, migrate, and validate data across the organization. Keeping data clean with automated processes between migrations makes every future one easier.
Conclusion
Utility Network migrations are complex because they involve data, schemas, identities, relationships, topology, and business rules all at once. Complex does not have to mean unmanageable. Assess readiness first, fix what you can before migrating, break the work into testable stages, parameterize wherever possible, and stop solving the same problem twice. The best Utility Network migration is not the one you manage to run once; it is the one you can confidently run again.
