5 mistakes when changing production accounting

Does your current hydrocarbon accounting solution no longer meet your business’s needs? Do you feel trapped in your contract, with no options and no choice?

You’re not alone. Most of the operators who move to EnergySys come from traditional on-premises systems, so we know the migration process well. Like you, they felt they had little choice but to keep riding the roundabout: expensive installation and maintenance, prohibitive upgrade costs, disruptive upgrade projects, and consultants for every change. The biggest hurdle they overcame wasn’t technical. It was believing that better was possible.

The fear is understandable, and it’s not unique to this industry. Accenture’s cloud value research found that modernising legacy applications ranks among the top three barriers to getting value from cloud, cited by 39% of companies, alongside the sheer complexity of business change. Changing production accounting software isn’t effortless. It takes work and expertise. But it’s easier and less costly than you’d think. In some cases, we’ve delivered it for less than the cost of upgrading the legacy solution.

Here’s the part nobody says out loud: much of what makes a system change feel daunting is the received wisdom about how to run one. The requirements document, the tender, the parallel run. These rituals were inherited from an era when production accounting systems were bespoke software builds, coded from scratch by development teams. They made sense then. Applied to buying a modern configurable product, they add cost, delay, and risk while telling you very little you actually need to know.

So instead of a to-do list, here are five things you shouldn’t do, and what to do instead.

1. Don’t upgrade your current system

An upgrade of your traditional system feels like the lowest-cost, easiest option. It’s generally not.

We recognise you’ve invested heavily to get where you are. You may have standardised across your estate. You’ve trained your people. You don’t want the hassle of change. But in economic terms, all of that is a sunk cost. The money is spent whether you stay or go, so it should play no part in deciding what happens next. Sunk cost thinking is one of the best-documented traps in decision-making, and vendors of legacy systems benefit from it every renewal cycle. The investment you’re protecting is precisely what keeps you on the roundabout.

There’s a practical problem too: upgrading a traditional system is more complex than the quote suggests. It runs as a full project, with the costs and time commitments that implies. Automated migration tools only take you so far, because heavily customised code always needs manual intervention. The initial quote is unlikely to be what you actually pay. And at the end, having spent even more, you’ll have something that isn’t significantly better than what you started with.

Do instead: run the “fundamentally better” test. Before accepting any upgrade quote, write down what fundamentally better would look like for your team. Not “back in support” or “two new features”, but the things that actually cost you time and money today. Then ask, honestly, whether the upgrade delivers any of them:

• Can your own experts change calculations and reports, or does every change still go through the vendor?
• Will the next upgrade be another project, or will upgrades simply arrive?
• Does the cost model become predictable, or does it stay a stack of licences, infrastructure, and consultancy?
• Can you scale down as assets change hands, or are you locked into capacity you no longer need?

For our customers, the upgrade failed this test every time. If it fails for you, the money earmarked for standing still is your migration budget. We’ve written more about the questions to ask before paying for an upgrade.

2. Don’t write a functional requirements document

You’ve decided to replace your system. Now you write the functional requirements, don’t you? Actually, no. And the worst option of all is paying a consultant to write them for you.

Requirements documents have two big problems. First, they’re anchored in your existing system. After years of working within its limits, people specify the system they know, with the pain removed, rather than the system they need. The workarounds have become invisible. The monthly spreadsheet that patches a gap doesn’t appear in anyone’s requirements because nobody thinks of it as part of the system, yet it’s exactly the kind of thing a change should eliminate. You end up documenting your past instead of designing your future.

Second, they read like a big shopping list, and that’s the wrong tool for a major system. It’s like listing the ingredients for a cake without the recipe. A thousand ticked boxes tell you nothing about whether the thing holds together, how it handles change, or what living with it feels like in year three.

Functional requirements made sense when companies hired programmers to build allocation systems from scratch. Today you’re buying a product, a set of concepts, and a future. The market has moved the same way: Gartner predicts that over half of organisations will use industry cloud platforms to accelerate their business initiatives by 2029, and notably recommends treating them as a way to add capabilities rather than a big-bang replacement. You’re not commissioning a build. You’re choosing a platform and a direction.

Do instead: define outcomes, then work in increments. Write down the outcomes that matter: month-end close in fewer days, allocation results your partners can interrogate, in-house changes made within a day, one version of the truth across assets. Outcomes fit on a page and don’t anchor you to the old system’s shape.

Then evaluate by doing, not by documenting. Pick one meaningful user story, perhaps a single allocation or one asset’s reporting, and have each serious contender show you how it’s built. On a configurable platform, this takes days, not months. You’ll learn more from watching your own use case take shape than from any vendor’s 400-row compliance matrix. And you’ll learn the thing the shopping list can never tell you: whether the vendor’s values and direction match yours.

3. Don’t let the tender make the decision

We get it. Most companies have rules about tendering and contract values, and sole sourcing isn’t always an option. But it’s worth being honest about what a tender can and can’t do.

The goal is to find a supplier you trust to deliver your vision of the future. Scoring vendors against a requirements list is a poor way to get there. It isn’t even a reliable way to establish cost: most people have lived through a project where the original requirements list ended up as ammunition for change requests. That’s a misalignment problem, and tenders don’t fix misalignment. They formalise it.

There’s a subtler distortion too. Tenders reward the vendors best at answering tenders. Every question gets a compliant yes, because the alternative is elimination. The exercise measures bid-writing capability, which correlates with the size of a vendor’s bid team and not much else.

Do instead: run a proper reference programme. The best information about a system comes from the people already living with it. Get as many reference contacts as you can, not just the one or two the vendor hand-picks, and dig into the full lifecycle. Keep it informal: people speak honestly on the phone but sugar-coat anything they’re asked to put in writing. Questions worth asking:

• How long did the implementation actually take, compared to what was estimated?
• Who makes changes day to day: your own team, the vendor, or a consultant? What does a typical change cost?
• What happened the last time something went wrong, and how quickly was it resolved?
• What has your experience of upgrades been: disruptive projects, or non-events?
• Has the subscription or licence cost moved in ways you didn’t expect?
• Knowing what you know now, what would you do differently?
• Would you choose the same system again?

Half a dozen honest phone calls will tell you more than any scoring matrix. If procurement rules require a tender, run one, but treat it as documentation of a decision your references helped you make, not the mechanism for making it. Our customer stories are a starting point, but we’d genuinely encourage you to pick up the phone.

4. Don’t run parallel testing

You’re implementing a new system, so how do you know it’s giving the right answers? The obvious move is to run it alongside the legacy system and compare. Appealing, but we’d advise against it, for three reasons.

First, a new system is your chance to re-evaluate current practice, and if you take it, the numbers shouldn’t match. Several of our partners specialise in reviewing allocation agreements, or creating them where none exist. They can help you simplify workflows, stay compliant, and even renegotiate business rules with your venture partners. Years of accumulated workarounds and approximations get stripped out. When old and new results differ, you then face an unanswerable question: is this a defect in the new system, or a correction of the old one? Parallel running can’t tell you, which means it proves nothing.

Second, resourcing. If you’re like most people we know, you barely have time for the day job. Doubling up on data entry, processing, validation, and checking isn’t remotely feasible, and your experts are too scarce to lock into a months-long comparison exercise.

Third, parallel running is the best way ever devised to find problems in your old system, not your new one. EnergySys gives you full transparency over data handling and every calculation performed, so discrepancies are quick to trace and fix. Your legacy system is likely opaque: the calculations might as well be written in hieroglyphics, and you may have no idea where the data goes along the way. Every mismatch becomes an archaeology project into code nobody can read.

Do instead: validate the new system on its own terms. Test calculations in isolation before loading them, using datasets where the correct answer is known and agreed. Because the logic in EnergySys is expressed in standard spreadsheet functions and formulas, your domain experts can inspect every calculation directly and check it against their own calculations, rather than inferring behaviour from the outputs. Validate increment by increment as each use case is configured, so sign-off happens continuously rather than in one terrifying go-live gate. And where results will differ from the legacy system by design, document why up front. That record becomes your audit trail, turning awkward “the numbers don’t match” conversations into evidence of improvement.

5. Don’t compare apples and oranges

Production accounting systems have historically come from companies that sold software development services, and that mentality still shapes how the industry buys. It makes comparing options genuinely tricky, because the same words describe different things.

“Implementation” on EnergySys means configuration, not programming, so delivery is shorter, lower risk, and far easier to estimate. In a traditional system, the same word refers to a complex development project. “Support and maintenance” on a traditional system is a separate fee for someone to answer the phone and post new versions for you. On a cloud subscription, it’s simply included. “Licence” traditionally means a large up-front payment for software you then pay again to keep alive. A subscription is a single running cost you can scale up or down, with no up-front expenditure, no hardware, and nothing to install.

Do instead: compare whole lifecycles, not line items. Build the comparison over a realistic horizon, say five to seven years, and make sure both columns are complete. For the traditional system, that means the licence and the upgrade projects, but also the quieter costs: server infrastructure and its refresh cycle, database administration, IT time spent on backups and patching, consultancy for every change, training against a system only specialists can touch, and the cost of delay every time the business waits on a change request. For a cloud platform, the subscription covers hosting, storage, failover, disaster recovery, security, and every upgrade, so the column is short. The remaining question is configuration effort, whether done by your team or a partner.

This is where value actually diverges. PwC’s UK cloud research found that organisations which have genuinely modernised their systems are realising value at twice the rate of those running outdated ones, and that a large share of companies use cloud merely to rehost what they already had. The lifecycle comparison is how you avoid that trap: it exposes whether an option changes your cost structure or just changes your data centre. Our pricing page shows how the subscription model works.

A different philosophy

EnergySys has been in business for more than 25 years, and we’ve been building our cloud platform for well over a decade, which makes us one of the most experienced providers in this space. Our expertise is the platform. The deep domain expertise in hydrocarbon accounting sits with our partners, and with people like you, which is exactly how we think it should be.

We don’t make our money from consultancy hours, so we’re not motivated to take on big projects that require lots of people. Partners can configure your solution and add value through their expertise in commercial agreements, metering, and more. Or your own team can build it themselves. The point of the platform is that the choice is yours.

Most of all, we have a vision we’d like to share: a platform that cuts your cost of ownership, delivers upgrades without disruption, and grows with you as your circumstances change. If that sounds like a better conversation than an upgrade quote, our Why PaaS page is a good place to start.