In my last post we focused on “WHY” we should replace a Legacy system. In this post we shall try to understand a few important challenges that should be addressed.
- Data Loss
One of the biggest challenge for any data/application migration project is that target system (new technology system) should readily consume source data (legacy system). However, there are plethora of tools, especially created to support migration, but it takes thorough analysis to map, transform and migrate legacy data. Often, Data Architects (DA), are accustomed or well versed with either source or target system (and rarely both) – the successful migration depends on their dexterity to mitigate gaps and build bridge between both source and target systems, making data movement very soothing.
- Data Transformation/Cleansing
Data transformation is the heart of any migration project. This involves complex analysis of existing data, meta-data, business constraints, data integrity constraints, mandatory attribute, defaults attributes, derived attributes, etc. DA’s have to wear multiple hats as a business analyst, system analyst and developer, often taking to business stakeholders, infrastructure team, and project team to design migration specifications and transformation rules. Hence making data ingestion an error-free process.
- Data Quality
As it happens, some legacy systems are poorly designed, which leads to lot of data-quality issues. These issues should either be fixed, by recommendations from business or they should be filtered before migrating the data. Apparently, filtering one such erroneous record means leaving behind other good quality records (linked together) behind in the legacy system due to integrity constraints. That is where an intelligent DA will extrapolate and try to fix such erroneous records using pseudo values. Again, in the end, it is a business decision and by all means [any modifications] should be agreed upon by the stakeholders.
Error-free migration does not guarantees that migration is successful – Validation is the key! Best way to ascertain, is to reconcile a use-case between legacy system and the new system. There are many tools that can reconcile data, but manual validation is required by executing same use-case on both systems and recording the out-come. Reconciliation packages should also determine the over-all quality of migrated data and special attention should be given to validate – data loss and data quality.
One thought on “Replacing a Legacy System: Part-2”
Pingback: Replacing a Legacy System: Part-1 – SQLpathy