Practice Management Software (PMS) is a must have feature of the modern healthcare clinic.

Regardless of whether a clinic is moving from the traditional paper-based client notes to a PMS, or changing the PMS they use; like any technology change these changes can come with some trepidation, flashbacks to Y2K and some good ol’ technophobic fear.

So here’s seven key stages to consider when planning to migrate PMS.

What triggers a PMS migration?

• Interoperability with digital health systems
• Privacy and security concerns
• Limitations of current software (lack of integrations)
• Limitations of current hardware (lack of storage)
• The business has been acquired by or merged with another company
• Business growing quickly, or seasonal, needs software to scale accordingly
• Current software pricing is license based per terminal plus support and updates

Being able to communicate and have buy in from your team as to why you are undertaking the migration will keep everyone focused on completing the migration when things get tough.

Whether you’re transferring a small or large amount of data, it’s not just “important” to be prepared. Serious problems including downtime, lost income, extra work, and upset team members and clients can result from failing to adequately plan.

The purpose of this checklist is to help you avoid some of these perils and have a successful PMS migration.

Part 1: Planning Your PMS Migration – First Steps

Before you begin transferring data, take some time to determine exactly what data to transfer and what systems it affects.

Have you developed a map of what data needs to be migrated?

Invariably when migrating PMS most practices start with the concept that coreplus has to do everything that the old one does, workflows must be identical and that all data needs to be migrated. Our experience has been that whilst this thinking remains, the migration is doomed and will fail to complete successfully. Successful data migrations stick to the basics by migrating their:

• Current and past users into coreplus (Past users so that they can be allocated closed clients that they were the case manager for. Alternatively, these can be assigned to a single placeholder user in coreplus)
• Sites (Locations) both current and past so that closed clients can be linked to locations no longer in use
• Service Types and stockable items – only current one’s need be transferred as we recommend to not migrate invoicing data (more about this later)
• Client details (linked to case manager and primary location)
• Referrers and their clinics – Active referrals should be manually transferred to ensure that they are linked correctly

Before beginning your data migration project, develop a map of what data needs to be migrated. Your map should include where your data and dependencies are in the old PMS as well as where they will be in coreplus.

NOTE: Remember to check with all team members even the contractors regarding data being stored external to the old PMS but using references such as identifiers that only exist in the old PMS. An example might be images for clients stored on a network drive and the file name if the client ID from the old system, these will be useless unless the old client ID is recorded in coreplus.

Have you checked your network for any obstacles to data transfer?

• Is the data encrypted, password protected in any way?
• If you’re transferring data over a network, it’s important to have the most bandwidth you can.
• Check for firewalls that might delay data transfer.
• Consider transferring data when there are fewer users — or even better, no users — online.
• Schedule data migration for after hours if possible.

Have you done a landscape analysis to determine what systems the migration will affect? 

• Medicare Site Certificates & Provider ID’s
• Secure Message addresses
• Accounting software
• EFT Terminals (will need WIFI terminals)
• Medical Devices (are they internet enabled?)
• Printers
• Internet / Network and WIFI
• Computers, Tablets and Smart Phones

Data migration usually focuses on the core and target systems. However, these two systems are rarely the only ones affected. Prevent broken links during migration by doing a landscape analysis. This will help you map out what other systems use the data you’ll be migrating, and help you see how the data migration could influence them.

Have you identified software necessary to complete the migration?

Once you’ve identified the systems, amount and type of data you’ll be migrating, you’ll need to choose software to help you move the data to the target system.  Whether you choose to create a checklist, roadmap or GANNT chart will depend on you but commonly used tools include:

• CSV, MS Excel
• Google Sheets– great for collaborating on roadmaps
• Trelloor Wrike – great for flexible project management (GANNT, calendar, checklists)
• Asana– great for advanced “to-do” lists

Imagine the “bad” things

It is well known in IT circles that “Most failed data migration projects, fail due to lack of imagination in the planning stage.” Notice that I didn’t say ‘lack of planning’. But there is an insufficient amount of imagining what the various bad outcomes of various actions might be, so that you can prevent the bad things from happening, or at least have a predetermined plan for when they do happen. Think through each stage of your migration and plan for the worst case scenario, It could save you untold heartache.

Part 2: Figuring Out How to Transfer Data

Your next step in the planning process is to figure out how to transfer data. Test your hypotheses early and often during this stage. Corruption and loss of data are two of the biggest risks in any migration project. Your data transfer method should help to minimize data loss. Good test cases can also cut down on the need for time-consuming manual validation.

Have you accessed your data?

If you don’t already have the full access you need, get access to your data early in the data migration process. This will save you a lot of grief down the road.

• Check out individual files.
• See what types of security permissions they have.
• Will you need to change these permissions during the transfer?
• What types of security permissions will they need in coreplus?
• Are there are any quirks in how the existing database is used that you’ll need to account for such as date formats or naming conventions?
• Actually, looking at your data will let you test out these hypotheses.

Do you have a plan for validating the data transfer?

Validating the data transfer is a crucial step of a data migration; after all, corrupt or lost data is often a costly problem. Planning for data validation from the get-go is the way to go. There are three types of data validation possible:

• Validating random samples
• Validating subsets of data
• Validating the complete data set

In an ideal world, it would be possible to validate the complete data set. But in the real world… do you know anyone with the time and resources to validate a complete data set? Consider validating random samples or subsets of the data to save time and sanity.

Do you have a recovery plan for data that didn’t transfer properly?

Despite your planning and testing, some of the data might not transfer properly. This can include minimal issues like using the wrong delimiter, or the core and target columns using different units of measurement. But it can also include major issues like data loss and corruption.

Two issues you should consider now include:

Semantic data and file naming conventions: It’s common for departments to develop their own file naming conventions, or to use database fields in unusual ways. This usually isn’t a problem. But when you’re transferring data to a new system, it’s important to understand your users’ idioms. If you’re transferring modified data or data stored in fields that wasn’t intended for that data type, consult with user well before the migration to make sure that you understand any unusual ways that they input information. Consider getting various team members to visually validate test samples of their data configured for coreplus before the migration.

Data loss and corruption: During the planning process, you should also consider what to do if data doesn’t transfer. This is a situation where prevention is the best cure. Will you be able to access a backup of any corrupted data? What can you do to prevent data corruption from occurring? Consider things like cleaning and deduplicating data before starting the transfer.

Part 3: Beginning the Data Transfer: Preparing Data for a Migration

Whether it’s duplicates, bad links or outdated formats, most data has at least a few issues. Clean up your data before you transfer it. This will cut down on the amount of data you’ll need to transfer, as well as the amount that you’ll need to validate after it’s done.

Have you cleaned the data you’ll be transferring?

Cleaning data before migrating it is significantly easier than cleaning it after. It can also cut down on problems with corruption and data loss in the target system. Extract, clean and deduplicate data before you transfer it. This is the perfect time to implement uniform standards to the data like ensuring mobile numbers are in the correct field, client and referrer names are entered in the correct case etc

Have you checked to see whether any data should be archived instead of transferred?

Beginning a data migration process is a good time to review your data archiving procedures. You may not want to transfer all of your data. Some of it may be more suitable for archiving such as clients that have been closed for more than seven years. This has the benefit of cutting down on work for you. Review or spot-check some of the data involved with your team who use the particular files in question.

Be careful not to overreact, though. Although it’s tempting to archive data instead of transferring it, be realistic about what types of data need to be accessed regularly. For example, you may import client details for Closed, Deceased or Deleted Clients from your old PMS but instead of bringing everything across you might just include a file note of their status in the old system and a reference as to how the old data can be accessed from archive.

Part 4: Data Security Concerns

Protecting data is a growing concern as it is often overlooked. When you take on a data migration project, expect that many stakeholders will have concerns about security.

Addressing data security concerns early in the process can get your project critical support from these groups.

Have you identified relevant stakeholders from data security or privacy?

There aren’t many ways to stop a data migration project quicker than ignoring security. Find out now who’s concerned with data security and data privacy issues at your business, and figure out how to address their concerns. Consider the following groups:

• Admin/reception team
• Practitioners including contractors
• Accounting team members
• Existing Service contracts with specific security requirements
• Third party software contractors

Identify their specific concerns and the data affected by these issues.

Have you vetted the software and personnel involved in the data migration?

Many of the data privacy risks that a company faces come from careless, uninformed or just plain disgruntled employees. That’s why it’s important to vet any personnel who will play a role in the migration.

This is also a good time to review who has what types of permissions to access confidential data. During the migration it is likely that, at some stage, you will have your entire practice data such as client and referrer lists in some sort of easily transferrable file format. It’s far too common to have accounts that are either not in use (or belong to ex-employees) retain access to restricted files. Remove these permissions before beginning a data transfer to cut down on the risk of data breaches.

By the same token, it’s important to vet the software you use for a data transfer. Don’t just pick up any open-source file transfer software such as Dropbox or send via email! Make sure the software you use is legitimate and well regarded.

Part 5: Getting Buy-in to Your PMS Migration

Getting your team to buy into a data migration project isn’t always easy. Neither practitioners nor administrative users always understand all of the benefits of migrating to coreplus because they do have access to nor understand the big picture. More than a few practices have found themselves struggling to get buy-in from their team due to their team not understanding why migrating is necessary.

Have you set realistic deadlines and deliverables?

More than half of all data migration projects go over the deadline. Therefore, it’s important to be upfront about realistic deadlines for your project.

It helps to group the data by functional areas. Your data map can help you to identify these areas and schedule realistic deadlines. Be sure to allot more time for resource-intensive areas. If you’ve identified areas where there are variations in how the system is used, consider allotting extra time for testing and transferring data.

One way to increase buy-in from your team is to schedule a few wins early in the data migration project. When users can see the benefits of the project, they’re more likely to support it. If you’ve identified an area that could see immediate benefits, consider pushing it to the front of the data transfer project. Look for low-hanging fruit to use as your “convincer”. For example, if your practice struggles with submitting Medicare claims and reconciliation ensure Medicare is enabled first and celebrate the Free Merchant and Transaction fees and the automated reconciliation with your admin team. Perhaps enabling the Client Portal to increase bookings is key for your practice, engage your team early and work towards getting quick wins out early in the process.

Do you have an adequate budget for this project?

We know this doesn’t always happen, but it’s good to know how much your migration project will cost up front! To get your team to support the needs of the PMS migration, focus on how the PMS will help the practice. If you’ll be saving money or improving client outcomes by turning off an old PMS and associated hardware, let people know.

Do you have the right personnel for this project?

Think beyond the IT department when you consider personnel. Try to get subject experts who can help to confirm whether data has transferred over properly. It can also be helpful to find real users to test the migrated data. These real users are your best gauge of whether the new database or system is working properly. If you’re in a large practice, consider delegating this to department heads.

Do you have your practice team buy-in?

For many practice owners, data migration isn’t the most exciting topic (though they will suddenly get real “excited” if something ends up missing or messed up). Particularly for longer complex migrations, it’s important to get prior buy-in from everyone in your team. One of the best ways to do this is to focus on the reason for migrating to coreplus. Why it’s important for your practice and your client outcomes.

Remember, one way to get key team members such as Admin and Senior practitioners on board with migrating is to understand what short-term wins they benefit from and deliver these up front in your migration plan. These will let these team members see the benefits of the migration early on, and help keep them a bit more patient throughout the slower portions of the project.

Helping users to help themselves?

One of the many benefits of choosing coreplus is access to in product help articles via Live Chat with our customer success team during support hours or the Artificial Intelligence used after hours to match requests for assistance with Help Centre articles. During business hours any of your team can engage with the coreplus customer success team via live chat, email or telephone. Empowering all of your team to engage directly with the coreplus team individually will prevent yourself or key team members from bottlenecking the migration.

Part 6: Getting the timing of the Migration right

Migrating between PMS is rarely a simple switch from one to another at a given point in time, unless you have little or no data in the old PMS the process will be more of a transition with various phases over an extended period.

When to export your data from the old PMS?

You should export as soon as possible, mostly because you will need at least one trial run of a full data export prior to the final go live export. As mentioned above the exported data is often formatted differently or has dependencies that do not map to coreplus. For the final Go Live export, you will want data that is as up to date as possible, if your final export is the first attempt you might find surprises that derail your migration.

When to enable coreplus?

As soon as you have decided on coreplus as your new PMS start using it straight away, with coreplus you can create a trial account that can be configured, and Add-ons enabled without having to pay subscription fees until you are ready to go live.

When to conduct training for coreplus?

Giving all users access to coreplus as soon as possible is ideal. Users in large practices with complex workflows will need more time to familiarise themselves with new workflows, change is hard do not under estimate the resistance to change. Remember to focus on the reasons why the change is necessary and give people time to get comfortable with coreplus. Our experience has been that users need one to three weeks of using coreplus to build confidence, so give them access to a training version with some dummy data early and set tasks for each user to complete. Doing this early in the process will build confidence in your team and mitigate the chance of users getting cold feet and feeling pushed into the change rather than welcoming it.

When is a good time to stop using the old PMS?

An ideal time to stop using the old PMS and go live with coreplus is at the end of an accounting period. Doing so will reduce complications from having to reconcile payments, stock, banking and BAS part way through an accounting period. If your migration is near the end of the financial year it may be worth timing your migration, Go Live date as 1 July.

Successful migrations tend to be ones that start using coreplus in parallel with their old PMS at least a week or two prior to the go live date. Yes, this does mean double entry into both systems for a short period, but it is short term pain for longer term gains. Being able to run a report in your old PMS for an entire date period or billing cycle or having future client creation and appointment dates already entered into coreplus will be well worth it later when you are faced with stitching together bits of information from both PMS’s or just looking at either one.

Part 7: Planning for After the Migration

Have you planned for decommissioning the old PMS?

Decommissioning the old PMS, minimizing access to a few power users or disabling access/connectivity altogether is a must do for a successful migration. It can help in two ways.

First, phasing out the old PMS and associated hardware can be a cost-saver. Most people will appreciate when there are savings involved.

Second, the fact that the old PMS and possibly hardware will be turned off means users will no longer have access to data on the old hardware. This can help users understand that they will need to learn how to use coreplus to access client data and learn new workflows. This can also make it easier to get users on board with the process of transferring data.

Do you have a plan for the copies of the migration data?

The work’s not done simply because the data’s been migrated, and your practice is now using coreplus. You’ll also need to make sure that the exported data used for cleansing and importing is stored securely with appropriate permissions for access. If you had multiple versions of working files during the migration where are they and are they still needed. Don’t fall into the trap of leaving your entire client or referrer list on an old PC and forget about it making the data available to a future user of that device.

A final thought…

Following these steps will produce a plan which gives your project a foundation. It is up to you and your team to execute this plan in the face of practice nuances, disgruntled users and missing data (even the best implementations experience these).