It is easy to look at an aging internal application and assume the problem is the software.
Maybe the interface feels dated. Maybe people are doing too much work manually. Maybe the system can no longer support new requirements without a lot of extra effort.
Those things matter, but they are usually only the visible part of the problem.
Behind an application that has been used for years is a much larger system of people, data, calculations, approvals, workarounds, handoffs, and engineering decisions. Some of those processes may exist because of limitations in the software. Others exist for good reasons that are not immediately obvious.
That is why replacing a utility application cannot simply be a matter of rebuilding the same screens with newer technology.
You have to understand the work first.
We saw this clearly while helping a major electric utility modernize its facility ratings management application.
The software was only one part of the problem
Facility ratings are a critical part of electric transmission operations.
Transmission companies need to know how much current their facilities can safely handle. A single facility can contain hundreds of individual pieces of equipment, and the equipment with the lowest rating can determine the rating of the facility as a whole.
That makes the underlying data important. It also makes the process for maintaining that data important.
The utility’s existing facility ratings application had served its purpose for years, but the work around it had become increasingly complicated.
The system could not store equipment at the level of detail engineers now needed. Some calculations had to happen outside the application before values were entered.
Physical equipment could also be represented in more than one place. If a shared piece of equipment changed, engineers sometimes had to update that information multiple times.
The application offered limited data validation, so a simple keying mistake might not be caught until another engineer reviewed the change.
None of these issues sounded dramatic on their own. Together, though, they added extra effort and created more opportunities for human error.
At the same time, the regulatory landscape was changing. FERC Order 881 introduced new requirements for transmission line ratings, adding more complexity to a process that already depended on accurate, detailed information.
The utility did not just need newer software. It needed a system that could support a changing engineering workflow.
Start by understanding how the work actually happens
When a system has been around for a long time, the people using it often know things about the workflow that are not documented anywhere.
They know which steps require extra checking. They know where information tends to be incomplete. They know which parts of the process depend on another group responding at the right time. They know where a seemingly small change can affect several facilities downstream.
You cannot uncover that by looking at the old interface alone.
For the facility ratings project, our team spent time learning how different groups interacted with the application and with each other. We looked at where data came from, how engineers used it, what happened when something changed, and who depended on the resulting information later.
That discovery work shaped the application requirements.
It also helped reveal something more important: some of the biggest opportunities were not about making individual screens easier to use. They were about changing how information moved through the entire process.
Model the real world more accurately
One of the most useful changes was also one of the most fundamental.
The new system stores equipment at a higher level of granularity and represents each physical piece of equipment once.
That sounds like a data-modeling decision, and it is. But it has a direct effect on how engineers work.
When the software more closely reflects what actually exists in the field, engineers have less work to do before entering information. A change to a piece of equipment can be made in one place. The system can then show every facility affected by that change.
This reduces duplication, but it also creates a clearer relationship between the physical system and the software being used to manage it.
That kind of alignment matters in engineering applications.
The closer the digital model is to the real-world system, the less effort people have to spend translating between the two.
Use automation where it can reduce risk
Automation is useful when it removes repetitive work or catches problems earlier.
It is less useful when it tries to replace decisions that still require engineering judgment.
In the new facility ratings application, the system knows the typical ranges for certain ratings. If someone enters an unusual value, the application can flag it for review.
That does not mean the value is wrong. It simply gives the engineer a chance to look again before the data moves further through the process.
Peer review still matters.
Instead of trying to automate it away, the new workflow makes it easier to perform. Reviewing engineers can see what changed, compare the relevant information, and approve the changes before they become active.
The software supports the engineer rather than trying to make the decision for them.
That distinction is important in utility applications, where the best outcome is often not full automation. It is giving people better information at the moment they need to make a decision.
Design for the whole data lifecycle
A utility application rarely exists on its own.
One team may maintain source data. Another may use that information to calculate or manage engineering data. Other groups may consume the results in completely different systems.
During the later phases of the facility ratings work, that broader ecosystem became especially important.
The team was implementing a major upgrade while still supporting the production application. New stakeholder groups were becoming involved. Existing historical data had to remain available. The release also needed to support regulatory requirements with a firm timeline.
That required a lot of coordination.
People needed to understand not only their own role, but also what happened before and after their part of the process.
This is one reason communication became such an important part of the project.
Frequent conversations with stakeholders helped the team surface changing requirements, explain decisions, and make sure different groups understood how their work affected the larger system.
Plan carefully, but expect the plan to change
A project of this size involves a lot of decisions.
Some are technical. Some are about user experience. Some concern rollout, data migration, or stakeholder coordination.
Our team documented those decisions throughout the project using practices such as Architecture Decision Records and design documentation.
That gave everyone a shared reference point.
Months later, when a requirement changed or a technical decision needed to be revisited, the team could see why the original choice had been made instead of reconstructing the discussion from memory.
That documentation did not make the project rigid. It did the opposite.
Because the reasoning was clear, the team could adjust when new information emerged. New information always emerges.
Requirements change. Technical constraints appear late. A stakeholder notices something that was not obvious six months earlier. A solution that looked good in a diagram behaves differently once it is connected to real data.
Planning gives the team a foundation. Flexibility keeps that foundation from becoming a constraint.
Modernization is really about changing the way people work
The final application did much more than update an old interface.
It reduced manual calculations, improved how equipment was represented, helped prevent duplicate updates, added validation, brought peer review directly into the workflow, and made historical information easier to access.
Just as importantly, it gave engineers a better way to understand the same facility over time. They could see how ratings had changed in the past, how they stood today, and how planned changes could affect them in the future.
Those improvements came from looking beyond the software itself.
The goal was not to recreate an aging application on a newer technology stack. It was to understand the process well enough to decide what should stay, what should change, and where software could make the work safer, clearer, and easier.
That is the larger lesson we take from projects like this.
When a utility is considering replacing an internal tool, the most useful starting question is rarely, “What should the new application look like?”
A better place to start is with the work itself.
How are people making decisions today? Where are they repeating effort? Where do errors tend to enter the process? What information is difficult to find? Where does engineering judgment matter most? And which parts of the workflow could software handle more effectively?
Once those questions are answered, the technology decisions become much clearer.
Because the real opportunity in modernization is not simply to build newer software.
It is to build software that fits the work better.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
