The short answer
What Integrator Consolidation Means for a Small Utility
When a small utility depends on one integrator and that integrator is acquired or closes, the utility can lose its institutional knowledge, its programs and drawings, its response times, and its pricing in one transaction it was not party to. The protection is ownership: every program, drawing, narrative, license, and credential in the utility hands, standards that let any competent firm work on the system, and a relationship with more than one firm before it is needed.
Key points
- Consolidation moves the people who know your system, the files that describe it, and the prices you pay, without asking you.
- Own everything: programs, source with comments, drawings, narratives, licenses, and credentials, in your own library, verified.
- Standards that any competent integrator can follow are what make the utility able to change firms.
- Keep a second firm familiar with the system before the first one changes hands.
- Contracts should say who owns the work product and how it is handed over; most do not.
For twenty years a small utility had one integrator. The same two people built the plant SCADA, added every lift station, and answered the phone at night. Then the firm was bought by a larger one three states away. The two people stayed for a year and left. The new firm has a ticket system, a different platform it prefers, and a rate card. The utility still has its system, and for the first time it does not have anyone who knows it. Nothing about this is unusual. Consolidation among controls integrators has been steady for years, and small utilities feel it most because they were the customers most likely to depend on one firm.
What changes
| What the utility had | What consolidation can do to it |
|---|---|
| Two people who knew the system | They leave, are reassigned, or are spread across a region |
| Programs and drawings on the integrator server | Migrated, archived, or lost in the transition |
| A phone number that was answered | A ticket queue with a service level |
| Pricing based on a long relationship | A standard rate card and minimum charges |
| A platform the integrator supported because the utility had it | A preferred platform the new firm proposes at the next upgrade |
| Informal knowledge of the utility standards | Nothing; the new engineers have never seen the site |
Own the work product
The first protection is to hold, in the utility engineering library, everything needed to maintain the system without the integrator: every controller program with the source and comments, at the version that is running, with the software and licenses to open it; every SCADA application backup and its license details; every drawing as built; every control narrative; every device configuration, switches and routers and radios included; and every credential, in a vault the utility controls. Then verify it: upload a program from a controller and compare it with the library copy, open the SCADA backup on a test machine, and check that the drawings match a panel. A library that has never been verified is a hope.
Most utilities discover the gaps when the integrator changes, which is the worst time. The way to discover them earlier is to make the handover a deliverable on every project, with the checklist above, and to ask the integrator for the current copies once a year. An integrator who will not hand over the programs of a system the utility paid for has told the utility something important.
Standards make you portable
A system built to the integrator way is a system only that integrator can work on efficiently. A system built to utility standards, a tag naming convention, a panel standard, a site library of controller and SCADA templates, a network design, a narrative for every site, is a system any competent firm can pick up. The standards are the utility property, they are short, and they are the difference between changing integrators in a month and rebuilding in a year. Small utilities that lack the staff to write them can adopt a peer utility standard or have an engineer write one, and then require every project to follow it.
Know two firms
The time to have a second integrator familiar with the system is before the first one changes. Give the second firm a small project, a lift station upgrade or a screen revision, so that they have been on site, seen the standards, and worked in the programs. The first firm may not love it, and a good one will understand it. When the acquisition letter arrives, the utility then has a choice instead of a dependency.
What consolidation can also bring
It is not all loss. A larger firm can bring deeper platform expertise, a bench when the local people are on vacation, cybersecurity capability a two-person shop never had, and formal processes that a small utility can lean on. The utility that owns its work product and has its standards can take those benefits on its own terms, because it is choosing a supplier rather than clinging to the only one that can read its programs. The utility that has neither takes whatever the new firm offers.
A checklist for this year
- 01Get and verify current copies of every program, backup, drawing, and configuration.
- 02Put licenses and credentials in the utility name and in a utility vault.
- 03Write or adopt a standards document and make it part of every new project.
- 04Add the ownership and handover language to the next services agreement.
- 05Give a second firm a small project.
- 06Ask the current integrator, plainly, what their plans are; most will tell you.
Frequently asked questions
- Our integrator is a one-person firm. Is that riskier than a large one?
- It is a different risk: illness or retirement instead of acquisition. The protections are the same, and the conversation about succession is easier to have with one person than with a corporation.
- The new firm wants to migrate us to their preferred platform. Should we?
- Only for the reasons a platform change would be right anyway: support life, staffing, cost over ten years, data portability. A migration proposed because the firm prefers the platform is a proposal to become dependent again.
- Can we maintain the system ourselves instead?
- Many small utilities do the routine work themselves with a technician who has the software and training, and keep an integrator for projects. Owning the work product and the standards is what makes that possible.
- What if the old programs were never handed over and the firm is gone?
- Upload what the controllers hold, which recovers logic and often names and comments; rebuild the documentation from the upload and the panels; and put the ownership language in every agreement from now on.
Related topics
- The Knowledge That Leaves With the Retiring TechnicianWater and wastewater utilities are losing the people who know how their control systems actually work, and a practical program for capturing it while there is still someone to ask.
- PLC Program BackupsWhat a complete controller backup contains, how often to take one, where to keep it, why the upload from the running controller is not the master, and the verification that turns a folder of files into a recovery plan.
- Control NarrativesWhat a control narrative is, what it must contain, how to write statements that can be tested, and how it drives programming, FAT, and the owner’s acceptance.
- What a Small Utility Should Ask Before Buying SCADAA utility with a plant, a few dozen remote sites, and two operators on call is buying a system it will live with for twenty years. The questions that decide whether it works out, and they are not about features: licensing, staffing, and the exit.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.