Which Utility Network data model should you start with?

One of the most common questions we hear from electric utilities is: "Which data model should we start with?"

The short answer is: it doesn't matter as much as you think. Here's why.

The platform is the point

The most important thing to understand about the Utility Network is that Esri built it, first and foremost, as an extraordinarily flexible and configurable platform. There are thousands of ways an organization could configure it to meet their specific needs — which, early on, turned out to be part of the problem. Too many options can be paralyzing.

To help, Esri began offering Foundation Packages for electric, gas, water, stormwater, waste, and telecommunications networks. Each package starts from the same underlying platform and arrives with a set of pre-applied configurations — asset groups and asset types, attribute domains, network rules, subnetwork definitions, and a baseline symbology — designed to accelerate your migration. Think of them as a well-considered starting point, not a finished product.

That framing is the whole game. A Foundation Package isn't a different thing than the Utility Network; it's the Utility Network with several hundred decisions already made for you. Some of those decisions will fit your utility perfectly. Many were made on behalf of a hypothetical average utility that doesn't exist — not in your service territory, not with your equipment, not under your operating rules.

The reason is simple. Every default you inherit and don't actively examine becomes a constraint your migrated data has to bend to fit. When that bend doesn't match how your network was actually recorded over the last few decades, the gap doesn't disappear — it turns into reconciliation work, mid-project scope changes, and editors quietly working around a model that fights them.

What about partner models?

As the market has matured, Esri product partners like Schneider Electric and SSP have introduced their own offerings — asset packages. It's worth understanding what these actually are: not distinct products, but a partner's own configurations applied to the same Esri platform, typically designed to align with their commercial offerings such as design tools and ArcGIS Pro add-ins.

The practical difference between an Esri Foundation Package and a partner asset package is roughly one to three hours of configuration changes. That's it.

That number surprises people, because the packages are marketed as if they were fundamentally different products. They aren't. Strip away the branding and you're looking at the same asset classes, the same network topology engine, and the same rules framework underneath. The partner has nudged a set of defaults and bundled the result with the tools they sell. Useful — but not a different foundation.

They're not different products. They're different starting configurations of the same platform.

What a "data model" really is

This matters because it reframes the decision. You are not choosing a destination you'll be locked into. You're choosing how many of the pre-made decisions happen to line up with where you're already headed — which shaves a few hours off the front of the project and changes nothing about the months of configuration that follow.

So which should you choose?

Start with whichever model gets your project moving the soonest and most smoothly.

• If you know you're planning to invest in ArcFM XI, it probably makes sense to begin with the ArcFM Asset Package.
• Otherwise, the Esri Foundation Package is a perfectly solid foundation — and you can adapt it as your needs evolve.

flowchart TD
    A[Which model<br/>do we start with?]:::flow --> B{Planning to invest<br/>in ArcFM XI?}:::flow
    B -->|Yes| C[Start with the<br/>ArcFM Asset Package]:::good
    B -->|No| D[Start with the Esri<br/>Foundation Package]:::good
    C --> E[[Configure to your data<br/>and operating environment]]:::human
    D --> E
    E --> F[Implement]:::flow

Either path leads to the same place: a package you reshape around your data. The starting choice is small; the configuration work is where the project actually lives.

You'll change it either way

Regardless of which model you select, you will make changes to it during implementation. The teams behind these packages have done an excellent job creating configurations that work for a broad, global audience — but that breadth is also a limitation. Elements that serve utilities in other regions, or with different operating environments, may not serve yours.

There are certain attributes and configurations worth preserving. Beyond those, your organization should lean into the platform's configurability and shape it around the data and operational environment you've been building for decades.

What you'll actually end up changing

In the abstract, "you'll make changes" is easy to nod along to and easy to underestimate. Concretely, the work tends to cluster in a few predictable places — and it's the same list whether you started from the Esri package or a partner's:

• Asset types and groups — adding the equipment your utility actually runs, retiring the classes you'll never use, and splitting or merging categories so they match how your crews and records describe the network.
• Attribute domains — replacing globally-flavored coded-value lists with the values your data already uses, so you're not remapping every record to a vocabulary nobody in your shop recognizes.
• Network rules — tightening what's allowed to connect to what, so the model reflects your engineering standards rather than a permissive global default.
• Subnetwork and tier definitions — aligning the network's notion of sources, controllers, and tiers with how your system is actually fed and operated.
• Symbology and field visibility — making the map and the editing experience legible to the people who'll live in it every day.

None of this is exotic. It's the ordinary, decades-deep knowledge your organization already holds about its own network, finally being written into the model instead of being worked around it. The package gave you a running start; this is where you make the model tell the truth about your system.

Your data. Your model.

So when you ask which data model to start with, the honest answer is: start with whichever one gets you moving, then make it yours. The packages are a head start, not a verdict. The platform was built to be shaped — and the organization best positioned to shape it around your network is the one that's been running it all along.

The teams that struggle with Utility Network migrations are rarely the ones that picked the "wrong" package. They're the ones that treated the package as the answer and let its defaults quietly stand in for decisions they never made. The teams that do well treat the package for what it is: a credible first draft, and then they put in the work to make it theirs.

Pick the model that gets you to the start line fastest. Spend your real energy on the part that was always going to define the project — turning a generic configuration into an accurate, operable picture of your network.

Working through a Utility Network migration and weighing which model to start from? The choice matters less than what you do with it — and keeping your data correct, attributable, and audit-ready as you reshape the model is where the real work is. Talk to us about making the model yours.