Migrating Service Charge Data in 6 key steps

The service charge sector’s currently seeing an increased consolidation of managing agents though mergers and acquisition, and as such, many of our clients have sought help with integrating systems and in particular migrating data from one system to another.

From our experience in assisting clients with this process, we know it can be a daunting and time-consuming task for many, the first thing that comes to mind is – ‘Where on earth do I start?!’ We have a dedicated Business Performance Improvement Team (BPI) who have provided this service for a number of clients, and in doing so, have developed tools to ensure the process runs smoothly from end to end. We know planning and testing’s critical to the success of a project of this nature and size, so here’s a few areas we focus on when instructed to assist.

---

1. The initial set up

The initial set up of the new schemes under management is key to the success of migrating new data. Taking time to consider the new nominal codes required as well as the correct schedules per the lease is essential, as trying to tidy up coding later often proves very inefficient or simply doesn’t happen. Ideally a standard approach to nominal codes and schedule naming and references should be adopted wherever possible as this will make data interrogation a simpler and more efficient process.

Considering how the new software accepts opening bank, debtor and other key ledgers should form part of this process.

2. Date of transfer

In an ideal world, the optimum time to transfer data for a scheme to new software would be at the year end, entering simply the opening balances, including service charge debtors and creditor ledgers along with cash balances before processing the new years transactions. However as is often the case, the year ends for multiple schemes won’t be aligned, or the merger of agents will take place mid-way through accounting periods. So, this isn’t usually an option for many to take. Therefore, selecting a date for the transfer is usually driven by the business need which will lead to careful planning prior to execution.

3. Data to be transferred

For a mid-year transfer, you’ll have to decide whether to transfer nominal account balances or individual transactions. There are pros and cons to each approach. Transferring balances reduces the volume of data being moved at the expense of detail. Whereas the opposite’s true if transferring at a transaction level, for a large scheme the volume of transactions to be migrated can be significant and therefore time consuming. This may become an issue as it’s likely that any data transfer will be implemented outside normal working hours to allow systems to continue to function efficiently.

4. Mapping

Before attempting to migrate any data, a mapping table needs to be established in order to link old nominal codes to new codes, old schedule references to new schedule references and old scheme references to new scheme references. If the historic schemes have an inconsistent approach then this can be a time-consuming task. It’s worth the effort however, and putting thought into how the scheme will be managed on the new software will pay dividends in the long run. If there are any housekeeping activities in the coding structure of your existing system then it’s worth planning that activity before mapping the data.

On the projects we’ve previously assisted with, Excel’s been used to recode the data from old to new.

The method for uploading data into your accounting software will vary depending upon the system and the detail of data chosen to upload. It may be you can create a simple journal to upload or create a data import table, either approach should be understood at the outset.

5. Data checks and reconciliation

Before uploading the data, you should consider building into the process appropriate checks to ensure the quality of the data transfer. At a basic level, this should ensure any journal entries balance, but should also include some spot checks on the mapping approach.

Systems such as Propman and Qube have data validation checks before uploading data, and these should form part of the checking process.

6. Review and test

Finally, once the data’s been transferred, a final testing and review process should be considered to ensure the information transferred is as expected. This may need to consider bank reconciliations as well as ensuring any use of suspense accounts have been cleared down.