High availability (HA) is not necessary for the UN and many organizations choose not to deploy their systems with this architecture. Those organizations choosing to implement a HA system do so to provide greater uptime protections as they tend to consider the GIS a more critical system. Often their businesses rely more heavily on other on-premise components of the GIS like the Portal and feature layers consumed by Esri mobile applications.

If your organization makes the decision to deploy a HA system, plan to troubleshoot the normal things that go along with any system implementation. The motions of joining sites and components up isn’t that complicated in theory. The issues from the unanticipated stuff that can throw the implementer for a loop. Make sure the architecture is done right in advance of other tasks, so you have a strong foundation to take advantage of its benefits.

It is important not to treat a move to the UN like a run-of-the-mill GIS upgrade. This is an opportunity to make valuable improvements to your integrations and processes. Many people and parts of your business will rely on this new technology to improve their daily operations and make your organization more efficient as a whole. You need to make sure your key stakeholders are aware of this opportunity!

Expectations need to be set from the top to the bottom of the organization. While lots of improvements are made in the solution, it’s important not to treat this like a GIS version upgrade.

Organizations implementing a UN need to properly prepare their budgets. This might simply mean budgeting enough dollars, but quite frequently it also means the organization isn’t giving itself enough time to put the budget together in the first place.

Take Organization Change Management (OCM) seriously. How do you prepare your company for the change? How do you handle training, infrastructure changes, business process changes? Again, this is an amazing opportunity to re-evaluate how you are utilizing your GIS and make changes to take advantage of not just what the Utility Network brings, but to improve and streamline other business processes that utilize GIS.

Most people are unclear about how much technology they need to get their jobs done after the move to the UN. People don’t know what 3^rd party applications are in the mix.

The Esri core stack capability has expanded. Some organizations might be fine with just the core stack and UN to meet their needs. Most will require going further with a 3^rd part application like SSP Productivity.

You need to learn what Esri offers out-of-the-box so you can understand the blend of technology you’ll need to complement it. Prepare yourself to rely on new end user tools with a focus on configuration of the Esri stack in place of heavy product extensions that drive much of the business value. You also need to study what the Utility Network, ArcGIS Pro, and ArcGIS Enterprise will provide that may eliminate the need for some 3rd party tools and home-grown applications, thus simplifying your overall GIS enterprise stack provide greater return on investment.

This point is an oldie but a goodie. Most organizations data quality issues. Your database schema may be overcomplicated, or full of legacy stuff, and the authoritativeness may be fuzzy.

Maybe connectivity in the Geometric Network is lacking, or maybe it is perfect. When it gets migrated to the UN, you will likely to uncover some quality issue you weren’t aware of.

Note: this doesn’t mean that the data model or new technology is poorly designed (quite the opposite, in fact). It just provides a clearer, more detailed window into the gaps of your current data quality. This is a good thing! More accurate attribute and connectivity data will ease your transition to the Utility Network, but also elevate the value of your GIS investment to the entire organization. And with the business rules provided by the UN, it will be easier to maintain data quality going forward.

A worthy effort early on in your UN migration plan is to knock out the backlog and work through the lists of things to enter or update that haven’t been gotten to yet. It is possible for things like transformers to have wrong or no associations on the other side.

Integrations are going to be a central component of the planning and operation of the new system. A lot of thought must go into these things.

Start by listing all current integrations that plug into the GIS data. Divide this list by integrations that need to be rebuilt for the UN and integrations that are no longer needed given the expanded core functionality of the Esri core stack or heavier use of web applications. Now add integrations you want to add during this effort to get more value out of the GIS.

The GIS group often misses the smaller and less frequent duties they perform when discussing large and important components of the move to the UN like automated integrations. It is extremely useful to sit down and list off everyone who uses the GIS in a year’s time.

This could be an ad hoc request for data that someone is using to make a report. This could be a shapefile export for the 811 Call Before You Dig system. Maybe there are reports to a regulatory body that rely on information requested once per year to one person on the GIS team who pulls that information by a set of queries to tables you didn’t even know existed.

When making the move to the UN you must have a plan in place to do all the things you normally do, but in the new world with the new tools.

Often overlooked, you need to define a UN extent when staging the UN. This is the maximum extent you can place features. It’s a simple concept but you must put some thought into it. The key here is that it restricts the editable area for all the structure network and domain network features collectively.

Regardless of the number of polygons in the service territory class, the result in the UN is the extent of that class. Sometimes people thought that they wouldn’t be able to edit outside of the individual feature polygons (in the gap between them), but that is not the case. The ultimate resolution to that, which makes this much more flexible, is to introduce another polygon class with the individual polygons for each service area and then use an attribute rule to stop edits outside of those polygons. The entire extent is enforced by the UN, but the edits within the extent are enforced by attribute rules and constrained to actual service territory polygons which can be edited as things grow or shrink.

Assemblies come up again and again when planning for and implementing the move to the UN. The decisions of what should participate in an assembly will get a lot attention—and deserves it. But, in the course of adding new devices, junctions, or asset groups, the discussion will move back to assemblies. It is a good idea to move the assemblies workshop to the end of the queue and focus on getting the assets that make up those assemblies configured properly to begin with.

This advice can be applied to a lot of the workshopping and design during your planning phase and will depend on your organization. Try to identify things that are contentious or where different departments have different opinions or uses, and work on agreeing on these things only after other conversations have been had and the dependent modeling decisions have been worked out.

Thank you to David Miller, Isaac King, Jayson Troughton, and John Sieben for their contributions to this article.