Main benefits of having a data repository
- All of the disparate legacy systems in a single place
- Facilitates analysis of legacy system data without having to worry about impacting any of the active systems
By having the data in a repository that the data migration team owns, they have free reign over the types of analysis that they can do and when it can be run. Their own repository also allows them to ensure that the data from the disparate legacy systems is in sync.
- Facilitates mini-test cycles into a mocked up version of the target system
By having a repository, it is possible to bring configuration data, table, and meta data from the target system into it and run some mini conversion tests that can make sure that there aren’t missing cross reference values, setups, and other conversion errors.Without a data repository for the team to run mock test loads, it makes running preliminary test runs an enormous challenge. Sometimes teams without a repository make use of a test environment. This environment may or may not be shared with the functional team or other tech team members that are testing other system configurations. It is usually not set up properly and doesn’t allow easy facilitation of running through entire data sets more than one time.
In order to maximize the data migration team’s efficiency, they need to be able to test data conversions by running them at a whim to ensure that they are working correctly and that the main set-ups are in place. Having their own repository allows for these mini-test cycles so the team can keep track of current issues and continue to pull issues forward in the process, and work with the functional team to resolve them well before the official test and go-live conversions.
- Facilitates a way for data cleansing activities to occur outside the legacy and target systems
- Facilitates an easy way to utilize additional transformation and enhancement rules
To enhance the legacy system data to include this new information, the data needs to come from somewhere. Sometimes this data can be calculated by the conversion programs. For instance, perhaps county code is needed in the new system, but doesn’t exist in the legacy systems. Data conversion programs can calculate the county value during their transformations and load that data into the target system. However, something like primary contact indicator might not exist in the legacy system, but is something that the business wants to utilize going forward. The easiest way to take care of this request is for the business to fill out a spreadsheet that indicates who the primary contact should be for each supplier. This spreadsheet can then be verified by the data repository and utilized by the data conversion programs.
- Facilitates testing and retesting on a stationary data set
- Facilitates the ability to reconcile data post conversion
For the next post, I’ll explore the some of the key features to look for in the data migration data repository. In the meantime, please email me at firstname.lastname@example.org or call me 773.549.6945 for any questions or comments.