• Strategy – High level scope of the data migration agreeing to what business objects must be migrated and how they depend on each other and on the business. Also business risks, constraints and limitations must be identified. Other topics may be data retention, decommissioning targets and cut-over constraints. This document should be agreed at a high organisational level and also signed off at same level. Typical level is CFO or corporate controller.
• Plan – Estimate in time and money based on the above Strategy including dependencies between business objects. This document is produced by the data migration manager.
• Procedure Design – How to migrate each business object mentioned in the Strategy step by step. This includes data cleansing, entry methods, prerequisites and reconciliation. Reconciliation methods and needed reports must be identified early. At this point needs for functional mapping or technical extract, transformation and load or a custom report may be identified and functional and technical specification documents should be created for this.
• Functional Specification – Functional specification for needs outlined in the Procedure Design. One procedure design may result in one or more functional specifications. Functional specifications should be made for functional and technical deliverables. A typical functional deliverable could be a mapping spreadsheet. Technical deliverables are normally interfaces and reports.
• Technical Specification – Technical specification for the above Functional Specification. This document is no different than a document for a technical deliverable like a interface or a report.
• Script – How to perform the data migration step by step in accordance to Plan and Procedure Design. This is a detailed step by step guide including timings and who to do what by when to ensure the data migration is performed in a controlled manner in correct sequence and to planned time and quality. A good script can significantly reduce cut-over risk and time.

All of the documents above mainly specify functional information. Of cause some technical input may be required – however the main focus is on the functional approach and the technical part is business as usual.

Except for the Technical Design all the above documents should be owned by a functional person  – ideally an experienced person that can engage top management as well as obtaining the technical information required.

Details of the above documents will be described in a later post.

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.