Functional Approach to Data Migration
Is the process of managing data migration a functional or a technical task?
Many times I have seen the requirements for a data migration manager being mainly technical – however looking at the aspects of a data migration this may prove strong functional skills must be present.
The data migration focus should be on:
- What we migrate?
- How we migrate?
- How do we know the migration was successful?
These are all business decisions from a functional perspective.
Taking a technical approach to this may put the business at risk as the consequences are obvious if you read on.
What we migrate – is a high level business decision and should be founded in what is critical for the business to function. This often include the basis both for legal and management reporting as well as items to ensure day to day operations.
Legal requirements for data retention may also come into play if the source system is to be decommissioned.
In some businesses historic information is hugely important as this may be used for risk assessment and statistics. However historical information can sometimes be very complex to migrate as each item may include changes to multiple transactions which has to be re-created.
All these items should be agreed by upper management as failing to assess the risks and requirements could in worst case impact share price or result in legal action against the company.
How we migrate – is based on information like volume, complexity and resources. The business needs to have an idea of how to provide the data migration in terms of procedures to obtain the correct data and how to apply it in the new system. This is again a functional task to describe this.
Often the data migration is fully manual and no technical interaction is needed but due to complexity a procedure must be followed. This may include items like period closing in the source system prior to extracting data for the target system. Another topic could be how to pay off as many supplier invoices as possible to reduce volume may be a non-trivial process as this will impact cash flow and reporting especially if the data migration takes place at a quarter end.
Most modern systems accept data from spreadsheets or semi-automated typing tools so most low to medium volume migrations can be done by users as long as the process is well documented.
When volume is very high or complex data transformation is required custom programs may be required but this is no different than specifying any other customization like an interface. As with any other customization this must be described in a separate functional specification.
How do we know the migration was successful – well here the functional approach is needed again. Both verification and reconciliation is needed here.
Only a business user would know if a migrated transaction is correct in the target system. If a transaction is not fully correct represented in the target system the business user will suffer as the transaction will have to be amended or re-entered manually after going live. This verification is clearly a functional task.
The source and the target system data must also be reconciled – often by the use of standard reports or spreadsheets. This will ensure that all the required data i the source system was successfully transferred to the target system. Differences may be allowed as long as they can be explained and verified.
Before going live legal and management reporting should be run and compared to the reporting made from the source system. This may include running quarterly or year-end reports is both systems.
If the data is transformed an audit trail must be retained so the transformation can be validated. Often source system identifiers are carried across to the target system so a report can be produced from the target system but in the format of the source system.
Custom reports may be needed often due to the source system is a legacy system with limited reporting capabilities, Making custom reports is no different than any other customisation so a functional specification is needed here.
Conclusion – data migration decisions and processes are driven from a business and functional point of view. Technical resources may be needed but this is mainly for customisations but this is no different than any other interface or custom report.
If the functional consultant has some technical experience this will be handy when writing the functional specifications.