A customer reached out to us this week.
They’d spotted something in our product portal, and they wanted some more info.
We were switching our database provider, and they wanted to know what it meant for their data and what their IT team would have to do.
It’s an understandable reaction. And we’ve had versions of this conversation more than once. So it’s worth getting this out there.
This industry grew up with software on its own servers
I’ve done a lot of thinking about software in the O&G industry since joining here.
Assets exist for a very long time. You put an allocation system (or whatever you are building with EnergySys) in place as the asset goes into production. That could be 25 years ago. And if you did that, then you’d have had that system on-premises.
Oil and gas have a long history of on-premises software.
You’d buy a system, it would get installed on your infrastructure, and from that point forward, every component of it felt like yours. The database, the storage, the servers in the room down the hall.
You could see it. You could probably touch it if you wanted to. And often, your IT team did. Cloud works differently. And for an industry that spent decades doing it the other way, that can take some getting used to.
When you move to a cloud platform like EnergySys, part of what you’re buying is the decision-making that sits underneath the product.
The hosting. The infrastructure. The security. The technical choices about which providers and tools best serve the platform.
That’s not the small print or something to be concerned about. That’s actually one of the things you’re paying for.
What programming language do Microsoft use to build Teams?
Most of the companies we work with use Microsoft. Outlook, Teams, SharePoint, Azure.
These are business-critical tools that their teams rely on every single day.
It’s like asking Microsoft which programming language they used to build Teams.
You care whether your emails arrive, whether your files are there, and whether the system is secure and fast. The technical decisions that make the software part happen are theirs to make, and you trust that they’re making good ones.
You manage things further down the line. User permissions. User settings. You’re the experts in how to set Microsoft up for you, using the software they have provided.
But the underlying tech? They are the experts here. And they make that decision that works best for their product.
Not all questions are equal
Here’s something interesting.
When customers ask us about our underlying infrastructure, it tends to be quite specific.
Database providers come up. Hosting questions occasionally. Nobody asks us which version of which library sits inside the codebase.
There’s no real difference. These are all technical decisions that sit underneath the product you use. The reason some questions feel more familiar is that words like “database” have crossed over into general business conversation in a way that “runtime environment” hasn’t. But from an operational standpoint, they’re the same category of decision.
We make all of them. We make them carefully. And we make them in the interest of all our customers, not just one.
What a change like this actually means
When we move to a new database provider, or make any infrastructure change, the question that matters to you is simple: does my data remain secure, intact, and accessible?
Seeing as this is a huge part of what we are paid for, the answer is always “yes”. In fact, it’s probably more like “yes, more secure, intact, and accessible than before.”
The ability to adopt better infrastructure without disrupting your operations is one of the core advantages of being on a cloud platform. No big upgrade project. No invoice for the change. No system downtime while engineers fly in to rewire something on-premises.
It just happens. And usually it happens quietly whilst your team carries on working.
No upgrade fees. No version lock-in. No waiting.
This is worth sitting with for a moment, because it’s quite different from what this industry has historically been used to.
With legacy on-premises systems, infrastructure changes were events. They required planning, resource, budget sign-off, and often a hefty fee to the vendor. You were billed for progress. That’s why we can understand these questions.
On a cloud platform, improvements to the underlying infrastructure are part of the service. If we switch to a better database provider, adopt more resilient hosting, or make any other technical improvement, your platform gets better.
You don’t get an invoice. You don’t need to raise a project. You often don’t even need to know it happened.
You also don’t lose the ability to change partners if your implementation needs change. The platform is one layer. The partner or configurator building on top of it is another. If you want to move to a different partner or manage the configuration yourself, you can, without dismantling what’s already been built.
That’s a meaningful difference from the old world, where switching vendors often meant starting from scratch.
We are the tech people
EnergySys doesn’t pretend to be deep domain experts in oil and gas. That’s not what we are. Our partners and customers bring that knowledge. What we are is a technology company, 100% focused on building and running a platform that domain experts can use to build serious operational applications.
That means when we make a technical decision, it’s based on what’s best for the platform, what’s most secure, what’s most reliable, and what will serve all of our customers well. Not just today, but as the platform grows.
So if you ever see a change in the product portal and your first instinct is to ask us about it, please do. We’re always happy to talk through what we’re doing and why.
But please do it with this in mind:
EnergySys – the tech people you pay to manage your hosting and infrastructure – saw a better way to run this for you… so we did it.
