In our last blog, Best Practices for Supporting Old and New Systems, we talked a little about what to do with your team after you make that monumental decision to switch from one system to another. Today, we’re talking about what to do with the data that’s caught up in the transition.
“Change Happens,”
“Nothing is certain but death, taxes, and change.”
No matter the reason that drove your organization’s decision to implement a new system, one thing remains true: it is a change process. And that change process encounters the same types of planning questions: What do we do with current systems and data? Who do we need to bring into the conversation? When do we need to do it and how?
As a healthcare IT consultant, how do I view change? To paraphrase a more eloquent quote “change inspires me because a challenge exists to make things better.” During a transition to a new system, there are countless decisions around your current systems and data that must be addressed strategically and methodically to improve the situation, not make it worse. And with all that data… trust me, it’s best to start early.
The Legacy System(s) & All that Data…
Choosing what to update and when.
For a lot of organizations, it doesn’t make sense to immediately throw out their old systems (also lovingly referred to as legacy systems). Instead, organizations choose the safer approach to “keep the lights on” and keep the data in a safe place. But what if “keeping the lights on” means paying too much for your power bill? To ease your minds, set upgrade/change parameters before the project starts. As an example, when the vendor releases an update or other change requests come in, you’ll need to follow your pre-established change guide, which should include certain considerations:
- Does the change impact my data in a regulatory, patient safety, or a financial capacity?
- What constitutes a financial scenario that would cause me to spend time and effort updating legacy systems?
- When do regulations go into effect, and is there a scenario where we could delay updates in legacy systems?
- Does the update meet the parameters around why I would install, test, and train for a new vendor update?
Knowing when it’s time to move on.
When you need to retain data, but it doesn’t make sense anymore – for financial or operational reasons – to store it in your legacy systems, migration is the obvious next step. Before you migrate, however, it’s vital to develop a strategic plan addressing which data to move, how to organize it, where its new home will be, and whether it can even BE migrated into your new system. This is where thoughtful and expert data planning, mapping, and migration strategies come in. It’s not easy, but some people actually live for the challenge…I know a few of them. Maybe one of them is me…
Deciding when to cut the cord.
Sometimes, it’s hard to say goodbye, but some data is only useful for a defined period or, like we just talked about, needs to move on for one primary or multiple reasons. In these instances, it may be more cost efficient to keep the legacy system running while the data runs its course and then at a certain date, just decommission the system. Decommissioning isn’t something to take lightly, and requires answers to incredibly important questions like “what are the legal requirements for data retention,” and “how can I properly dispose of data I don’t need anymore?” Proper planning is required at this point but done correctly, you’ll be rewarded with a smooth transition.
Deciding who to partner with.
Whether you’re migrating data or retiring a legacy system, it will be important to work with qualified, knowledgeable legacy vendors to ensure you have a contract for the right amount of time (not longer than needed), and that you then fulfill the contract tenets for properly closing out the contract. Your partner should be knowledgeable in both your legacy system AND your new system – that’s not easy to find, and it’s an often overlooked qualification. Keep that in mind.
Remembering what it’s all about.
Ultimately your goal should be to maximize the value of systems and data. As I work through a migration process, the little voice in my head constantly reminds me to work towards maximizing value at every step. Data Access – how do we maximize value? Updates – how do we maximize value? Data retention – how do we maximize value? Vendor contracting – how do we maximize value? And on and on…
