Migrate from SAP BO to GCP Looker -  Keeping your data as a source? Is it possible?  GCP's BigQuery has a solid reputation as a cloud database. Some companies will opt for the BigQuery + Looker combo, which is offered at extremely advantageous conditions. In this context, some are considering migrating from SAP BO to Looker. And they're right! Semantic layer aficionados will find it helpful, and BigQuery will guarantee incredible response times.   If the source data has been migrated to BigQuery, that's perfect!  In this context, we recommend migrating the As Is dataviz layer  from SAP BO to Looker (dashboards rebuilt, prompts redefined, data model transposed into LookML, etc.).  Use case: " Adeo / Leroy Merlin migrates its BO reports to GCP Looker by the thousands " .... But in most cases, the migration of multiple databases in SAP BO source must be carried out to BigQuery in parallel: in this context, the project becomes much more complex, therefore stretched, therefore more expensive, etc. Indeed, we often encounter in SAP BO sources Oracle, SQL Server, or DB2 databases, others, Excel sources, "Freehand SQL" integrated in BO, etc.: porting all that to BigQuery is a guaranteed headache!  What if, for the sake of efficiency, we were to leave ourselves the option of not developing the SAP BO sources (at least initially), but of making them compatible with Looker?  This will involve reproducing the behavior of SAP BO in Looker, without immediately migrating the data  .  Recommended technical architecture  1. We will build an intermediate data layer, stored in Google Cloud Storage (GCS), in Parquet format:  > This will allow efficient reading of data (column storage), economical storage, independent of source databases and which is compatible with many tools (native interoperability).   2. We will add a distributed SQL engine:   > It will replay all BO logic : dynamic prompts (SQL pushdown), aggregations, multi-database joins, etc. Most queries are cached on the fly. Some can be scheduled as needed.    3. Looker connections will be made on this layer:  > Looker connects to GCS, not to legacy databases : complete decoupling (which suggests the possibility of future technical interoperability). Expected benefits:    Removal of dependency on non-migrated databases (Oracle, SQL Server, Excel, etc.) Partial reproduction of BO dashboards, even complex ones, without modeling overhead in Looker. We avoid systematic loading : Parquet acts like a cache, but with an "expiration date".  We reduce the load on the sources, but maintain the original user logic.  Provision of impact analysis and data lineage directly in this layer,  with the benefit of facilitating the understanding of dependencies, making maintenance more reliable and anticipating developments.  In summary: You may already have Looker through your GCP contract, but aren't fully leveraging it, or you may be planning to adopt it. Rather than a cumbersome and costly migration, we propose a pragmatic approach: moving quickly, without rebuilding everything, preserving the value of what already exists while preparing a more interoperable architecture.