Migrating to Esri’s Utility Network is rarely just a data migration. Here’s why the same four pitfalls keep showing up, regardless of the utility, the region or the size of the network.
Anyone who has looked seriously at migrating to Utility Network will probably agree on one thing early; it’s not easy and it’s not easy for a fairly specific reason. Most organisations aren’t starting from a blank canvas. The legacy GIS being migrated has usually been in service for ten, fifteen, twenty years and over that time it has accumulated historical data, custom schemas, business rules, relationships with other systems and a long list of workarounds nobody documented at the time.
So this was never going to be a simple lift from one system to another. It’s understanding what you’ve actually got, working out what it needs to become, transforming it, validating it and doing all of that in a way that’s repeatable rather than a one-off heroics project.
Why Utility Network and why now
Legacy GIS was largely built to answer “where is this asset”. Utility Network is built to answer “how does this asset connect, interact and behave.” That’s a genuinely different model, with richer support for connectivity, topology, associations, containment and network rules and it’s what lets GIS support field workflows, asset management and enterprise integration rather than just being a map.
The timing pressure is real too. Networks are getting more complex and interconnected, organisations are modernising legacy systems and GIS is increasingly expected to support operational and analytical decisions, not just display them. For the Esri crowd specifically, ArcMap has now officially retired.
But there’s a catch worth naming plainly, the smarter the target model, the more complex the migration. A valve in a legacy GIS might be a feature with a handful of attributes. In Utility Network, that same valve needs an asset type, an identity, connectivity, associations and a set of network rules that apply to it. You’re not just migrating data any more, you’re migrating the meaning and behaviour of the network.
Why one feature looks easy and a thousand don’t
Migrating a single feature looks simple enough. Legacy valve becomes Utility Network valve. But the questions stack up fast. Is the data complete and valid, where does it belong in the new schema, which asset group and asset type does it become, does anything else in the organisation rely on its existing ID, what does it connect to, is it contained within something, and do all of those relationships actually comply with the Utility Network rules.
One feature, that’s manageable. Multiply those questions across thousands or millions of interconnected assets and the migration stops being simple.
The four pitfalls that show up again and again
Across different utilities, different countries and different network types, the same four problems tend to surface.
- Data quality. Legacy data almost always has issues sitting quietly in it for years, things like inconsistent codes, missing values, duplicate IDs, invalid geometry. Migration has a habit of finding all of them, which is actually a useful side effect rather than a disaster, provided you catch it before it reaches production
- Schema mismatch. Legacy and Utility Network models are rarely a one-to-one match. Ten legacy feature classes might become three Utility Network classes through asset groups and asset types, which means you’re translating meaning, not just moving fields
- IDs and relationships. If assets reference each other, those relationships need to survive the migration even as identities change. A source valve ID becoming a new GlobalID is fine, as long as everything that referenced the old ID knows about the change. Break that chain and the relationship breaks with it
- Topology and validation. Getting every record successfully loaded into the database doesn’t mean the network has successfully migrated. It still needs to validate, connect, trace, recognise subnetworks and honour the rules you’ve configured. Data loaded and network migrated are two different things, and it’s worth not confusing them
None of this makes Utility Network migration unmanageable, but it does explain why so many projects underestimate it going in. Part 2 of this blog post will explore how it all comes together in practice.
Further reading
Join FME Accelerator, our free, instructor-led 90 minute introduction to FME – Register Now