Upgrading from AMR to AMI involves six implementation steps: assessing your current AMR infrastructure and upgrade path, selecting AMI hardware and head-end software, configuring the MDM for 15-minute interval data, running a parallel billing period with AMR and AMI meters active simultaneously, validating AMI billing accuracy before decommissioning AMR, and transitioning customer-facing systems to interval data feeds. The critical difference from a greenfield AMI deployment is that your utility continues operating on AMR throughout the upgrade, which requires the MDM to manage two read types in parallel during the transition period. The SMART360 meter data management platform handles AMR and AMI reads in a single system, which simplifies the parallel-billing phase of any AMR-to-AMI upgrade.
Three operational pressures are driving AMR-to-AMI upgrades among small-to-mid-sized US utilities in 2025 and 2026. The first is rate design: time-of-use and demand-charge rate structures require 15-minute interval data to calculate accurately, and AMR's single billing-period read cannot support them. The second is non-revenue water detection: interval analytics at the distribution zone level requires continuous reads, which AMR does not provide. The third is infrastructure age: first-generation AMR transmitters deployed in the 2000s and 2010s are approaching or past vendor support end-of-life, which makes a hardware refresh decision unavoidable.
Utilities that are replacing aging AMR hardware have a choice between like-for-like AMR replacement and upgrading to AMI. The hardware cost difference between new AMR transmitters and AMI-capable endpoints has narrowed considerably. The additional investment in AMI head-end software and MDM configuration is what makes the total project cost higher, not the meter hardware itself.
For a view of where the AMR-to-AMI transition fits in the broader metering landscape and what data capabilities the upgrade enables, utility metering trends for 2025 and 2026 covers the trend drivers and the capabilities that interval data unlocks.
The upgrade path from AMR to AMI differs significantly depending on which AMR technology your utility currently operates. This assessment should be the first step in any upgrade planning process.
Fixed-network AMR is the shortest upgrade path. The fixed collector infrastructure that your current AMR system uses for read collection is architecturally similar to the fixed network an AMI system needs. In many cases, fixed-network AMR collector hardware can be upgraded or supplemented with AMI-capable units rather than replaced entirely. The meter endpoints require replacement (AMR transmitters are one-way; AMI endpoints are two-way), but the backhaul infrastructure may be partially reusable.
Drive-by AMR requires a more significant infrastructure investment. Drive-by systems have no fixed collector network. Converting to AMI means installing fixed collectors throughout the distribution area, which is a capital project with site selection, permitting, and installation timelines. Drive-by AMR utilities typically plan AMI conversions over 12 to 24 months to accommodate the infrastructure buildout.
Walk-by AMR has a similar infrastructure gap to drive-by. Walk-by systems depend on handheld receivers with no fixed network. The upgrade requires the same fixed collector deployment as drive-by conversion.
For a full description of the three AMR technology types and their characteristics, automatic meter reading for water utilities covers the differences and what each type looks like operationally.
Does your current MDM platform support 15-minute interval data storage and VEE at AMI data volumes, or was it configured for AMR scalar reads only?
Before any AMI hardware ships, five conditions must be in place or planned for the upgrade to proceed without billing disruption:
AMR-to-AMI upgrades that treat software selection as a secondary decision after hardware procurement typically encounter integration problems during commissioning. The correct sequence is to select and configure the AMI software stack before hardware deployment begins, so that the first meters deployed are reporting to a configured system rather than an unconfigured one.
The software decisions that must be made before meter deployment:
Head-end software: Most AMI hardware vendors supply head-end software bundled with the meter endpoints. Evaluate whether the head-end exports in an open format your MDM accepts (ANSI C12.22, XML, or CSV) before committing to a hardware vendor. Proprietary export formats create vendor lock-in and middleware dependency.
MDM configuration: If your existing MDM handles the upgrade (rather than being replaced), it requires interval data configuration before AMI meters go live. This includes enabling interval storage at 15-minute resolution, configuring VEE rules for interval reads, and setting up the data delivery pipeline to the CIS.
Customer portal: If your utility has a self-service customer portal, determine whether it supports interval usage display. Customers on AMI will have data available for near-real-time usage display; a portal that only shows billing-period summaries does not use that data.
For a full evaluation framework covering AMI software components and vendor selection, AMI software for utility metering programs covers the five stack components and eight evaluation criteria.
The MDM configuration change between an AMR deployment and an AMI deployment is more significant than most utilities anticipate at project planning. AMR MDM configuration stores one value per meter per billing period. AMI MDM configuration stores 2,880 values per meter per month at 15-minute resolution.
That data volume change affects three MDM configuration areas:
Storage and retention: Confirm that your MDM's storage configuration can handle 15-minute interval data for your full meter count. A 10,000-meter AMI deployment at 15-minute resolution generates 480,000 reads per day. Legacy MDM deployments sized for AMR data volumes often require storage upgrades before AMI go-live.
VEE rule reconfiguration: AMR VEE typically runs at billing-cycle close, checking period totals. AMI VEE runs at read receipt, checking each 15-minute interval. Rules that flag a period total as anomalous (for example, flagging any period total more than 200% of the prior period) need to be translated to interval-level equivalents that flag individual reads rather than period aggregates.
CIS delivery pipeline: During the parallel period, the MDM delivers billing data to the CIS from two sources: AMR scalar totals for accounts not yet on AMI, and interval-based validated totals for accounts on AMI. Confirm that your CIS integration handles both data types in the same billing cycle without requiring separate billing runs.
For the detailed data flow architecture from AMI head-end through MDM to billing, AMI MDM integration: how smart meters connect to billing covers the four-step flow and where integration failures typically occur.
During the parallel billing period, is your MDM capable of running VEE for both AMR scalar reads and AMI interval reads in the same billing cycle, or does it require a single read type per cycle?
| Function | AMR System (during upgrade) | AMI System (during upgrade) |
|---|---|---|
| Read collection | Vehicle route or fixed AMR collectors | AMI fixed-network collectors |
| Read frequency | One read per billing cycle | 15-minute interval reads |
| MDM VEE | Scalar period total validation | Interval-level read-by-read validation |
| CIS input | Billing-period consumption total | Validated interval consumption total |
| Customer portal data | Billing summary only | Near-real-time interval usage (if portal supports it) |
The parallel period is the highest-risk phase of the upgrade. Both systems must deliver billing-ready data to the MDM on the same schedule, and the MDM must handle both correctly. Testing the parallel configuration in a single billing cycle before full deployment expansion confirms the setup before scale exposes any gaps.
For a utility with 5,000 to 15,000 meters on drive-by AMR, the full upgrade typically takes 18 to 30 months from project planning to full AMI coverage. Fixed-network AMR utilities can move faster because collector infrastructure is already in place; 12 to 18 months is common for fixed-network conversions of similar meter counts.
Most utilities keep their existing CIS through an AMR-to-AMI upgrade. The CIS does not need to change; the MDM handles the translation between interval data and the consumption totals the CIS expects. The integration layer between MDM and CIS may require configuration updates to handle interval-based inputs, but the CIS itself typically does not require replacement.
When an AMI meter fails to report during a billing cycle, the MDM's VEE rules apply estimation to fill the gap before the read reaches billing. The estimation method (typically based on the account's historical interval consumption for the same period) produces an estimated bill similar to what an AMR system would generate for a missed read. The MDM maintains an audit trail of every estimated read for review.
MDM configuration for interval data must complete before AMI meters are deployed. If AMI meters go live before the MDM is configured to handle interval reads, the head-end collects data that has nowhere to go, and the first billing cycle runs on estimated reads for all AMI accounts. Sequence: configure MDM first, validate with a simulated AMI read file, then deploy hardware.
Bynry Inc.
111 Galestown Cir
Chesterfield, NJ 08515
+1 732-630-0285
Bynry Inc.
Serene Tower, Pakharbaug
Pune, Maharashtra 411021
+91 93252-51217
