A Business Intelligence migration is a term that can be used to cover a number of things.
It may cover the migration of data from a legacy system to a new database system, it may cover the migrating of data and reports from one Business Intelligence system to another, or it may cover the merging of two corporate systems into one system (possibly during a merger).
Whatever the reason for a Business Intelligence migration, it will necessitate a good, clear migration plan.
In the vast majority of cases, a Business Intelligence migration plan should start with a review of what you have (the old system) and where you want to go (the new system). This is important as you may need to perform a comprehensive mapping exercise. The mapping exercise is a critical point in the migration planning excercise. Incorrect mappings will lead to incorrect data, which in turns leads to users losing interest in your Business Intelligence solution.
When reviewing the new system mappings, ensure that users of the old system are familiar with the terms used in the new system. This is not such a big deal on internal system migrations, but will be very important in migrations where two company systems are merged.
You should not at this stage consider implementing any changes in your business rules. The important consideration at this stage is to get your data from the old system into the new, without any changes in the underlying data. If you did implement new rules, how would you test?
When the mapping exercise has been completed, you can use an ETL program to code in the various work and data flows required to migrate your data.
Once the process has run, you need to perform a series of tests. These can use the pyramid method of testing, whereby you produce high level numbers for a set of measures across a series of dimensions. You can test test at a lower level, by testing against smaller dimensions, etc. until you get to your lowest level of data.
If your testing has shown that the data has migrated successfully, it may be worth considering a data cleansing exercise. This may involve tidying up and inserting missing items in variables such as addresses, removing duplications, correcting misspellings, etc.
As well as a data migration, you may also find yourself having to perform a Business Intelligence migration of reports. This may involve an upgrade from one reporting system to a newer version, or the more involved process of migrating a reporting system from one software product to another.
Migrating reports from one version to another is normally straightforward, and often automated via the use of wizards. Not the type that have pointy hats and a wand, but software wizards. These are often the safest option, as the software will have been tested thoroughly by the product vendor prior to release. This however, does not release you from your duties of testing every single report that has been migrated using the wizard. Errors can be introduced. Wizards are very useful if you are migrating from versions which are fairly close to each other – e.g. a v5 to a v6. If you have not migrated versions in a long time, and are on an old version, e.g. v3, you may not be able to use a wizard. In this case it is best to speak to the software vendor so that they can suggest an upgrade path. Alternatively, a more convoluted method is to migrate from v3 to v4, v4 to v5 and v5 to v6. This method, while time consuming, may produce more accurate results. Of course, the alternative is recreate your reports in the new version, and run both versions alongside each other until all reports are migrated.
Finally, a trickier report migration scenario is that of moving reports created in one software product to another. It will be very rare indeed to find that your new software provider has created an automated wizard capable to reading a competitors report structure. In this scenario, you will have no choice but to recreate the reports in the new product, along with all the underlying data sources. This approach however, has a silver lining as it represents an ideal opportunity to identify this reports that are being used and eliminating those which are not. You may find that 50% of your reports are no longer required. This helps tremendously with the migration process, and allows the new product to be used to develop new reports which match user requirements.