Firstly, congratulations. That can be a difficult position to be in, as it would be far easier for you to simply use the software you have, never touching it, never enhancing it, knowing that it works as you need it to work. But you aren’t the kind of person who likes to stand still.

Most software these days – especially cloud-hosted solutions – are continually updated on a published timetable, bringing new features – major or minor – into your software stack. This normally forms part of the subscription you pay each month for the privilege of using that software. Pay your money, get the enhancements, it’s a simple concept. No different to you getting new releases on Spotify or Netflix.

Take a look at the Dynamics platforms from Microsoft. The Customer Engagement product receives two updates per year on a schedule, alongside a number of tiny bugfixes. The Finance product receives eight updates per year, bringing new features and sunsetting other features. Since you’re the kind of person who wants to embrace these improvements, you’re excited when they land in your world.

Having the confidence to tell your users and colleagues that the release next week has been fully tested is worth its weight in gold.

But you’re still accountable for your systems, and whilst you have full confidence that the vendor has tested the enhancements, the buck stops with you if Monday morning goes pear-shaped due to a change made over the weekend. And whilst vendors can and do test their software extensively, with ERP systems being highly configurable and extensible there’s still a chance of something slipping through the net.

To do this right, and to give your users or the board or investors the confidence they need, you really have to test this yourself.

The best way to bring this confidence is to invest in your own test strategy. No-one is expected to test an entire system with every release, but every client has a moral duty to test at least their core business processes. Not only does this make it easier to embrace the releases, it is more comforting. Identify which business processes are absolutely critical to you and build a test library around it. For most companies that will start with “I need to be able to pay my staff” and “I need to be able to invoice my clients”; two key processes that are fairly common. But then there are the processes unique to you, or to your company or industry, and only you have that insider-knowledge on what needs to work correctly on a Monday morning.

Building a test library and capability takes time, and it takes money. But it’s a true investment, as it lays the groundwork for you being able to adopt future software much more easily. And if you can go the extra mile and automate that testing, then testing “the next release” becomes a mere formality rather than a chore.

Having the confidence to tell your users and colleagues that the release next week has been fully tested is worth its weight in gold.