The riskiest bill run is the first one
The meter data management system sits between AMI and CIS. Almost every bill a utility sends depends on it. So when the time comes to replace it, because the vendor is ending support, the AMI network is being refreshed, new rates demand more than the old system can do, or volumes have simply outgrown it, the program carries a risk that few other IT projects share.
That risk has a date on it: the first bill run on the new system. If determinants come out different from what the old system would have produced, customers get wrong bills, call volumes rise, and regulators take notice. Too many replacement programs manage that moment with a cutover weekend, a test plan built on sampled data, and a great deal of hope.
There is a better way to approach it. Prove the new system bills correctly before it becomes the system of record, and make the cutover itself a rehearsed, reversible event.
Why MDMS replacement is hard
Legacy behavior is rarely documented. A long-running MDMS carries years of configured rules, workarounds and special-case handling. Some of it was deliberate. Some of it was a fix for a problem nobody remembers. Very little of it is written down.
Matching is not the same as correct. Two systems can disagree for good reasons and bad ones. Sometimes the new system has a configuration gap. Sometimes the old system has a defect the utility has billed with for years. A program that treats every difference as a new-system bug will either stall or quietly copy the legacy system's mistakes.
History has to come across intact. Rebills, disputes and regulatory inquiries reach back into prior cycles. Historical reads, estimates, edits and their audit trail must survive the move, and the utility cannot stop billing while they are moved.
Test data is not production. Synthetic and sampled data are valuable, but they miss the long tail: the meter exchanged mid-cycle, the account on a legacy special contract, the head-end that resends a day of reads. Those cases only show up at production volume.
Integrations multiply the moving parts. Head-end systems, CIS, outage management and analytics all have to point at the new platform, and each has its own timing and failure modes.
Principles of a cutover with proof
Run in parallel on real data. Shadow reconciliation means the new platform processes the same production feed as the legacy system, cycle after cycle, while legacy remains the system of record. Determinants from both are compared account by account.
Explain every difference. Parity is not declared when most numbers match. It is declared when every difference has an explanation and an owner's decision: a new-system issue to fix, a legacy defect to correct deliberately, or an expected difference from an intentional change. Each decision is documented, so billing leaders and regulators can see what changed and why.
Gate the cutover on evidence. Readiness gates turn "we think we're ready" into explicit criteria that billing, IT and operations sign off on together. Reconciliation results, integration tests, performance under production volume and operational readiness all have to pass.
Verify fast after the switch. Smoke tests run immediately after cutover to confirm the end-to-end path works: reads flowing in, VEE running, determinants certified, CIS receiving and acknowledging.
Rehearse the way back. A rollback runbook is written, rehearsed and ready before cutover day. Most programs never need it. Every program should have it.
Migrate history with its audit trail. Historical data should move without downtime for billing, and it should arrive with its full audit trail, so a rebill for a prior cycle works the same way after cutover as it did before.
Hand off operations on purpose. The team that will run the platform day to day needs runbooks, monitoring and hands-on time before they own it.
What it looks like in practice
Shadow reconciliation is built into the billing side of the Grid Data Management Platform. It is designed for exactly this moment: proving billing parity against a legacy system before cutover. The same platform then serves as the system of record, with certified determinants, CIS export and acknowledgment, rebill, dispute and hold, and an immutable audit trail. Our platforms support more than 15 million meters and over 1 billion interval reads per day in production.
PeriNimble's services team works alongside the utility through the replacement. We run MDMS upgrades and managed operations, integrate CIS, AMI head-end, SAP and Oracle systems, and deliver zero-downtime data migrations with full audit trails. Every deployment follows the same discipline: readiness gates, smoke tests, a rollback runbook and a planned operations handoff.
Illustrative example (hypothetical)
Imagine a hypothetical mid-sized utility replacing an MDMS that is reaching end of support. For several bill cycles, both systems process the same production reads. After each cycle, the reconciliation shows which accounts match and which differ.
One cluster of differences, on commercial demand accounts, traces to a rounding behavior in the legacy system. Billing leadership reviews it and decides to keep it, so it is configured deliberately in the new platform and documented. Another cluster traces to how the legacy system handled meter exchanges in the middle of a cycle. That one turns out to be a long-standing legacy defect. Leadership chooses to correct it, documents the change, and prepares customer service for the handful of accounts affected.
Once every difference is explained across consecutive cycles, the readiness gate is met. On cutover, history migrates with its audit trail while billing continues. Smoke tests pass. The rollback runbook, rehearsed the month before, stays on the shelf. The operations team, trained during the parallel run, takes ownership with the runbooks and monitoring they have already used.
The first bill run on the new system is uneventful. That is the goal.
Questions to ask any MDMS vendor or integrator
Can your platform run in parallel with our legacy MDMS on production data and compare determinants account by account?
How are differences classified, decided and documented?
What readiness gates do you use, and who signs off?
What do your post-cutover smoke tests cover?
Is there a rollback runbook, and will we rehearse it before cutover?
How is historical data migrated, and does its audit trail come with it?
Can billing continue during migration?
How does operations handoff work, and when does our team start using the tools?
Replacing the system, not the confidence
An MDMS replacement is a large program, but the question that matters most is simple: will the first bill run be right? Shadow reconciliation, readiness gates and a rehearsed rollback turn that question from a hope into something you can show your executives, your billing team and your regulator before the switch.
Learn more about the Grid Data Management Platform at perinimble.com/grid-data-management/, or talk with our team about your replacement program at perinimble.com/contact/.