The question that stops more water utility software decisions in their tracks is not about price or features. Itis the data question: What happens to everything we have built up over the last fifteen years? The billing histories, the customer accounts, the meter reads that go back to 2009, the service line records that four different field supervisors have maintained in four different places. Where does it go? What if something breaks?
This guide answers that question at the level of detail your IT Director and billing supervisor will need before your first vendor conversation. If you have already read the overview of the migration process — what it involves, how long it takes, and how to evaluate vendors — this is the document that goes deeper on the one part of migration that generates the most anxiety: your data.
What Is Water Utility CIS Data Migration?
Water utility CIS data migration refers to the structured process of extracting, cleaning, mapping, validating, and loading all operational data from a legacy customer information system into a modern cloud platform. This includes customer account records, billing history, meter reads, service orders, payment histories, deposit balances, and service line records. No historical data is lost in a well-executed migration — it is systematically transferred and validated before go-live.
Before you can understand what migrates, you need a clear inventory of what is actually in your legacy system. Most Utility Directors are surprised by the full scope — and most IT Directors have never catalogued it end to end. A typical water utility CIS holds eight to twelve distinct data categories, each with different volumes, formats, and migration complexity.
The table below maps what a legacy CIS typically contains, the format challenges each category presents, and the migration complexity rating — low, medium, or high — based on how often each category causes delays in practice.
The highest-complexity categories, service order history, service line records, and compliance and inspection records, are the ones most likely to be partially or entirely outside your CIS. A utility that has been running for thirty years will often have data scattered across three or four systems and a filing cabinet. Before migration begins, your water utility management software partner's first task is finding all of it.
Not everything in your legacy system needs to live in the new one. Deciding what migrates, what gets archived for compliance access, and what can be safely retired is one of the most important planning decisions in the migration process and one most utilities do not make explicitly enough.
Archived data does not disappear, it is exported in a searchable format and retained in accordance with EPA Safe Drinking Water Act requirements and your state PUC's data retention rules. Your compliance team should confirm retention schedules before migration so nothing is retired prematurely. The SMART360 data migration service includes an archival export as standard, ensuring your compliance posture is not disrupted during the cutover.
Data quality issues in legacy utility systems are not hypothetical risks. They are the rule, not the exception, particularly in systems that have been running for ten or more years without a major database overhaul. The AWWA's utility benchmarking data consistently identifies data quality as the primary cause of billing exception rates above 5% in legacy CIS environments.
Here is what dirty data actually looks like in practice, and why each type matters to your migration:
Archived data does not disappear, it is exported in a searchable format and retained in accordance with EPA Safe Drinking Water Act requirements and your state PUC's data retention rules. Your compliance team should confirm retention schedules before migration so nothing is retired prematurely.
Data quality issues in legacy utility systems are not hypothetical risks. They are the rule, not the exception — particularly in systems that have been running for ten or more years without a major database overhaul. The AWWA's utility benchmarking data consistently identifies data quality as the primary cause of billing exception rates above 5% in legacy CIS environments.
Here is what dirty data actually looks like in practice, and why each type matters to your migration:
Common Dirty Data Scenarios in Legacy Utility CIS Systems
1. Duplicate customer accounts. A customer moves, the old account is not cleanly closed, and a new account is opened at the same address. The legacy system holds both. Without deduplication before migration, the new system inherits the same ambiguity and the first billing run surfaces it as an exception.
2. Meter read gaps. A meter was replaced three years ago, but the read sequence in the CIS was never reconciled to the new meter ID. The read history has a gap or worse, a sequence of estimated reads that were never corrected. Migrating an uncorrected sequence produces incorrect billing history in the new system.
3. Billing history in proprietary formats. Legacy CIS platforms from the late 1990s and 2000s stored billing data in formats specific to that vendor's architecture. These formats are not readable by modern systems without a translation layer. Migration teams that have not migrated from your specific legacy platform before will spend weeks reverse-engineering the data structure, adding scope and cost.
4. Service line records in spreadsheets. The EPA's Lead and Copper Rule revisions require utilities to maintain a complete, reportable service line inventory. Many utilities hold this data in GIS layers or Excel files maintained by field supervisors, separate from the CIS entirely. When a field supervisor retires, the continuity of those records becomes a compliance liability. Migration is the moment to consolidate service line data into the CIS where it belongs.
5. Deposit balances on closed accounts. Deposits from accounts closed five or more years ago may still be sitting in the system, unclaimed. These must be handled according to your state's unclaimed property rules, migrating them blindly creates a financial reconciliation problem in the new system from day one.
The data cleanup phase, where these issues are identified and resolved, must happen before extraction, not after. Migration teams that discover dirty data mid-migration face a choice between delaying go-live to clean it or going live with known data quality problems. Neither is acceptable. Front-loading data quality work is the single most effective way to protect the 12–24 week implementation timeline.
Data mapping is the technical process of defining exactly how each field in your legacy CIS translates to its equivalent field in the new system. Every piece of data your utility holds has a structure — a field name, a data type, a relationship to other fields and that structure is different in every CIS platform.
When your migration team maps your data, they are building a translation layer. A field called "ACCT_NO" in your legacy system may map to "account_id" in the new customer information system schema. A field called "READ_DT" maps to "meter_read_date." Simple enough when the structures are similar. It becomes complex when your legacy system combined what the new system separates — a single "BILL_AMT" field that the new system splits into base charge, consumption charge, and tax — or when your legacy system stored data in a format the new platform does not recognize.
Three factors determine how straightforward data mapping will be for your utility:
1. How closely your legacy system's data structure matches the new platform's schema. Platforms built on modern relational database standards map more cleanly than platforms built on proprietary 1990s architectures.
2. How many custom fields your utility added to the legacy system over the years. Custom fields require individual mapping decisions — they do not map automatically.
3. Whether your migration partner has mapped from your specific legacy platform before. A team that has migrated twenty utilities from the same legacy CIS already has the field map. A team doing it for the first time starts from scratch.
Data validation is the process of confirming that what arrived in the new system matches what was in the legacy system, with the right values, in the right relationships, for the right accounts. It is the sign-off gate that stands between a test migration and a live go-live.
A complete data validation checklist for a water utility CIS migration should cover the following seven checkpoints. Each must pass before the legacy system is decommissioned:
Total receivables in the new system match total receivables in the legacy system within an acceptable variance threshold (typically < 0.1%). Any variance must be explained and resolved.
A sample of 100+ individual account balances is pulled from both systems and compared. Balance discrepancies above a defined threshold are investigated before go-live.
For each meter ID migrated, the read sequence is checked for gaps, duplicates, and chronological consistency. Estimated reads flagged in the legacy system are carried over with the same flag in the new system.
All service orders with open or in-progress status in the legacy system are confirmed present and correctly assigned in the new system. No open work order should be lost during migration.
Payment totals for a sample of accounts are cross-checked against billing records. Deposit balances are verified account by account for all active accounts.
Each account's active rate schedule in the new system is confirmed to match the legacy system. For multi-rate utilities, rate code mapping is validated against the full rate schedule library.
If service line data has been consolidated from outside sources (GIS, spreadsheets) as part of the migration, completeness is verified against the pre-migration source files and confirmed against EPA service line inventory requirements.
This checklist is used during the parallel running period — where both systems operate simultaneously — before the final cutover is authorized. It is not a one-time check. Billing total reconciliation and account balance cross-checks run after each billing cycle during the parallel period. Only when all seven checkpoints have passed for a minimum of two consecutive billing cycles should the legacy system decommission be scheduled.
Most migration failures are not technology failures. They are data failures - problems that existed in the legacy system before migration began and were not caught before the cutover. The four data risks below account for the majority of migration delays and post-go-live issues in utility software implementations.
The common thread across all four risks is timing. Each one is preventable when it is caught before extraction. Each one is expensive when it is discovered after go-live. The SMART360 implementation process front-loads risk identification in the discovery and scoping phase, so that data quality issues are resolved as planned scope rather than mid-migration surprises.
SMART360's SMART360 data migration service is a managed service included as standard in every implementation, not a billable add-on. Here is what that means in practice for your utility's data:
• Your dedicated implementation team performs the data audit, builds the field map, executes the cleanup, runs the test migration, and leads the validation process. Your team's role is operational input and sign-off — not technical execution.
• Pre-built data mapping templates for common US utility CIS platforms reduce the field mapping phase from weeks to days for utilities on supported legacy platforms.
• All ten data categories in the table above are included in migration scope. Service line data consolidation from external sources — GIS, spreadsheets, paper records — is handled as part of the data cleanup phase.
• The parallel running period is a mandatory part of the SMART360 implementation methodology. No go-live is authorized until all seven validation checkpoints have passed for a minimum of two consecutive billing cycles.
• Post-go-live, SMART360 operates as a cloud-native SaaS platform — no on-premise server infrastructure means no data held in aging hardware, no database licensing to renew, and no single-point-of-failure server room dependency.
All operational data transfers during a utility CIS replacement: customer account records, 24+ months of billing history, meter read sequences, service orders, payment records, deposit balances, service line records, and rate schedule assignments. Your migration partner begins with a data audit to catalogue every dataset in your legacy system — including data held outside the CIS in GIS layers, spreadsheets, or paper records — and confirms the full scope before migration begins.
The data audit phase — conducted before extraction — will tell you. Common red flags include: billing exception rates above 5% in your current system, service line records held outside the CIS, meter ID mismatches from prior replacements, and accounts with missing or inconsistent address data. None of these disqualify a migration — they define the cleanup scope. A migration partner's job is to identify these issues early, not discover them at go-live.
Not with a managed migration service. Your IT Director's role is to provide access to the legacy system, confirm the data inventory, and sign off on validation results. The technical extraction, mapping, cleanup, test migration, and loading are handled by your migration partner. For utilities running lean IT teams of one or two people, this is a standard delivery model — not an exception.
Closed account billing history is handled in one of two ways: migration to the new system for accounts closed within the active window (typically 24 months or as defined by your retention policy), or archival export for accounts closed beyond that window. Archived records are retained in a searchable format per EPA Safe Drinking Water Act requirements and your state PUC's data retention rules. Your compliance team should confirm retention schedules before migration to ensure no records are retired prematurely.
For a utility with reasonably well-maintained data, data cleanup typically adds two to four weeks to the discovery phase — it does not extend the overall 12–24 week migration window. Utilities with significant data quality issues (heavily fragmented service line records, large volumes of duplicate accounts, or billing history in unreadable legacy formats) may see cleanup extend by four to eight additional weeks. Identifying these scenarios early in the data audit is exactly why the audit is the first step, not an afterthought.
