Automatic migration from SAP BO to a third-party solution



    Automatic migration from SAP BO to a third-party solution  
    SAP BO is one of the most popular BI platforms on the market. It has continued to evolve, and it continues to be widely appreciated for its reliability.

    However, teams favor "self BI" tools. And the mass movement towards the Cloud has seen the emergence of solutions carried by hyperscalers (Power BI for Azure, Looker for GCP, or Quicksight for AWS, etc.). Migration projects therefore tend to multiply. Including by simply switching SAP BO to the Cloud.

    These migrations are extremely difficult to implement. They are largely operated manually. This leads to long and expensive projects, and sometimes failures.

    We propose to automate the process as much as possible.

    It will never be 1 for 1, but 80-90% of the project can be implemented instantly.

    How ?  
    3 phase :

         Phase 1: "parse" the entire SAP BO platform to
         deconstruct the complexity
    Ellipsys is the editor of {openAudit}, a software that allows to operate an exhaustive reverse engineering on complex analytics platforms. {openAudit} uses various probes or parsers to analyze the dataviz layer, but also all the feeds.

    Regarding SAP BO:
    • {openAudit} will directly parse *.wid, *.unv, *.unx files to retrieve intelligence, document structure, and semantic layer (universe); 

    • Through SAP tools, {openAudit} will access the repository to keep the consistency of IDs between the different objects (universes, data providers, reports, instances, others);
    • An {openAudit} probe will retrieve certain logs from the audit databases (Auditor);

                Phase 2: simplify the SAP BO platform upstream, to
                migrate what needs to be migrate

        2. We believe that the first step in a technical migration of this type will be to essentialize the source platform.

          The strong anteriority of the SAP BO platforms is the source of a strong complexity, which it is useful to resolve upstream.

          How ?
          • Obsolete documents, errors, whether positioned on the common platform or in Private Folders, are detected. They can be archived (creation of unit BIARs) / or simply be discarded massively;
          • The replicated documents are detected by degree of similarity (from 0 to 100%, out of 5 criteria), and can also be discarded massively;
          • Objects that are not used in the documents can be identified, and discarded;
          • Semantic layers can also be cleaned to discard never-published objects.

          It is often a large proportion of the platform that can be decommissioned instantly. a forte antériorité des plateformes SAP BO est la source d'une forte complexification, qu'il est utile de résoudre en amont.  

          {openAudit} pour SAP BO, - film 2'
                Phase 3: migrate automatically

        5. Example of a migration from SAP BO to Looker (Google):

          We are able to “translate” the SQL present in SAP BO, into the language used by Google Looker: LookML.
          LookML is a language for describing dimensions, aggregates, calculations, and data relationships in an SQL database as well as the structure and intelligence of reports.

          3 steps : 
          1 - Migrate 
          the BO universes
          They will be replicated in Looker Views and Explores.
          2 - Migrate 
          the BO objects 
          They will automatically switch to Looker views fields.
          3 - Migrate 
          the layouts 
          They will be translated into LookLM, with the components in the same places.
          Dataviz technologies addressed to date
          for automated migrations: 


                      (Ongoing developments: Tableau, Qlik ...)
                                         Case of a "simple" migration from SAP BO to the Cloud

                                  Some players choose to keep SAP BO and bring it to the Cloud. {openAudit} also makes it possible to operate this movement in a largely automated way.

                                  Here is the list of automated actions:
                                  • Creation of connections on the new platform;
                                  • Remapping target connections to universes (unv, unx);
                                  • Modification of the SQL of the objects using native functions of a DB in the universes (unv, unx);
                                  • Migration of universes;
                                  • Processing of scheduled / mass published documents;
                                  • Editing destinations in posts and instances;
                                  • Mass securities update (ldap, winAD, access level);
                                  • Remapping of objects in documents in case of ID inconsistency;
                                  As soon as a regression is identified, {openAudit} will operate impact analyzes to locate the impacted objects/documents and can update the processes in bulk.

                                  Conclusion :
                                  Few companies have not adopted SAP BO at one time or another. Legacy is often complex, which makes Cloud migrations perilous. We rely on our know-how in terms of reverse engineering to make it possible to operate these scales in a largely automated way (80 to 90%), by having them preceded by a massive simplification.

                                  Migration projects can thus be framed, timed, and they will have a good chance of being a real success!


                                Posts les plus consultés de ce blog

                                Supprimer les régressions entre environnements IT Insight #1 : Comparer les environnements

                                Le lien étroit entre la data gouvernance et la Green IT

                                Les forces et les limites du Data Mesh