
Water Finance and Management reported that Badger Meter announced on Nov. 3 that it had acquired "utility technology and remote monitoring company" 37South, a firm based in Melbourne, Australia. The same summary places the deal within a recent string of acquisitions by Badger Meter and names UDlive Limited as the most recent one it cites. That is an ownership fact. The summary does not describe what happens to the platform's users, administrator roles, or vendor support arrangements after the deal closes, and this article does not assume it does.
Access Is Written Into the Contract, Not the Screen
A remote monitoring platform is usually reached through more than one door. Named user accounts sit beside administrator roles, service integrations that move readings into a SCADA historian or billing system, and vendor support logins that let the company's staff reach the utility's tenant during an outage. Each of these was issued under a service agreement with a specific legal entity, and each depends on that entity continuing in the form the agreement describes.
When ownership changes, the entity may be left intact, folded into a parent, or replaced by a new contracting party. Each outcome moves the access record differently. An administrator role tied to a person survives a corporate change only if the platform re-links it. A token tied to the old organization record may keep working for a while, or stop, with no notice a utility staffer would recognize. Neither outcome is a failure in itself. The problem is that the utility rarely knows which one it is in until someone tries to log in or rotate a key.
The Tradeoff Runs Both Ways
Vendor support access is useful. A support engineer who can see the tenant during a telemetry gap shortens the time to diagnosis, and the utility often wants that. The cost is that the same access can expand who changes alarm settings, polling intervals, or user permissions. The sound position is not to remove support access but to know its window, its scope, and the name of the person who approved it. The pre-close question is which of those three the utility can answer today.
Build the Inventory Before the Notice Arrives
Start with a list that someone outside the vendor can read. Record every account with administrator rights and the person it belongs to. Record every integration token by its purpose and issuing date, not its value. Record vendor support accounts, the access window each one has, and who approved it. Record where data is hosted and which subcontractors the vendor names in its documentation, if it names any. Then send a written request asking the vendor which items will change at closing, which will be re-issued, and what notice the utility will receive. The assignment and change-of-control terms of the agreement are worth reading with the utility's counsel before that request goes out, because they set what the utility can demand.
Dealers and integrators need the same list from their side. A dealer that commissioned gateways may hold a login named in the commissioning record, and that login may outlive the job. Ask the dealer to confirm in writing which credentials it used and whether it still holds them.
Keep Your Own Copy
Keep a dated export of roles, the integration inventory, and support access windows in the utility's own file, not only in the vendor portal. Refresh it at each contract milestone and after any ownership announcement. The export does not need to contain secrets. It needs to show who had access, to what, under which agreement, and when that changed. If a product change follows an acquisition, the file gives the utility a baseline to compare against.
The Nov. 3 announcement tells a utility that the ownership picture is changing. It does not tell the utility whether its logins, tokens, or support paths will change with it. Closing that gap is the utility's job, and it is easier to do before the first new login prompt appears.