Blog
Cloud accounting

How to change accounting systems without wrecking month-end

Mike Scott

It's possible to move on from an old finance system while minimising the disruption to processes like month-end. A planned migration involves cleansing and mapping your data, testing it in a sandbox, reconciling the results against the old system and training the finance team before go-live. The most common cause of a messy go-live is rushing the data cleanse, so allow the time your organisation needs. West Dean Schools of Arts, Design and Conservation went live in around five weeks after a server crash, though most migrations allow more time.

Key takeaways

  • If your current accounting system is not working well for you, it’s no surprise that you would be nervous about moving to a new platform.
  • It’s important to use a robust implementation methodology when making the switch, and to take as much time as you need.
  • Testing your processes in a safe environment and training your staff on the new system are essential to a successful migration.
It’s understandable to be nervous about migrating to a new accounting system. But you can avoid disruption and the loss of crucial data by following a well-worn migration plan that includes mapping your data, testing in a safe environment and training staff thoroughly. What is most important is not to rush the process, as we'll explore in this, the latest in a series of articles about moving on from outdated systems.

Changing your accounting system is a leap into the unknown. Many companies will have used the same system since they were created. The finance team is inherently comfortable with it, even if it is no longer up to scratch, because they will have designed the workarounds that enable them to keep doing their jobs, albeit less efficiently than they could.

The new system, even if it is much better able to deal with the company’s requirements today and in the future, is still novel. And that brings with it a fear that something awful will happen during the transition and that vital data will be lost.

If you don’t know what’s going to happen, and your current system is not that user-friendly, it’s not surprising that you would worry that making the move will lead to a period of chaos, missed deadlines or problems with month-end or year-end.

These are valid fears, but according to Kieran May, Head of Consulting at iplicit, “there is a whole implementation methodology to switching over to ensure a successful go-live”.

The stages of a safe migration

A well-planned migration will avoid a crisis during a crucial period like month-end. The first thing to do is prepare your data so that what moves across is not just complete, but accurate. “This is an opportunity to cleanse your data and get rid of information on that supplier you haven’t used for five years,” Kieran explains.

You need to map all the categories that exist on the old system onto the new one so that you can record costs in the same way after the migration as before.

Next, a test migration is carried out into a practice version of the new system, so nothing happens for real yet. “We encourage clients to create their own test cases so that everything is tested before go-live,” Kieran adds.

This test data must then be reconciled against the old system to ensure that nothing has gone missing or been changed, then any connections to other tools that your organisation relies on – such as bank feeds, payroll or CRM – must be rebuilt.

This is followed by user acceptance testing, with the finance team trying the new system out before relying on it in a live situation and receiving any training necessary to make sure they’re up to speed with the new platform.

When all that has been done, you’re ready for cut-over – the moment when you switch to using the new system live. Soon enough, you will be at your first month-end and eventually your first year-end on the new system.

“It’s a good idea to do a bulk payment run just before the go-live so the balance is as small as possible and make sure your bank reconciliation is up to date so that the migration is as smooth as it can be,” says Kieran.

Where are the risks in making the change?

With a potentially disruptive project like a change of system, there can be a temptation to get it over with as quickly as you can. But rushing things is where the errors can creep in, derailing everyday work like month-end close and causing frustration across the team.

The length of time it should take will depend on the size and complexity of the organisation. Other factors include the number of entities you’re dealing with, the state of the existing data and how many integrations need to be rebuilt.

The single most common cause of a messy go-live is rushing the data cleanse stage. iplicit always does a full test migration so that any problems are discovered safely in the contained environment of a sandbox rather than live on the new system.

And you still have access to the sandbox once you go live to do further testing in a safe environment of any improvements that you need to make.

Moving static data over to the new platform does not always happen automatically – with some legacy providers, it’s quite simple to extract the data but with others it’s more difficult and if it’s not too expensive, it might be better to leave the data where it is with a read-only licence.

What this looks like in practice

While iplicit recommends a measured approach to migration from your old system, it can be done at short notice in some circumstances. West Dean Schools of Arts, Design and Conservation knew it needed to upgrade its accounting software but when its server was damaged by a sudden crash two weeks before year-end and with an audit looming, that move suddenly became essential.

iplicit managed to migrate all West Dean’s data – which included records for a charitable arm and a limited company responsible for its retail activities – from its 10-year-old legacy Exchequer system into a modern, cloud-based finance system in time for the looming audit.

“Another software vendor suggested iplicit might be a good option because its team had a lot of knowledge of Exchequer and would have the ability to extract our old data, which had been backed up four days before the crash,” says Charlotte Backshall-McGregor, Interim Head of Finance. “We went live with iplicit in around five weeks. It was what I call ‘basic live’, which was enough to get the transactions team working. We weren’t quite there with all our year-end reconciliations but we did complete it just in time for our Christmas audit.”

Most migrations allow more time for planning a smooth transition. “We moved seven years’ worth of Sage data into the archive and produced opening balances,” says Adam Johnson, Managing Director of P. Johnson & Son. “It was a really easy process, enabling us to shut down our old system and have no need to pay for ‘right to use’ access to get to historical information.”

Find out more

Changing to a new accounting system is a big deal. Even if your old platform is clearly no longer up to scratch, your finance team is comfortable with its foibles and knows how to make the best of it – even if that is creating a lot of unnecessary work.

So making the switch is bound to lead to a few nervous moments. But there is a well understood path to migration that will allow you to move to a new platform that is cloud-based and built to make life easier for the finance team, freeing them up to be more productive. You can book a demo to find out what that would mean for your team.

How long does it take to switch accounting systems?

It depends on the size and complexity of your organisation, including how many entities you run, the state of your data and how many integrations need rebuilding. iplicit implementations are usually measured in weeks rather than months, and West Dean Schools of Arts, Design and Conservation went live in around five weeks.

When is the best time to switch accounting systems?

It’s often helpful to go live at the start of a new period so the new system starts from clean opening balances. Switching mid-period means reconciling transactions across two systems, which adds work for your finance team during the close.

What is a test migration?

A test migration moves a copy of your data into a sandbox, a practice version of the new system, so nothing changes for real. Your finance team then reconciles it against the old system and runs its own test cases to catch missing or altered records before go-live.

What happens to our historical data?

Static data such as customer and supplier records moves across first, followed by opening balances. Older transaction history can be stored in an archive or left in your old system under a read-only licence, depending on how easily your current provider lets you extract it.

What’s the difference between a test migration and user acceptance testing?

A test migration checks that your data has moved across completely and accurately. User acceptance testing comes afterwards and checks that your processes work, with the finance team trying out everyday tasks on the new system and receiving training before it goes live.

Want to see iplicit in action?

Book your demo and discover how iplicit can simplify your finance operations, automate manual processes, and give you real-time visibility - wherever you work.