Avoiding Common Mistakes in Legacy Data Migration and PaaS Deployments

Introduction

We all know the feeling. The decision has been made, and the die is cast. Whether it is the thrill of deciding to buy a new car or moving into a new home, our attention in such life decisions is usually on the end state but not on the details of the journey. In the case of a new home, we often neglect such details, such as, “Will my furniture actually fit in the new house?” “Who will be involved in moving my possessions?” “Who should have input on the location, furnishings, decorations, and yard?” Believe it or not, the decision to move to a new pension or health system can be eerily similar. Once the decision to migrate to a new pension/health benefits system is made, the actual move is fraught with obstacles and challenges.

Like the improperly planned move into a new house which can lead to unforeseen outcomes, so too can the hastily drawn-up migration from a legacy system to a new pension/health benefits program. Data in the legacy system can be a minefield waiting to be unearthed. How does the new Platform as a Service (PaaS) vendor need the data presented? Who are the stakeholders in the move? How are issues tracked and resolved? How do we determine the current state of the data in the legacy system? How accurate is it? I know we all like to focus on the end state, but if a few key issues can be addressed upfront, we can all happily end up in that robust, state-of-the-art pension/health benefits platform.

Stakeholder Identification and Engagement

First and foremost, in any migration the team of stakeholders must be assembled. But in many instances, this will fall exclusively on the internal IT department. That said, the people who have skin in the game regarding a new pension/health benefits system include much more than IT. The team should include internal business assets, the PaaS vendor, and any third-party vendors whose applications either touch the legacy system or will be integrated into the new platform (i.e., CRM, workflow, or document management). By engaging all of these parties, the data can be migrated into the correct functional state.

Proactive Data Profiling

Before moving data from a legacy system into the new PaaS solution, it must be profiled and examined in its current state. This can best be accomplished by migrating the data to a safe virtual “sandbox” a/k/a data foundry. Once migrated, IT can implement a discovery phase and write scripts to examine and cleanse the data to make it relevant to the new system. Focusing on pain points and risk at this stage can avoid delays once the data is exported, just like measuring your furniture before moving to a new house can prevent unpleasant surprises during the move.

Issue Tracking

While it is great to get everyone on the same page, as issues arise, there must be a methodology to track them and assign ownership. There must be one owner among the stakeholders for the problems and their resolutions. Just like when you move into a new house, someone has to be assigned specific tasks (e.g., like setting up the utilities). Equally important is keeping a historical record of all issues and their resolution. This allows for a knowledge base that will guide future system improvements or troubleshooting.

Data Mapping

Data Mapping is a critical exercise that involves the internal IT and business users of the new system. An agreement on where and how the data will be displayed to efficiently and effectively enable the users of the new platform is paramount. It also allows for the adjudication of issues and a better understanding of the needs of the system’s consumers, both internally and externally.

Quality Assurance and Scorecards

Once the data is transferred to the PaaS vendor, there has to be a feedback loop. This enables the identification of errors and mistakes in the migration process. In addition, as the system operates, new and unforeseen problems might appear. End-users may experience glitches or workflow issues with how the system was set up. By keeping scorecards and addressing unexpected outcomes, quality assurance can be maintained.

Final Thoughts As you can see, a systematic and reasoned approach to data migration can help ensure a less painful move from legacy systems to new pension and health benefits programs. The common assumption that “my legacy data is clean” can be famous last words. A close examination of the old system by all stakeholders can lead to positive outcomes, just like the move to a new house will go much smoother if essential planning is in place before the big day.

Pension Team