A utility can spend a decade modernizing its grid and never touch the software that keeps it running.
New meters go in. Renewables come online. Outage data flows through modern analytics dashboards. Industry coverage of grid modernization means new hardware, new sensors, and new control systems.
Meanwhile, the software that dispatches the crew, tracks the asset, and closes the work order is often the same system that’s been running since the 1990s. This piece is about that second system, not the first. It doesn’t cover SCADA, EMS, or DMS. It covers the field service, asset management, and work-order software utilities run beside the grid, and why modernizing the grid without modernizing that layer leaves the job half done.
Grid Modernization Covers Two Layers: Grid Control and Back-Office IT
Grid modernization efforts typically target one layer: physical and operational infrastructure. The Department of Energy’s own Grid Modernization Initiative organizes its work around meters, storage, electric vehicle charging, and modernized control systems, the tools that keep power flowing and balance load in real time [1].
Readers looking specifically for that side of grid modernization, such as meters, storage, distributed energy resources, and control-system architecture, will find it covered there in depth. This piece covers the other layer.
Grid modernization usually refers to physical and operational upgrades: new meters, transmission hardware, and grid-control systems like SCADA and DMS. Utilities also run a second layer of technology alongside the grid: the work-order, asset-management, and customer information systems used to plan, dispatch, and document that physical work, and a large share of that layer is still running on 20- to 30-year-old platforms.
That back-office layer is part of grid modernization as the term is actually used, even though it’s architecturally and operationally distinct from real-time grid-control systems.
| Grid Control Layer (out of scope here) | Back-Office IT Layer (this article’s focus) | |
| Examples | SCADA, EMS, DMS | Work-order systems, asset management, GIS-adjacent tools, CIS |
| Function | Real-time control and monitoring of the physical grid | Planning, dispatching, and documenting the work done on it |
| Typically owned by | Grid operations / OT engineering | IT / application owners |
| What Legacyleap modernizes | Not this layer | This layer |
Outage management systems are the one system that genuinely sits in both rows. Their real-time switching and breaker-confirmation function integrates with SCADA and stays out of scope here. Their ticketing, customer-communication, and reporting function is enterprise IT, and that half is what the rest of this piece addresses.
Utility Asset Management Systems Are Still Running on VB6 and Oracle Forms
The systems in question are not exotic. Work-order management, asset registries, and GIS-adjacent mapping tools at many utilities were built in VB6, Oracle Forms and PL/SQL, or PowerBuilder, RAD-era platforms chosen decades ago because they were fast to build and tightly coupled to the database underneath them.
Oracle Forms remains a live migration conversation across the industry, even as Oracle’s own support calendar has shifted more than once, most recently pushed further out by a February 2026 policy revision. What hasn’t changed is the practical pressure on older versions like Forms 10g: fewer developers know the platform, and organizations running Forms-based utility systems are increasingly choosing between an APEX migration and a full application rebuild [2], often for the first time in twenty years.
These systems generally handle a small, well-defined set of jobs:
- Asset inventory and condition tracking
- Work-order creation, assignment, and dispatch
- GIS-based location and network mapping
- Field-crew scheduling and completion reporting
The vendor market serving this category is itself active and consolidating, evidence the underlying need hasn’t gone away even where specific software has stalled. In less-modernized shops, a meaningful share of this work still moves through paper records re-entered by hand at each step, the manual handoff a purpose-built system was originally meant to remove.
For an organization still running a VB6-based work-order or asset-management system, the software itself has usually outlasted the documentation describing what it does.
The Workforce That Understands These Systems Is Retiring Faster Than They’re Being Replaced
NERC’s own 2025 Reliability Issues Steering Committee report names an inability to maintain a cybersecurity-capable workforce as a top reliability risk, citing an aging workforce and the loss of operational technology knowledge as the reason [3]. That finding covers the sector broadly. It applies just as directly to the engineers who know why a specific work-order system was built the way it was.
Utility-sector workforce data outside NERC’s own reporting tells the same story. In one survey of nearly 630 US water-industry stakeholders, 47% named aging workforce and hiring as their top challenge, with 60% flagging engineering roles specifically as most affected by upcoming retirements.
None of this is unique to control systems. A back-office asset-management or work-order platform built in the 1990s or early 2000s was typically documented, if at all, by the people who wrote it. When that person retires, the application doesn’t stop running. It stops being explainable.
That gap compounds. Legacy system maintenance costs escalate over time rather than staying flat, and a system nobody can safely modify is the most expensive version of that problem, since every change carries the added risk of breaking logic nobody currently understands.
A $0 Modernization Assessment maps the dependencies, risk, and effort involved in modernizing a system like this, before any commitment to a timeline or a budget.
Where NERC CIP Actually Reaches Utility Back-Office Systems, and Where It Doesn’t
NERC CIP standards apply to registered entities that own or operate the Bulk Electric System (BES), and the BES definition explicitly excludes facilities used in local distribution of electric energy [4]. Work-order, asset-management, GIS-adjacent, and customer information systems are, functionally, distribution-side and customer-side systems at most utilities.
That’s the honest starting point. Most of what this piece covers sits outside NERC CIP’s direct jurisdiction simply because the assets these systems describe were never BES in the first place.
At vertically integrated utilities, the picture changes. The same asset registry or GIS platform that tracks distribution equipment often also describes transmission and generation facilities that are BES-classified, and that’s where two real mechanisms pull an otherwise ordinary IT system into CIP’s reach.
| Mechanism | How it pulls a back-office system into scope | Governing standard |
| Information-based | An asset registry or GIS map describing BES-classified assets can be a BES Cyber System Information (BCSI) storage location, even with no control-system function | CIP-011 |
| Network-based | A system sharing an Electronic Security Perimeter with a BES Cyber System becomes a Protected Cyber Asset, inheriting its obligations | CIP-005 |
Neither mechanism means these back-office systems must independently be NERC CIP compliant. Both mean an inaccurate asset registry, an undocumented network connection, or an unmanaged vendor relationship can create compliance exposure that has nothing to do with the software’s day-to-day function.
That exposure is getting harder to ignore even at smaller utilities. CIP-003-9, effective April 2026, adds vendor remote-access controls to the lightest-touch, low-impact tier that most cooperative and municipal back-office systems fall under when they’re in scope at all [4]. Cooperatives alone include roughly 830 distribution-only entities against 64 that also own generation or transmission [5]. That split is a rough measure of how much of the sector sits on the distribution side these rules were built to exclude, and how much still doesn’t.
A $0 Security Assessment maps where a specific system’s network connections and data actually touch BES-classified assets, turning this section’s general mechanisms into a concrete answer for one utility’s own environment.
Federal Grid Funding Mostly Doesn’t Cover This Software Layer
The Grid Resilience and Innovation Partnerships (GRIP) program, funded through the Bipartisan Infrastructure Law, represents $10.5 billion in federal grid investment, the largest single federal grid-modernization commitment to date [6]. Its eligible-use language is overwhelmingly physical: transmission and distribution technology, advanced grid devices, storage, and resilience hardware.
Software funding under GRIP is rare. It isn’t nonexistent. GridUnity’s DIGITAL project received $49.5 million in GRIP funding to replace fragmented interconnection-queue tools used by transmission organizations with a centralized platform that includes an AI-based cost-estimation tool [7].
It’s a genuine example of federal dollars funding pure software, in a different system category than this article’s focus: transmission interconnection tooling rather than utility work-order or asset management. Federal funding can clearly reach software. Whether it reaches this specific layer remains a separate, open question.
| What GRIP Funds | What It Doesn’t (Explicitly) Cover |
| Transmission and distribution hardware upgrades | Work-order and asset-management software |
| Grid resilience and storage technology | GIS-adjacent and customer information systems |
| Smart grid devices and advanced sensors | Field-service dispatch platforms |
| Select software, interconnection-queue tooling, case by case | General back-office IT modernization |
The more durable connection is indirect. Every meter, sensor, and transformer this funding adds becomes a row in an asset registry, a data point in a GIS system, and eventually a work order. A back-office system built for a smaller, slower-growing asset base absorbs that pressure whether or not its own modernization was ever part of the grant.
How Legacyleap’s Gen AI Agents Modernize the Software Running Beside the Grid
Modernizing this layer doesn’t require discarding what already works. Legacyleap’s platform runs a five-agent system, Assessment, Documentation, Recommendation, Modernization, and QA, across the full Assess, Comprehend, Modernize, Validate, and Deploy lifecycle, built for codebases where the original documentation is thin or missing entirely.
The Assessment Agent and Documentation Agent address the workforce problem directly. Where a retiring specialist would otherwise take the system’s logic with them, these agents reconstruct architecture, dependencies, and business rules from the code itself, typically within two to five days. The result converts institutional knowledge into a structured, reviewable artifact before that knowledge walks out the door.
Modernization then proceeds as diff-based, human-reviewed pull requests rather than a full rewrite. Incremental modernization preserves working logic instead of replacing it wholesale, which matters for a system whose business rules were never fully documented anywhere else. Roughly 70% of the transformation is automated. Engineers retain final review over every change before it merges.
For a system tied to asset records or billing data, an undetected regression is expensive in ways that go beyond downtime. The QA Agent auto-generates unit, integration, and regression test coverage and validates functional parity against the legacy system before cutover, the same parity check that matters whether the risk in question is a broken report or a compliance-relevant data gap.
All of this runs inside the utility’s own infrastructure. No source code leaves the client’s environment, a detail worth stating plainly given the network and information exposure questions the previous section raised.
Legacyleap is built to handle the same regulated, high-stakes, integration-heavy environments utilities already operate in, backed by the same discipline reflected in 150+ production-grade assessments completed across other regulated industries. Legacyleap’s work across those industries is documented case by case.
Conclusion: Modernizing the Grid Means Modernizing the Software Beside It
Grid modernization, done well, touches both layers: the hardware that carries power and the software that manages everything around it. Utilities have made real progress on the first. The second, the work-order, asset-management, and GIS-adjacent systems still running on VB6 or Oracle Forms, gets modernized far less often. It rarely gets named as part of the same conversation in the first place.
The workforce that understands these systems is retiring on a five-to-seven-year clock. The compliance exposure is narrower than the keyword volume suggests, but real where these systems touch BES-classified assets or networks. None of it requires replacing software that still does its job.
A $0 Modernization Assessment maps the dependencies, risk, and modernization path for a system like this in days, not months, before any commitment to a timeline or a budget. A technical demo is the lower-commitment next step for teams that want to see the assessment and modernization lifecycle work against a real codebase first.
FAQs
A smart grid is one outcome of grid modernization, focused on two-way communication between meters, sensors, and utilities. Grid modernization is the broader effort, and includes the back-office software that plans and documents the physical work behind any smart-grid deployment.
NERC CIP stands for the North American Electric Reliability Corporation’s Critical Infrastructure Protection standards, the mandatory cybersecurity requirements for organizations that own or operate the Bulk Electric System.
FERC certified NERC as the Electric Reliability Organization in 2006. NERC develops and enforces CIP standards through six Regional Entities, while FERC separately runs its own Commission-led audit program.
No. Legacyleap modernizes the field-service, asset-management, and work-order software that runs beside the grid, not SCADA, EMS, or DMS control systems.
References
[1] U.S. Department of Energy, “About the Grid Modernization Initiative.” https://www.energy.gov/gmi/about-grid-modernization-initiative
[2] OptiSol, “What Oracle Forms 10g Users Need to Know About Modernizing in 2026.” https://www.optisolbusiness.com/insight/what-oracle-forms-10g-users-need-to-know-about-modernizing-in-2026
[3] PowerMagazine, “NERC Warns Long-Term Grid Reliability Risks Mounting From Surging Demand, Lagging Resources.” https://www.powermag.com/nerc-warns-long-term-grid-reliability-risks-mounting-from-surging-demand-lagging-resources/
[4] FERC, “2025 Lessons Learned from Commission-Led CIP Reliability Audits” (Oct 20, 2025). https://www.ferc.gov/sites/default/files/2025-10/25._Lessons%20Learned_1014%201.pdf
[5] NRECA, Comments to FERC, Docket No. RM26-4-000 (Nov 21, 2025). https://www.electric.coop/wp-content/uploads/2025/11/RM26-4-000-ANOPR-NRECA-Comments-20251121.pdf
[6] U.S. Department of Energy, “Grid Resilience and Innovation Partnerships (GRIP) Program.” https://www.energy.gov/gdo/grid-resilience-and-innovation-partnerships-grip-program
[7] PR Newswire, “GridUnity’s DIGITAL Project Awarded $49.5 Million in Federal Funding to Accelerate Grid Interconnection.” https://www.prnewswire.com/news-releases/gridunitys-digital-project-awarded-49-5-million-in-federal-funding-to-accelerate-grid-interconnection-302279982.html
