Business Intelligence Migration
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.
Business Intelligence Migration
Business Intelligence Strategy

|