Why it might be time to switch your organization’s accounting software

Somebody using accountancy software on their laptop
(Image credit: Getty)

In almost every business, the accounts department needs a close relationship with the IT department, but that doesn’t mean the two have much in common. In fact, many basic assumptions IT professionals make are totally disregarded by accounts departments. 

It’s a strange situation, considering the entire IT function in many organizations reports to the finance director. That may be a historical consequence of the fact accounts departments were often among the earliest IT adopters.

The first commercial computer deployed in the UK, after all, was Leo, a computer that handled payroll processing, inventory management and other jobs for Lyons Tearooms. While it may nowadays be considered to be more on the operations side of the business than purely accounts, it was commissioned and managed by the accounts department.  

Legacy Sage products are reaching end-of-life

Sage, in the UK, comes across as a friendly software house, which has made life easier for the hundreds of thousands of small businesses – the ones that have had their hands full managing their business and didn’t want to devote any more time and energy than necessary to tracking their accounts and managing their accounting software.

It must be said, such places tend to disturb the equilibrium of a fully paid-up nerd like me; I walk in and see the real “beating heart” PCs, running critical tasks such as order processing and shipping, all sitting with black DOS-mode screens. This would be the company’s historic installation of Sage: in some cases, there might actually be only a single PC set up to run the entire accounting function.

It’s understandable when businesses haven’t rushed to upgrade, however, because moving from one version of Sage to another can be as much of an upheaval, as moving from Sage to another competing product. So when the news broke that those character-mode screen versions from long, long ago would no longer be supported, it sparked considerable concern in businesses where the accounts software had been a fixture for longer than anyone working in the relevant department.

Since the announcement, the rest of the iceberg has become visible. It’s not just those early releases that Sage wants to withdraw support from, but all sorts of multi-user and multi-function packages are now developing end-of-life dates. For example, Sage 200 Extra Online is slated for deprecation in 2024.

Sage waking up is a good thing, though. It means the age of outdated versions running on singular legacy computers is coming to an end, and that’s great news for manageability, support, and security. And while forced migration is never welcome, it gives businesses an opportunity to move up to a more modern accounts solution, perhaps one that can integrate with a CMS or e-commerce service.

Pay attention to system design

While the accounts team often bears underlying responsibility for IT within a business, separating job functions and technologies is desirable. Traditional techies and computer science people love to converge and integrate; the ultimate expression of elegance in coding is when one program takes over the work of ten individual ones. This is wholly opposite to the instincts of accountants and bookkeepers; they know the value of separability. 

You may appreciate it too if you’ve ever set out to migrate a business that uses a clever, deeply integrated, perhaps cloud-based, all-singing, all-dancing accounting package. This broad scope can be very attractive and powerful when you’re just getting going – it’s a single solution to all your needs. 

Unfortunately, a lack of staging between distinct functions makes it hard to migrate to anything that doesn’t have the exact same structure. In fact, even before you think about where you’re migrating to, questions arise as to whether functions you don’t want to migrate (which may extend beyond the core accounts system) will continue working when the system is no longer whole.

In other words, if you’re congratulating yourself on having designed and commissioned a comprehensive management platform that precisely and exactly reflects the state of your business and marketplace, there’s a good chance you’re actually creating future obstacles. The ability to execute a partial migration, or a lazy cutover from old to new systems, is crucially governed by how you handle stuff that’s not inside the accounts function.

Finding a migration partner

When you are ready to migrate to a new accounting system, you may find choosing a destination almost as hard as implementing the switch. There are comparatively few medium-sized business accounting software packages you can just download and try out during a quiet patch. More often, the solution comes via a specialist, intermediary reseller, which might hopefully be au fait with your business sector, or with the business of making a particular piece of software actually work. 

This state of affairs hasn’t arisen by chance. It’s far from uncommon for package developers – in accounting, or otherwise – to make their software almost impossible to deploy and maintain without specialist knowledge. This puts you somewhat at the mercy of authorized partners, whose demeanors may range from refreshing honesty right through to frankly venal disregard for what you might actually want your systems to do for you. 

It’s as important to pick the right partner as much as it’s important to pick the right software package, therefore. This turns the whole thing into a much more organic, face-to-face process than you may be expecting. 

On the occasions when I’ve been drawn into a partner selection process, I’ve tended to immediately discard those who talk too much about return on investment. That has a lot to do with the businesses I’ve been working with: the idea of getting a demonstrable, financial return on your IT projects makes sense for a business churning out millions of identical products. But it can also be an indicator that the vendor doesn’t understand (or doesn’t care about) the fundamentals of your company. If you’re revamping a website for a company that imports antique Japanese pens worth £50,000 each, how on earth are you meant to calculate the value of a faster accounting system?

Overall, I’ve found partners in the accounting sector have something in common with the systems they support: they’ve experienced relatively little competitive or evolutionary pressure in the last couple of decades, and it often shows. For example, how many accounting products have appeared with support for cryptocurrencies? Would you even trust a partner-labeled business to deliver and implement such a thing? 

Think about your migration tactically 

In business, it’s often important to think strategically: work out your overarching aims, and identify the resources and methods you can deploy to achieve them. But migrating your accounts package probably doesn’t directly connect to your grand corporate mission. It’s a tactical endeavor, involving ideas such as reversibility, soft deadlines, modular adoption, and other buzzwords.

Cutting through the jargon, the goal is to manage away all the dramas and disasters which await a poorly-planned move. In some cases, this can involve a lot of people-management, but in this scenario, the challenges and solutions are largely technical. You have to start way back, with careful consideration of the cost of re-implementing custom code or special-purpose connections – although very often the whole reason for making a migration project is to escape from bodged-up customizations and move to a platform that properly supports the functions you need. 

The human-centric part of a project is managing expectations. An accountant may well expect that every last byte from the old system will be open to retrieval in the new, on the first day of use. In fact, this isn’t necessary and in most businesses, you can migrate the connections and import/export functions on day one, and after that, you have at least 89 days to debug the links and then import the historic transactions. At the bottom, most accounting deployments are essentially quite intricate (but low-stressed) multi-user databases. And any DBA will tell you, there’s no problem with filling up a historic transaction table while the regular users carry on with their daily grind. It’s just another expression of the difference in perspective between the bean counters and the nerds.

In truth, though, it wouldn’t hurt IT professionals to learn a few lessons from the world of accounting. When we come at projects from a technical mindset, we have a terrible tendency to design everything for maximum stress, only one level of security, and long downtime intervals during replacement work. Accounting has a lot to say about smoothing down those peaks of anxiety, thinking around those moments of no-return, and being able to go back to basics for short periods of downtime. These are the keys not only to a successful accounting migration – but positive results in any IT project.