When a water utility needs to locate a valve, respond to a service issue, plan capital work, or update network records, GIS is part of the operating environment. At mature utilities, it supports engineering, field operations, customer service, asset management, emergency response, and leadership decisions.
That makes modernization more than a software upgrade. Esri positions ArcGIS for water utilities as a system of record, a system of engagement, and a system of insight: a platform for maintaining authoritative information, connecting people and workflows, and supporting analysis and decisions. The modernization question is therefore not simply where GIS should run or which product should be deployed next. It is whether the utility can trust the data, depend on the workflows, and operate the platform to the level the business requires.
This guide focuses on the decisions behind that outcome: what a modern water GIS should do, where environments break down, how GIS supports daily operations, which architecture and operating choices matter most, and what utilities should resolve with a modernization partner over the next 12 months.
1. What Your GIS Should Be Doing
A modern water GIS should provide an authoritative spatial foundation that people can use in their day-to-day work. Pipes, valves, hydrants, meters, service connections, facilities, pressure zones, work areas, and customers are all spatially related. The value is not the number of maps produced; it is whether those relationships can be maintained accurately, accessed by the right people, and used to make operational decisions.
For the office, that means engineering, planning, customer service, and operations teams can work from current infrastructure information without creating parallel records to compensate for gaps. For the field, it means crews can access the network context they need, capture observations at the point of work, and return those updates to a governed enterprise record rather than a separate handoff.
For leaders, GIS should also support insight: where maintenance demand is concentrated, where assets or customers may be affected by an event, where data quality needs attention, and where capital or operational priorities intersect. The underlying requirement is trust. A sophisticated application cannot compensate for network information that users do not believe.
Evidence in practice: Rural Lorain County Water Authority replaced a paper-based meter replacement process with digital GIS workflows. Esri reports that the utility increased its average meter changeouts from 15–20 per day to about 70 per day. Data for 1,000 meters that once took hours to enter could be loaded in about 15 minutes, and the utility reported $1.5 million in savings by completing the work in-house. These results are specific to that program, but they demonstrate that GIS value can be measured through operational throughput and data handling, not just mapping output.
2. Where Water GIS Environments Break Down
Water GIS environments typically become difficult to manage because of accumulated complexity rather than a single failure. New applications are added, asset information spreads across systems, integrations grow, users create workarounds, and the operating burden increases. Providence Water and Central States Water Resources both describe modernization programs that began with long-standing architectures, fragmented information, or business processes that had outgrown the existing environment.
The symptoms are often visible before a major outage occurs. The same asset may be represented differently across GIS and another system. Field observations may return through paper, photos, email, or spreadsheets. Platform administration may repeatedly displace higher-value GIS work. Application and integration dependencies may be poorly understood until an upgrade is planned. Each of these conditions creates a different risk, but they share one effect: users have to compensate for the system instead of relying on it.
Data quality belongs in the same discussion. Utility Network supports rules, connectivity, tracing, and validation, but those capabilities do not eliminate the need for accurate source data, clear ownership, editing standards, and stewardship. Modernization therefore needs to address data quality and the processes used to maintain it, not just the underlying platform.
A useful current-state assessment should cover infrastructure, data, applications, integrations, governance, security and resilience, and business requirements. The goal is to identify the sources of operational risk, the workflows most dependent on GIS, and the dependencies that must be preserved or redesigned before implementation begins.
Areas to understand before modernization
A current state assessment should show what the environment can support today and what could create operational risk during change.
3. GIS in Daily Operations
The strongest test of a GIS environment is how well it supports routine operations and responds when conditions change.
During a main break or service event, teams may need to locate assets, understand connectivity, identify isolation points, assess which customers may be affected, and coordinate field response. During planned maintenance, they need asset history, inspection information, location context, and a reliable way to return changes to the enterprise record. During capital planning, they need to understand where asset condition, demand, risk, and investment priorities intersect.
Field workflows are particularly important because they connect the physical network to the enterprise record. Some county authorities documented a progression from paper forms, spreadsheets, and disconnected processes to mobile applications, dashboards, and automated updates that improved visibility between field and office teams. Another water-utility modernization similarly connected mobile fieldwork with a Utility Network-based master topological database and enterprise systems.
Modernization also has to preserve the business processes that already depend on GIS. Providence Water kept its enterprise GIS in place to support engineering, maintenance, customer service, and emergency response while replacing ArcMap and the geometric network with ArcGIS Pro and Utility Network. Planning, testing, data validation, integration work, and business continuity were treated as parts of the same program.
The practical question is not whether a new platform can perform a function in isolation. It is whether an end-to-end workflow works: Can a crew access the right asset information? Can a field update return to the right record? Can work management or customer service systems use the information they need? And can the utility continue operating while changes are introduced?
GIS in the moment of work
The value of GIS is visible when authoritative information remains usable across the full operational workflow.
4. The Decisions You'll Face
Modernization is a sequence of operating and architecture decisions. Four deserve particular attention because they shape the risk, scope, and long-term support model.
4.1 Where should the platform run?
Start with requirements, not a default preference for cloud or on-premises infrastructure. Esri's ArcGIS Architecture Center recommends aligning deployment choices with organizational IT principles and considering reliability, scalability, security, service levels, and the balance of responsibility between the organization and its providers.
The same principle applies to reliability. Esri's Well-Architected Framework ties reliability to business criticality and user workflows. Not every system needs the same level of redundancy, but critical workflows need clearly defined expectations for availability, monitoring, backups, disaster recovery, and recovery time. Cloud can support those objectives, but moving to the cloud is not, by itself, modernization.
CyberTech's published Central Arkansas Water (CAW) case provides one example. CAW moved from an aging on-premises foundation to a fully managed ArcGIS Enterprise platform on Microsoft Azure. The number of active GIS users grew from 75 before migration to more than 200, while availability remained at 99.9 percent across the managed environment.
Two decisions that should not automatically become one
Where the platform runs and when the network model changes can be coordinated, but they do not have to move at the same time.
| Deployment | Existing network model retained | Utility Network as target |
|---|---|---|
| Cloud or managed environment | Infrastructure modernization can proceed while the network model remains unchanged. | Infrastructure and network-model change occur together, increasing the amount of testing and change management required. |
| On-premises environment | Hosting and network model remain in place; modernization can still focus on supported versions, high availability, monitoring, recovery, patching, and capacity. | The network model changes while hosting remains on-premises; infrastructure requirements still need to be reviewed independently. |
4.2 Utility Network: whether, when, and how far
Utility Network should be treated as a network-management and workflow decision, not simply as a data-conversion exercise. Providence Water's migration included modernizing ArcGIS Enterprise, adopting ArcGIS Pro and Utility Network, validating data, updating applications, preserving integrations, and maintaining business continuity.
The implication is straightforward: readiness depends on the source network model. Utilities need to understand data quality, tracing and validation requirements, applications that depend on the network, integrations that must remain intact, user workflows that cannot be interrupted, and the testing required before cutover. Platform modernization and Utility Network migration can be coordinated, but they do not have to be treated as a single decision or implemented at the same time.
Central Arkansas Water (CAW) illustrates how the two decisions can be sequenced. CAW first moved from an aging on-premises ArcGIS Server deployment to a cloud-hosted ArcGIS Enterprise environment managed by CyberTech, completing the migration and a geodatabase upgrade in four months. With that platform in place, the utility is now completing its ArcGIS Utility Network implementation for its water distribution assets.
4.3 Who should run the platform?
The operating model should assign responsibility at each layer. Who owns the cloud account or data center? Who administers ArcGIS Enterprise? Who monitors platform health? Who patches and upgrades it? Who manages backups, tests recovery, handles incidents, and approves production changes? Esri's reliability guidance emphasizes tested backups, clear escalation paths, and an understanding of the workflows users rely on, rather than focusing only on whether a service responds to a health check.
CyberTech's public cases show that this responsibility split can vary. In Portsmouth, the city retained responsibility for the AWS infrastructure while CyberTech operated the ArcGIS environment through MACS Advanced. The published case reports an upgrade from ArcGIS Enterprise 10.9.1 to 11.5, automated daily backups, approximately 50 GIS users, 640 ArcGIS services, and 99.88 percent availability since go-live.
At Veolia, CyberTech managed both ArcGIS Enterprise and the underlying AWS infrastructure within Veolia's cloud environment. The engagement includes production and staging environments, daily ArcGIS backups, monitoring, and change control. The case reports that recurring Portal outages were eliminated within two months of onboarding. The point is not that one model is universally better. The point is that ownership and accountability must be explicit.
4.4 What connects to what?
Enterprise integration is primarily an ownership decision. Providence Water's modernized environment keeps GIS authoritative for the physical water network, Cityworks for work management, and SpryPoint for customer and billing information, with integrations connecting the workflows that cross those boundaries. Gruppo Tea established GIS as the master topological database while integrating SAP ERP and Salesforce into the operating model.
For any integration, the utility should define which system owns each important record or attribute, the direction in which updates move, how conflicts and failed transactions are handled, what security controls apply, and who resolves exceptions. Without those decisions, integration can automate inconsistency as easily as it automates work.
Esri lists CyberTech's Unity Engine as a partner solution for bidirectional synchronization of asset data and geometry between enterprise asset management systems and ArcGIS, for use in the water and wastewater industries.
Loudoun Water provides one example of that capability in practice. The utility uses ArcGIS as the system of record for linear assets and SAP for asset and maintenance management, each in its own Microsoft Azure environment. CyberTech replaced a custom integration with its Asset Mapper and Unity Engine to connect the three cloud environments. The solution hosts configuration data, not business data.
5. Choosing a Partner and the Next 12 Months
A modernization partner should be evaluated against the environment the utility needs to support. Credentials help establish capability, but they are not a substitute for evidence of successful delivery. Esri's current Partner Network profile lists CyberTech as a Platinum Partner and identifies specialties in ArcGIS Cloud Services, Network Management, State and Local Government, and Imagery. It also lists water, wastewater, and stormwater among the industries CyberTech serves.
Beyond credentials, ask for evidence from comparable environments and make responsibilities explicit. Can the partner explain the current-state dependencies before proposing a target architecture? Can it show how data validation, applications, integrations, testing, cutover, and operations will be handled? Can it define what the utility will own after go-live and what the partner will continue to operate? Can it show how backup, recovery, escalation, and production changes are governed?
The next 12 months do not need to follow a fixed quarterly template. Scope, data quality and readiness, procurement, integrations, testing, and organizational readiness will shape the sequence. What matters is that the utility resolves the decisions that determine whether modernization can move safely into production.
What should be resolved over the next 12 months?
- Establish the current-state baseline. Document the ArcGIS environment, data quality, applications, integrations, business-critical workflows, platform dependencies, security requirements, and recovery expectations.
- Set authoritative ownership. Define which system owns each critical class of data, how updates move between systems, and how exceptions are resolved.
- Choose the target architecture. Decide where the platform should run and what reliability, monitoring, backup, recovery, and change-management practices are required.
- Make the Utility Network decision. Confirm whether Utility Network is in scope now, at a later stage, or not at all, based on data readiness, workflow requirements, integrations, testing, and organizational capacity.
- Define the operating model. Clarify responsibilities for GIS, IT, cloud infrastructure, service providers, support, escalation, and knowledge transfer before the production handoff.
- Agree on outcomes. Choose measures tied to the business case, such as availability, recovery performance, field adoption, data-quality exceptions, workflow cycle time, network validation results, application usage, or reductions in manual handling.
Conclusion
For water utilities, GIS modernization is ultimately about operational confidence. The platform must maintain trusted network information, support field and office workflows, preserve the enterprise connections the utility depends on, and meet the reliability expectations of the services built on it.
The right starting point is not a migration date or a preferred deployment model. It is a clear view of the current environment, the workflows that must remain available, the data users must trust, and the outcomes the utility needs to improve. From there, cloud, Utility Network, integration, managed services, and partner selection become connected decisions rather than isolated technology projects.
