You are here

Esri Utility Network - Migrating Your Data into the Utility Network

We loved seeing you last week at the Esri GeoConX conference in Phoenix, AZ! SSP had record booth traffic with the conversation focused largely on the new Utility Network, including demos on our SSP migration tools to the Utility Network and on Esri's out-of-the-box Utility Network tracing functionality. Thank you for stopping by! Your feedback has helped guide our discussions, and we encourage you to keep reaching out with questions in this blog post series. Without further ado, here is the fourth article: 

How to Migrate to the Utility Network

Utility Network Demo at GeoConX

In this post, I am going to break away from the model we've been using to guide our post topics; there is certainly a lot more to cover in this model, and we'll continue in following posts. But in this post, I'll tell you about the Utility Network migration process, which SSP premiered at GeoConX.

To come up with this migration process, we've been working with Esri. The result is a straightforward approach to loading your data into the Utility Network while keeping three key goals in mind:

  1. Integrity: Maintain the integrity of the network from the geometric network data
  2. Usage: Create a process that enables instant usage of the new Utility Network rules, tracing, connectivity, diagrams, etc.
  3. Configurability: Make the process completely configurable so that individual utilities will be able to make informed decisions on how their data is migrated

The second point, instsant usage, became an interesting discussion between SSP and several of our customers at GeoConX. The new Utility Network allows us to configure very advanced connectivity for devices such as Wye and Delta transformers, where we can map the internal GIS workings of the transformer terminals to match the real world.

This granular connectivity may prove useful as it relates to some ADMS systems and additionally for potential new GIS-based integration that may come up in the next 15-20 years of Utility Network usage. But the complexity of the model has proven challenging to many customers who just don't believe we should be modeling this level of connectivity in the GIS ... yet.

A Migration that Does What You Need it To 

With that in mind, our goal at SSP was to design a migration process that would migrate your geometric network data into the Utility Network by utilizing configuration/rules that would allow customers like you to take advantage of the advanced connectivity (now or in the future) but that would not require all of the aspects of the granular connectivity to allow the network to function.

Our process begins with a mapping exercise, where we will map the following items between the geometric network and the Utility Network:

Utility Network Migration Mapping

To learn more about any of these concepts, please read up on our previous Utility Network blog posts.

How the SSP Utility Migration Migration Process Preserves Integrity

The above mappings are completed and then fed into our SSP migration application, which reads your geometric network and translates its data into the Utility Network format, within a 10.2.1 intermediate staging geodatabase.

Utility Network Migration Process

There are a few key reasons why we are migrating to a staging geodatabase within 10.2.1. First, we want to build your confidence in the data that we are going to load into the Utility Network. A significant aspect of the new network is the associations, including connectivity associations, structural attachment associations and containment associations.

Our migration application handles all of these associations within the staging database; it does so by creating the associations as linear records that can be visualized on the map. This allows the user to review them in detail before importing them into the Utility Network:

Connectivity Associations

The second, and primary, reason we are using 10.2.1 ArcMap to review the staging database is because this is the software that the end users know and love already, thus allowing them to easily review all aspects of the data before importing it into the Utility Network (where all further review will occur in ArcGIS Pro).

Once the staging database is approved, we use a scripted "import utility script" to perform the following actions:

The end result is a fully connected Utility Network model in ArcGIS Pro that can be further reviewed, QA'ed, or traced. Each electric circuit, gas pressure system, or water pressure system is established as a Utility Network subnetwork. The ID of the subnetwork is persisted/saved on every feature within the subnetwork. All the expected traces can then be performed: upstream, downstream, protective device, and so forth.

Downstream Trace

Finally, a single linear feature is established for every circuit/system extent within the SubnetLine feature class. This provides for easy and fast rendering of a color by network map. All of this reads pretty well but a demo is worth a 1,000 words and pictures! Check out the demonstration of the full migration process here:

Our goal in creating this migration process, including the QA staging database, is to create a process that brings across your fully connected circuits and systems into the Utility Network, while taking advantage of every feature this new Utility Network has to offer. Our hope is to have each customer get involved with the new Esri Utility Network as soon as possible. We are expecting the beta release of the Utility Network in January 2017.

Looking ahead to the Utility Network Beta

utility network

To reduce the barriers to entry your organization might feel while begining to use the beta Utility Network, we've created a hands-on, two-day training program called the Utility Network Jumpstart Package. The Utility Network Jumpstart Package from SSP also includes the option of using the above-described migration process to load a subset of your own data into the utility network! Just ask us for details. 

We were fortunate to talk to many of you in person at GeoConX about this program. However, if we didn't connect and you want to know how you can easily get on the Utility Network beta release, please contact us, so we can explain all the details!

In the meantime, we'll continue with our Utility Network education through this bi-monthly blog series. Please keep the questions and comments coming, as they ensure we are hitting on the right points for the utility and telco communities! 

Author Information

  • Skye Perry

    Skye Perry

    Skye Perry is a Principal Consultant for SSP Innovations and has provided technical architecture, development, and management solutions for GIS-centered implementations since 2000. Skye's roots tie back to Convergent Group, Miner & Miner, and Enspiria Solutions where he has focused on implementing Esri GIS customizations and system integrations. Today Skye is still involved on a number of SSP's project implementations and supports technical marketing in addition to leading the company.

    See all items created by this author >

    Connect with me on:


Hello Skye. As you know we have a lot of annotation feature classes. How will they tie into the new structure of the UN?


Hi Steve, there will be a new annotation model coming out. The existing anno classes are not supported across the whole Esri platform. The new anno model will have a similar concept to feature linked annotation but there will be a migration aspect to moving your existing anno into the new classes. The new anno model hasn't been released yet and we'll definitely update everyone on it when it is! Great question...

Thanks for your reply. I was also wondering about migrating fields into the new model. If I understand correctly, most of our networked electric points, for example, will be stored in a single electric device featureclass in the UN model. Any one of our current feature classes like transformer banks or switches may have upwards of 20-30 fields. Would the conversion to UN mean we could have domain featureclasses with hundreds of fields and mostly empty records for fields that only apply to one asset group?

Steve, you are correct. We will need to merge the extra business fields from the various source classes into a single destination classes for each source type. Where multiple source classes share the same field we would obviously use the same field in the destination class. Where they have differing fields, we would add them on and then filter them in the UI so the user only sees the applicable fields for each asset group / asset type. The other option we've discussed is adding related objects for some of the asset data so that you would move the attribute data into a related asset specific record. This would keep the data in separate tables BUT has the downside of not managing the data directly on the individual feature records.

Hello Skye As suggested in article we should promote unit object class to AssetGroup/AssetType. But for example we have a tranformerunit class in GN while migrating it to UN what will be the value of SHAPE field in UN feature class as this field does not allow null value.

Thanks in Advance

Hi Suraj, you definitely need to populate the shape value on the transformer units. Our migration application essentially uses an offset from the existing transformer bank to "promote" the units onto the map. If it's a single phase it's pretty straight forward. If it's a three phase OH then we are offsetting further to create three distint points on the map. I hope this clarification helps - definintely plan on them being GIS features.

Hi Skye,
Thanks for your quick response but I still have some confusion. Suppose we have a transformer in Transformer feature class and a related transformer unit in Transformer unit table object class in GN. As per my understanding we can migrate transformer feature into Distribution device feature class in UN.
Transformer feature has geometry also so there won't be any issue. But how we can migrate transformer unit feature in to UN distribution device feature class as this feature does not have any geometry and at the same time on which attribute we can establish the relationship between transformer feature and transformer unit feature in the same feature class that is UN Distribution device. Also will there be two different features one for transformer and other for transformer unit in UN Distribution Device feature class. This will be grateful if you can clarify the above mentioned queries.



I'd actually propose that you migrate you features from the "transformer" feature class into the new Assembly feature class in the utility network. Then you'd migrate your transformer unit object records into the Device feature class in utility network. You are correct that the transformer units do not currently have a geometry/shape. So the migration process SSP has established takes the transformer bank shape and derives geometry information for the transformer units. You then establish a containment association between the Assembly (transformer) and the Device (transformer unit) records. I hope this clarifies... they aren't going into the same feature class in the UN.

Hi Skye,
In electric data set there are many tables which are not unit objects like customerinfo, usageinfo,demandinfo, loadsummary etc. so what is the migration thought of these tables from geometric network to utility network.

Suraj, these other tables would be migrated as-is and we can still build relationship classes between those tables and the UN feature classes as needed. No worries there!

I have one question related to data migration. While migrating data from Geometric network to Utility network what approach we should follow to create connectivity associations in utility network?
i know i can create a association csv file which we can import to create association but my problem is what approach i should follow to create this csv using geometric network.


Hi Suraj, we started by using the CSV import methodology and originally created the CSV files automatically via our ArcObjects migration application. We have, however, moved on and are actually utilizing the Utility Network APIs to create the associations which turns out to be much faster than importing the CSV. Either way should work though. The challenge is how you determine where the associations need to be created and that is likely a custom piece of code based on the rules of your utility.

Add new comment