Of all the components of a business intelligence system, the reporting solution is the most visible building block. Widely proven, this methodology takes into account technical requirements, security and user expectations.
Explore this blog to know the key steps for migrating a BI solution.
1. Framing & study of the existing
The objective of this preparation phase is twofold. The aim is both to raise awareness among the players concerned and to map the tool in its existing version. This awareness and mapping work is done in workshops with business users. At the end of the workshops, the scope to be migrated is clearly defined, as well as the migration strategy.
2. Review of licenses
Migration is an opportunity to reassess the license pool and resize it. It is not exceptional to discover, thanks to this examination, that a certain number of licenses are unused, which represents an additional cost without object for the company. This examination of the license pool is all the more necessary as the licensing method can vary from one publisher to another, just as it may have evolved between two versions of a solution from the same publisher.
3. Backup of the existing environment
Safeguarding the existing environment is an essential precaution. This operation consists of taking a “photo” of the existing reporting system in order to be able to restore it to a state that we know to be stable in the event of a problem during migration. If you are migrating to another editor’s solution, you must also plan to be able to operate in a dual system until the migration is complete.
4. Identification of duplicate, unnecessary, inactive content, etc.
Over time, it is inevitable that users of a reporting solution will duplicate reports, create temporary documents that are never deleted, stop using certain documents, etc. All of these elements unnecessarily weigh down the reporting system and weaken its performances. The migration to a new solution / version is an opportunity to carry out a major cleaning to start again on a good basis.
5. File cleaning
A logical continuation of the previous phase, unnecessary, obsolete and unused content is isolated. They will not be taken into account in the following steps. The tree structure becomes more readable, which makes it possible to better assess the work to be done to effectively migrate useful content to the new solution.
6. Impact assessment
Any new version of software is accompanied by new functionalities and functional modifications which will have an impact on existing objects and modes of use. This analysis aims to anticipate the impacts of migration on content and on security. It is also during this stage that we anticipate the needs in terms of change management and training of end users.
7. Comparison between old & new version
This technical operation consists in comparing the new environment with the old one. We check that the content has been migrated, that it conforms to what it was and that it updates correctly. We also check that all user profiles have been recovered and we make sure that there is no regression in terms of security and individual rights.
8. Qualification & automated non regression tests
During this step, all the existing reporting elements will be tested: each document is opened simultaneously in the old version and in the new, then is updated to see how it behaves. This operation cannot be carried out by hand. We therefore use third-party software that automates the entire procedure. The results of the non-regression tests are capitalized in recipe books and each identified regression is subject to corrections.
9. Upgrading all environments with tested content
In most contexts, the company has at least two environments – a production environment and a development environment. When you perform the migration which allows you to carry out the two previous steps, you exclusively migrate the production repository from the old version to the new one. Once it has been tested and we are able to certify that this environment is stable, we initialize the development environment in the new version with the content of the first environment. We check its proper functioning through a series of tests.
10. Securing content
Before the final switch, we take advantage of the migration to re-study the security that was recovered from the old version. For optimal security and traceable responsibilities, we recommend the implementation of security matrices. Taking into account all users and all folders, they allow you to specify individual rights with regard to folders, data and applications.
Conclusion
At the end of this last step, we consider that everything is in working order and we can proceed to the final switch. This means that all users will now work on the new version / solution. The old platform will remain active for an agreed period so that it can retrieve items on request that have not been successfully migrated. When the entire process has been carried out in accordance with the rules and in conjunction with the users, recourse to the old version is exceptional.
