Implementing a new practice management system is not a simple undertaking even after the system evaluation, selection and contract negotiations are complete. With demands associated with getting the system design and configuration right, integrations development, process transformation, training, business communications and other change considerations, it can be easy to view the data migration element as a simple technical undertaking. After all, how hard can it be? It’s just data right? A name is a name in any system, likewise for an address, a time transaction, a bill…

​

It may come as no surprise that the largest investment when replacing a practice management system is the data migration, with the outcomes having a major impact on business continuity. Why not use this investment to provide the best opportunity to minimise risk, while maximising the value of the outcomes?

 

Below are ten (10) tips to achieve a successful data migration:

 

1.      Define (and refine) data scope

 

An oft-made, ‘easy’, decision is to elect to take all data from the legacy practice management system into the new system. That should satisfy data retention compliance requirements and allow for full historical reporting and enquiries should the need arise. The downside is spending implementation time, effort and money on data that will not add value to the firm and potentially hinder the data migration process. Older data has potential for greater data integrity issues, which cause more effort to map, test and resolve over multiple test cycles. Clear analysis of the data scope including historical timeframes to migrate will indeed mitigate this risk and this process should be refined for each cycle.

 

2.      Consider all source systems and data repositories

​

Most agreements with the practice management system vendors include standard data migration services involving extracting data from a single source. However, many sources of data may need to be considered whether from peripheral systems such as records management, in-house developed matter management databases, or Excel spreadsheets. Without including these, the firm can end up with a myriad of legacy systems and inefficient processes where multiple systems need to continue to operate.

​

3.      Transform data to match future processes and configuration

​

Bringing data across as-is might be the simple choice however will it work with the new processes to be adopted in the new practice management system? Ideally process design and configuration will have been undertaken prior to data mapping to ensure that the data migrated provides value when in operation.

​

Legacy systems, by definition, will not have matching data structures to the new practice management systems. Commonly, duplicate entities, addresses and related data, redundant or expired system codes, irrelevant historic data that have no place in the new system, will often not be used and should be merged into a tight and usable form. Likewise, gaps in data should be filled to ensure new processes and automation has the opportunity to be productive without the time delays associated with organic data population once in operation.

​

4.      Cleanse data (early and continuously)

​

As they say in the classics GIGO (garbage in – garbage out). Duplicates, data gaps, inconsistencies in format, invalid and outdated financial balances, dormant matters among others should all be dealt with early and continuously throughout the life of the implementation of the new practice management system. This may take the form of automated and/or manual cleansing in the legacy system itself or as part of the data mapping and migration programming. Confidence in the new system is greatly enhanced with cleansed data, not to mention, the productivity gains when data is supporting new processes and automation.

​

5.      Take the first test of the data migration seriously

​

Should the first four (4) tips on this list not be followed, it can be almost guaranteed that the first test of the migration will be a ‘bung it in and we’ll see’ exercise. This leads to large volumes of issues to work through, difficult testing and poor data upon which to develop reports and customisations (if needed). All of this can result in a waste of implementation time, effort and money, along with the requirement to include an additional test of the data migration. The first test of the data migration should be a commitment undertaken by all parties involved with uncompromised expectations of getting as much right as possible.

 

6.      Tailor quality assurance (QA) testing

 

Generic data migration test plans may be available from the practice management system vendors which are well intentioned, however are generally high level - and just that – generic. No firm is a generic operation. Test plans should be tailored to a detailed level and by reference to the data scope and data maps to ensure thorough QA testing. Data migration issues not identified during any testing cycle can become painfully costly and disruptive if fixes are necessary once in operation.

 

7.      Conduct full testing on new processes and reports with migrated data

 

Similarly, generic processing test plans (aka user acceptance test plans) may be available from the practice management system vendors. However a true implementation of a new system always requires transformation of processes, unless you are a firm that tries to customise the new ‘whizz-bang’ system to match the legacy system and continue with the old processes in mind. Testing your full suite of new processes and reports on migrated data will provide certainty once in operation, along with giving your testers the experience that should be leveraged to support the wider user group within your firm.

 

8.      Allow testers sufficient time away from BAU commitments

​

Systems implementations often stretch internal resourcing availability. And, it is tempting to try and fit the required data migration testing in amongst business as usual (BAU) commitments. This inevitably leads to rushed or incomplete testing, missed issues, loss in quality and implementation timeframe slippages. Uncompromised testing schedules, ideally in a dedicated testing environment away from the temptation of BAU activities, always proves to provide the best opportunity to achieve quality testing outcomes. BAU can be accommodated by backfilling or sensible scheduling of resources to provide coverage.

​

9.      Bite the bullet on an additional test of the data migration (when necessary)​

​

Full confidence in data migration is paramount to communicate to key stakeholders to indicate you are ready to proceed to live operation. Should there be significant issues remaining after the last scheduled test of the data migration, it may be tempting to execute a fix in the final data migration. This is fraught with danger. Any costs saved by not undertaking an additional test (when necessary) are inevitably incurred at any rate with data fix-ups occurring in operation not to mention loss of confidence in the new system and loss of productivity by your users.

​

10.    Obtain external expertise (where appropriate)

 

Data migration is a once in a decade (or longer) investment for any firm. Internal staff are more than often experts at BAU, not data migration. Obtaining external expertise can relieve internal staff of undue pressure to learn complex new skills for a one-off need and avoid pitfalls of such inexperience. External expertise not only brings experience in proven data migration methodologies but also brings a wealth of insight into specific data structures of both the legacy and target systems. Further, suites of detailed test plans to match the legacy and target systems to be used for quality assurance and process testing can be provided and rapidly tailored to the specifics of your firm. All of these factors combined provide maximum value, reducing risk and costs, while increasing accuracy and quality in the outcomes.

​

Data migration is too important not to be given the implementation attention and investment needed for any change in practice management system. Get in touch if you need some advice on data migration.

​

Matthew Arendsen, Senior Associate, Harriss Wagner Consultants and Advisers