You’ve named the problem. Now you’re looking at energy tech options. And if you’ve done this before, you know what happens next: a sea of vendors, all promising the same things. Digital transformation. Automation. Innovation.
Most of it is marketing. The hard part of evaluating energy tech isn’t finding options. It’s working out which ones will still serve you in five years and which ones will quietly recreate the same constraints you’re trying to leave behind.
Why energy tech evaluation is harder than it looks.
At this stage, you’re not ready to commit. You’re trying to understand what’s actually out there. The questions running through your head are probably something like:
- What types of solution could genuinely solve this?
- Is there anything that would change how we approach this completely?
- How do I compare products that look completely different on paper?
The uncomfortable truth is that many energy tech platforms look similar until you’ve spent months discovering their limitations. By then, you’re already mid-implementation.
Cloud-native versus cloud-hosted: why the difference matters in energy tech.
Not everything called “cloud” is the same. A lot of what gets sold as modern energy tech is simply an older system moved onto cloud infrastructure. The underlying architecture hasn’t changed. The vendor dependency, the upgrade cycles, and the rigid workflows are all still there.
A genuinely cloud-native platform is different in a specific way: it was designed from the start to be configured, not customised. That means your team can adapt workflows, allocation logic, and data models directly. No development queue. No support ticket. No invoice for a change that should take an afternoon.
It also means upgrades happen continuously in the background, without scheduled downtime or version lock-in. If a vendor is still asking you to plan for upgrade projects, that’s worth noting.
How to spot legacy in disguise.
These are the warning signs worth watching for during any energy tech evaluation:
- Implementation timelines measured in months or years, with no clear reason why.
- Changes to workflows require external consultants or the vendor’s own development team.
- The system comes with pre-built logic that doesn’t quite fit your operation, and fighting it becomes the project.
- Integration “works” in demos but needs significant support to hold up in production.
- Questions about audit trails or calculation transparency produce vague answers.
None of these is a dealbreaker on its own. But a pattern of them tells you something about what life with that platform actually looks like.
The questions worth asking every vendor.
Don’t accept a demo as an answer. Ask vendors to show you, specifically:
- How quickly can a domain expert change a workflow, without involving the vendor?
- What happens when an acquisition adds new assets or changes the operating model?
- Can you show me where the calculation logic lives and how it can be traced?
- Who owns the configuration: your team, or theirs?
A vendor who can demonstrate these answers confidently is a different conversation from one who promises them.
What it looks like when you get the evaluation right.
EnQuest inherited a legacy production and allocation system following a North Sea acquisition. Rather than maintain it alongside their existing setup, they migrated to a single platform quickly. Allocation models were rebuilt using reusable templates. The inherited system was retired early. When reporting and compliance questions came up, their team could trace the logic themselves.
That outcome started with the right questions during evaluation, not just the right product.
What comes next.
Once you know what good looks like, the next challenge is writing energy tech requirements that actually capture it, without accidentally replicating the system you’re trying to replace. Part three covers exactly that.
