6 Best Practices You Should Follow for System Migration as a Healthcare Startup
The rise of open, well-documented APIs and middleware as a service platforms have truly unlocked the power of choice for the consumer. No longer are you tied to a system that does one thing well and five things poorly just so you can have some semblance of coverage across your core business processes. You can now choose the right system for the job and with a bit of plumbing have the best of both worlds: the right tool for the right job with an enterprise-wide vantage point of your data often at a fraction of your current cost.
While exciting, the odds are good that there is at least one legacy monolithic system that you’ll need to transition off of to take advantage of the latest and greatest tools and technology available. Done incorrectly, you are opening yourself up to a deluge of angry stakeholders, data integrity problems, and project delays as you work to migrate from one platform to another. While this may seem daunting, there are several tips that you can follow to keep you from going off the rails and ensure a clean, timely delivery.
6 Tips for a Successful System Migration
1. Communicate, communicate, communicate
Communicate far and wide within your organization to make stakeholders aware of the transition. This allows you time to gather feedback, ensure folks are aware of any changes to their day-to-day processes, and reduce any backlash that may occur during the blackout period of the migration. The more heads up you can give stakeholders that a change is coming, the more prepared they will be for the transition.
2. Build a Data Map
At its simplest a migration is moving data stored in location A to be stored in location B. Building a data map serves two purposes: First it confirms you have a clear handle on the semantic meaning of the data points of the legacy system so you know which points to retrieve. Second, it allows you to front load the planning of which data point in the destination system will support each data point from the legacy system. Writing this down will save you time and large headaches by providing a clear, precise reference on migration day. This documentation can also serve to educate users of the legacy system as to what fields hold relevant data in the new system.
3. Don’t Move Junk
Just as moving houses allow you to take stock and offload junk, there is no better opportunity for reducing data bloat and carving out any old, useless records from a legacy system than during a migration.The longer you’ve used your legacy system, the more likely it is that some or even most of the data is no longer needed. Take time to build a strategy based on object type, modification date, or some other method to ensure that you’re only bringing over data you really need.
4. Make a List of Steps For The Migration
Migration days are stressful. Many migrations occur in the wee hours of the night to avoid business interruption and the nature of a finite black out period means you’ll be racing against the clock. Planning ahead and documenting each individual step needed to complete during the migration keeps you focused and confident, even as the pressure mounts. Make the checklist and check off each step as you proceed to stay on track and finish on time.
5. Bring The Primary Keys
I have Ned, a former mentor and systems ninja to thank for this tidbit, which he beat into my brain during a major HRIS system conversion for a billion dollar enterprise. As you move data from system to system, wherever possible bring along the primary key or identifier of the record from the legacy system and store in the new system, preferably as a column/property on the destination associated object. Invariably there will be some data integrity questions and having the primary key from the legacy system allows you to get to the bottom of the discrepancy with ease. The additional effort it takes is immaterial and will save you tons of time and headaches. Just trust me on this: bring the damn primary keys.
6. Retain Access to Your Legacy System
While not always possible, it is ideal to maintain at least some level of reduced access to the legacy system for six months to a year after migration. For instance, you could reduce your license head count to a single user. This would allow you to have a point of reference if you ever need to check a legacy record while keeping any nostalgic users out of the legacy system. If licensing makes this cost-prohibitive, backups of the legacy system can also work in a pinch.
You Can Do This!
Few things are more intimidating but ultimately satisfying than executing a large-scaled system migration. While details and mileage will vary from system to system, I’m confident the steps provided will save you plenty of time and pain as you prepare to bring the latest and greatest technology to your healthcare company.