Cape Town, 30 Jun 2014
In our involvement in SAP and other software system implementations, the single most frustrating issue that never gets enough attention and investment and always causes the most difficult implementations, if not project failures, is legacy data migration.
One of the worst migration efforts we have ever witnessed was in the banking industry. The business operational resource that was appointed three weeks before go-live to prepare the data, migrated all the savings accounts as checking accounts because the target system configuration defaulted certain settings based on certain data combinations. Honest mistake. Horrible consequences. This was only discovered the following Monday morning when loads of frustrated customers had to leave the ATM machines empty handed, thinking that they were robbed of all their savings.
How does this happen and why? In our experience, the dreaded migration nightmare is instigated as early as in the bidding process. Clients would request the data migration effort to be removed from project estimates because of the cost implication. Vendors often oblige to be successful in the bidding process. The clients' rationale is that they know their data intimately and are in the best position to migrate it. Vendors agree "in principle" to secure the project. Then the project starts and in the flurry of gathering new business requirements, writing blueprints and configuring or developing the target system, data migration usually only pops up again when implementation plans are agreed.
We are all aware of rates pressure and the urgency to deliver; often there will not be enough investment allocated to the migration effort. How then can one address this risk? We believe the following five principles will go a long way in reducing it:
* Contractually agree on a migration strategy. Clients and vendors need to be clear on how migration will be performed. Ask these questions to shape the agreement: Who will be responsible for migration? What methodologies and tools will be used? How will migration quality be assured? How will data clean-up exercises be managed, if at all? What will the tolerance be for non-migrated data? And what post go-live processes will be defined to manage non-migrated data? Will internal and/or external audits be required? Will mock migration runs be performed during the project life cycle? When these questions are answered to everyone's satisfaction, the strategy is defined. Furthermore, in our experience, these questions were critical in getting stakeholder buy-in and investment for migration.
* Run a separate migration project or project stream parallel to the main project. Start early and get sight of all data issues. Even if this initiative is running as an internal project and managed by the client, it is critical to get it off the ground as soon as possible.
* Clients, assign key data resource(s) to the migration initiative. How often has it happened that any tricky question asked by a functional or business analysts is met by this answer: "Just ask Barry"; Barry being the guy who wrote the first bespoke systems for the company; the only guy that knows the history and context of certain processes or data anomalies; Barry who fixes everyone's data problems with a quick update statement directly into the production environment; Barry who is generally too busy running around and solving critical day-to-day problems to answer any of the important questions that needs asking during the life cycle of the project. There is only one problem, Barry is about to retire or die of a heart attack. Barry needs to be allocated to the migration effort in some capacity. Other valuable resources include the integration team; they already have all the experience and necessary tools to move data between systems and they know the client data well. Allocate some of these resources to your migration project.
* Vendors, get access to the legacy data. The sooner one can perform some analysis on legacy data; the sooner one can quantify and understand the complexities around data migration. In our experience, this has been the single biggest success contributor in data and system migration projects. If you understand the data models of both the legacy and the target systems, migration can be a breeze.
* Vendors, always include a data analyst on your project team. Strong technical business analysts with data analysis experience are in fact the best way to go. If legacy data access was arranged, this resource can test assumptions against the data during the requirements gathering phase already. It is known that exceptions in legacy systems outnumber the rule and such exceptions are often only dealt with in the Assumptions section of the requirements. As we all know, assumptions are the main cause for re-design work way too late in any project. Not only will this resource deliver more accurate business requirements; he/she will be in a very good position to assist with the migration effort.
For further information contact ConVista Consulting on (021) 5519294 or visit our website at www.convista.com
Share