Smart Meter Software: How a Hardware Industry Is Reinventing Its Business Model

2026 June / By Semir Haddad – Chief Product and Strategy Officer at MicroEJ

According to a 2026 analysis by Exponent, nearly 146 million smart meters are currently deployed across the United States, the majority installed during the grid modernization wave of 2008 to 2015 and now approaching the end of their 15-year service life. As that replacement cycle begins, the major metering OEMs are making a structural shift: the smart meter software layer is becoming a distinct, higher-margin business alongside the hardware. Understanding why that is happening, and what it requires technically, is worth a closer look.

Smart Metering Has Always Been a Cyclical Hardware Business

Smart meter deployments are tied to large utility capital programs that run on long cycles. A utility authorizes a program, runs a multi-year procurement, selects a vendor, and deploys devices over two to three years. Then the program closes and the next tender may be many years away. That structure creates revenue that is lumpy by nature: significant during active deployments, thin in the gaps between them.

Geographic diversification has historically been the response, balancing active programs across regions to smooth the peaks and troughs. That approach works reasonably well when cycles are out of sync, but when major markets slow simultaneously, as happened when several large European AMI 1.0 rollout programs wound down in recent years, the structural challenge becomes more visible. Smart meter software and services revenue, being subscription-based and tied to installed devices already in the field, offers a more predictable earnings profile alongside the hardware cycle.

AMI 2.0 Changes What a Smart Meter Is

Here is what makes this replacement cycle different from previous ones. The EPRI Journal published a notable finding in April 2026: despite billions invested and near-universal deployment of smart meters, over 60% of utilities are still primarily using them for billing and outage alerts. The more transformative applications, including dynamic pricing, demand response, and distributed energy resource integration, have been slower to materialize than early AMI promises suggested. The next generation of metering systems is being designed to address that gap.

AMI 2.0 devices are software-defined edge computing platforms. A useful analogy is the shift from a basic mobile phone to a smartphone: the underlying function is the same, but the platform’s ability to host new applications changes what the device can do over time. AMI 2.0 smart meters can receive software updates in the field, run multiple applications simultaneously, and process data locally rather than relying entirely on centralized systems. Utilities planning AMI 2.0 deployments are increasingly thinking in terms of platforms they can extend and update over the device’s service life, rather than hardware they procure once and replace when requirements change.

For smart metering OEMs, this opens the possibility of longer-term software and services relationships alongside the hardware sale.

What Major OEMs Are Communicating to Investors

On June 1, 2026, Landis+Gyr held its Capital Markets Day at the Nasdaq MarketSite in New York and formally restructured into two business segments. Grid Intelligence, covering smart meter software, analytics, and managed services, reported a 45.2% gross margin on 24% of FY 2025 revenue. Connected Platforms, the hardware business, reported 30.7% on the remaining 76%. The company also guided that earnings per share will grow at more than five times the rate of revenue over the next three years, reflecting the higher margin leverage of a growing software mix.

The same week, Itron reported Q1 2026 annual recurring software revenue of $414 million, up 28% year-over-year. Hubbell’s Aclara had launched its Aclara360 grid-edge software platform at DTECH in January. Sensus was moving its Stratus IQ+ application-platform smart meter from pilot to utility deployment. Across the category, investor communications share a consistent theme: smart meter software and services revenue growing faster than hardware, with meaningfully higher margins.

The Device Architecture Behind Smart Meter Software Revenue

There is a practical dimension to this shift that the financial framing does not fully capture. Generating recurring smart meter software revenue from devices in the field depends on what the meter can actually do after it ships. Specifically, it requires the ability to receive new applications remotely, run them independently of the core metering functions, and update them without affecting the rest of the system. Where that capability exists, new grid services can be deployed to installed smart meters without a new hardware program. Where it does not, software revenue typically takes the form of a separate cloud services contract rather than something tied directly to the deployed device.

Most first-generation AMI devices were not designed with this in mind. Each software change touched the entire system, which made adding new services over time complex and costly. AMI 2.0 deployments represent an opportunity to revisit that architecture, and the devices shipping in this cycle will remain in service into the mid-2030s.

VEE Energy™ is the smart meter software platform MicroEJ built to enable this model. It separates application lifecycle from hardware lifecycle, allowing new services to be deployed to devices already in the field without replacing the hardware. The Landis+Gyr Revelo® and Sensus Stratus IQ+ meter platforms are built on VEE Energy™ and represent early implementations of this approach at utility scale.

For OEMs evaluating their smart meter software strategy, the device architecture question and the business model question are closely connected. This is what I hear from product leaders and utility technology directors when we talk about their own programs. If you are considering a business model change, evaluating a new metering platform, or simply exploring what AMI 2.0 could mean for your roadmap, I’d be glad to compare notes.