Migrate from SAP BusinessObjects to Metabase: what it involves
Migrating from BusinessObjects to Metabase is a practical path for business users who build their own Web Intelligence queries on universes, because Metabase's models and query builder let them ask questions without writing SQL. The BI team usually leads the work, with data engineering owning the warehouse tables and views that sit beneath the universes, and security owning the group and permission design. The main effort lies in the universe layer: joins, prompts, derived objects and filters have to be re-expressed as Metabase models, and each rebuilt definition should be checked against the figures the old query returns. Crystal-style formatted output is a separate question. Metabase covers ad hoc analysis and dashboards well, but any paginated, precisely formatted document needs its own check against what the output must look like before it is promised to the business.
Security is where most surprises appear. Metabase maps users into groups, and Metabase's people and groups documentation describes how group permissions apply to collections and data. Row and column level permissions, SSO and multi-tenant segregation are not part of the Open Source edition, and according to Metabase's pricing page they require the Pro or Enterprise plans. Before choosing an edition, list every BusinessObjects restriction that hides rows or columns from a user group, because those rules must have an equivalent in Metabase or be enforced at the database. On the platform side, the embedded H2 database is for demos only, so plan a PostgreSQL application database from the start and confirm the database version requirements with the Metabase documentation before you build the environment.
Which BusinessObjects capabilities map to Metabase, and which need rework
This table maps the main BusinessObjects capabilities to their closest Metabase equivalents and marks each as clean, needs rework or gap. Read the status column first, then the notes on what must be confirmed in your own environment before you commit to a timeline. The main takeaway is that ad hoc querying and scheduling map well, while pixel-perfect output, complex drill-down and some security features need planning and, in some cases, a higher plan.
| Capability | Metabase equivalent | Status | What to confirm or plan |
|---|---|---|---|
| Universes (semantic layer) | Models and saved questions, with the query builder on top | Needs rework | Universe joins, aliases and filters must be rebuilt as models. Confirm how many universes exist and which objects are shared across them. |
| Web Intelligence ad hoc queries | Query builder on models, plus SQL editor for power users | Needs rework | Business users can ask questions on curated models. Complex multi-query documents usually need to be split into separate questions. |
| Web Intelligence drill-down | Drill-through and click-behavior actions on questions and dashboards | Gap | Confirm drill paths with business owners. Multi-level hierarchical drill may need rebuilt dashboards rather than a direct port. |
| Crystal Reports layouts | Dashboards and table visualizations, with no pixel-level layout control | Gap | Formatted, print-ready layouts are a known gap. Confirm which reports require exact page layout before deciding whether to rebuild or retire them. |
| Scheduling to subscriptions | Dashboard and question subscriptions delivered by email or Slack | Clean | Confirm the recipient list, file format and delivery channel for each schedule. Check which output formats your recipients require. |
| Prompts to filters | Dashboard filters linked to model fields | Needs rework | Prompts with dependent values need to be redesigned as linked filters. Test each one with real user selections. |
| Security to groups and permissions | Groups with data permissions for databases, schemas and collections | Needs rework | Map BusinessObjects security classes to Metabase groups. Row and column level permissions require the Pro or Enterprise plan, according to Metabase's pricing page. |
| Single sign-on | SSO requires Pro or Enterprise on the pricing page | Needs rework | Open Source and Starter do not include SSO. Factor the higher plan into the cost comparison before you plan authentication. |
What data and identities to move, and which integrations to rebuild
Moving from BusinessObjects to Metabase is less about copying files and more about four connected decisions: which reports and universes still matter, which databases Metabase reads from, where Metabase keeps its own state, and how people sign in. Each card below covers one of these decisions and what to confirm before you commit.
Inventory universes and reports
Start with a list of Web Intelligence documents, Crystal Reports and the universes behind them, with owners and last-run dates. BusinessObjects export formats and metadata extraction options must be confirmed with SAP and with your own environment, since they vary by release and configuration. Use that inventory to decide which content is rebuilt as Metabase models and questions, and which is retired. Keep the universe join logic in writing, because it is the part a Metabase model has to reproduce.
Connect Metabase to supported databases
Each data source that BusinessObjects reads today needs a matching connection in Metabase. Confirm that your database has a supported driver and check which network paths, service accounts and read-only roles the Metabase server needs. Metabase models sit on top of these connections, so the same table can serve several reports once it is defined in one place. Test row counts and key figures against the BusinessObjects output before users rely on them.
Move the application database off H2
Metabase ships with an embedded H2 application database, which is suited to demos. For production, Metabase recommends PostgreSQL, and MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 are also supported. Metabase documents a one-time load-from-h2 command for this move, and it must be run with the same Metabase version that last updated the H2 file. Take a backup of the H2 file before you start and plan the cutover as a dated change.
Choose the sign-in method
Open Source and Starter support Google sign-in and LDAP. JWT, OIDC, SAML with documented setups for Auth0, Entra ID, Google, Keycloak and Okta, advanced LDAP group and attribute sync, and SCIM provisioning require Pro or Enterprise. Confirm which directory your analysts already use and whether group membership must drive Metabase permissions automatically. If SCIM or SAML is required, price the Pro or Enterprise plan into the business case before the pilot.
Map BusinessObjects security to groups
BusinessObjects access is usually set through groups, folder rights and universe restrictions. In Metabase, you map these to groups, collection permissions and, on Pro or Enterprise, row and column level permissions. Row and column restrictions that depend on universe security filters need to be reproduced explicitly and tested with real user accounts. Ask your security team to sign off the mapping as a written matrix before access is switched over.
Plan upgrades and backups of the app database
Metabase runs application database migrations automatically during upgrades. Back up the application database before each upgrade, and for major upgrades reduce a cluster to a single node because of a migration lock. Upgrade release by release if you start from a version older than 40. Metabase LTS releases are supported for 14 months, so choose the LTS line that fits your upgrade calendar.
The migration sequence from inventory to decommission
The sequence moves BusinessObjects users to Metabase in controlled stages, so each group's queries, dashboards and access rules are proven against known results before the old platform is switched off. Each step ends with a named artifact that the next step depends on.
Inventory users, queries and reports
Pull usage and ownership data from the BusinessObjects CMS and audit logs, and list every Web Intelligence document, Crystal Report, universe and scheduled instance with its owner, last run date and recipients. Confirm with the business owners which items are still needed, and retire the rest in writing. The output is a reconciled query list with an owner, a business purpose and a keep, rebuild or retire decision for each item, plus the universes and connections each keeper depends on.
Model the data in Metabase
Before any query is rebuilt, the team creates Metabase models on top of the warehouse tables that the universes currently expose, naming fields in business terms and documenting joins, filters and calculated measures. Universe logic that cannot be expressed as a model is listed separately for review. The output is a versioned set of models with a short definition sheet for each, signed off by the data owner who knows the source.
Pilot with a small group of query builders
Choose a small group of power users who build Web Intelligence queries today and give them Metabase accounts on the approved models. They rebuild a handful of their most-used queries, and the team logs every gap in the query builder, drill-down or export behavior they hit. The output is a pilot log with the gaps, the workarounds agreed for each and a go or no-go decision on the model design before the rest of the estate moves.
Run in parallel and reconcile results
For each keeper query, run the Metabase version and the BusinessObjects original against the same data cut and compare row counts, totals and filtered results. Investigate every difference until its cause is known, whether it is a join, a time zone, a null handling rule or a model error. The output is a reconciliation record per report that shows the matched figures, the explained differences and the named business owner who accepted them.
Map security to Metabase groups
Translate the BusinessObjects security model, including folder rights, universe row restrictions and connection access, into Metabase groups, collection permissions and data permissions. Confirm which controls need the Pro or Enterprise plan, such as row and column level permissions and SSO group sync, before any group is granted access. The output is a group and permission map reviewed by the security and data owners, with a test account for each group that demonstrates the expected access and denial.
Cut over group by group
Move each business group in turn: its dashboards are published in Metabase, its subscriptions are set up and tested with real recipients, and its users are told which Web Intelligence documents to stop using. BusinessObjects stays read-only for that group until a set period of normal use passes without open issues. The output is a signed-off dashboard set per group and a cutover record that lists the reports moved, the subscriptions active and any items deferred.
Decommission BusinessObjects
Once every group is cut over, export the final content and audit records you must retain, confirm with compliance what must be kept and for how long, and then switch off scheduled jobs, revoke access and shut down the BusinessObjects servers and licenses in the agreed order. Store the archive in a location the retention policy covers. The output is a decommission record with the archive location, the retention decision and written confirmation from the owners that no active report depends on the old platform.
How the migration changes with estate size and starting point
A small BusinessObjects estate usually has a handful of universes, few scheduled reports and a user base that mostly builds its own Web Intelligence queries. In that case the migration centers on modeling the most-used tables in Metabase so that self-service users can ask questions in the query builder without rebuilding every document. Because the content is limited, the reconciliation work is mostly a conversation with each business owner about which queries still matter.
- Model count: Expect a small number of Metabase models, each built around a business subject that users already query, such as orders, customers or invoices.
- Report reconciliation: Most documents can be checked one by one, and many will be retired once the owner confirms that a model answers the same question.
- Security mapping: A short list of BusinessObjects groups usually maps to a few Metabase groups, with row and column permissions handled only where the data requires them.
- Licensing check: Row and column level permissions are listed on the Metabase pricing page only for Pro and Enterprise, so confirm early whether the small estate needs those features.
- Application database: The embedded H2 database is acceptable for a demo, but plan a move to PostgreSQL before users depend on saved questions.
Confirm with your team how many Web Intelligence documents are opened in a typical month, since usage data often shows a smaller working set than the full document inventory.
A large estate typically has many universes, a long tail of Web Intelligence documents and Crystal Reports with fixed layouts, such as invoices or regulatory extracts. Each universe can hold joins, aliases and business logic that must be understood before it can become a Metabase model. The migration is therefore a multi-phase inventory and reconciliation project, and Crystal Reports with pixel-level formatting usually need a separate decision because Metabase dashboards do not reproduce that layout.
- Model count: Plan for one model per governed business subject, and avoid copying each universe into its own model when several universes share the same tables.
- Report reconciliation: Group documents by owner and by usage, then reconcile the most-used first. Crystal Reports that need exact print formats should be tested for a different output path.
- Security mapping: Map BusinessObjects groups and folder rights to Metabase groups and collection permissions in a written matrix, and review it with the data owners before cutover.
- Operating model: Decide who maintains models and who approves new ones, because a large user base will request changes continuously.
- Upgrade path: Metabase upgrades run application database migrations automatically, so take backups and plan version steps for a production cluster.
Ask your implementation partner to estimate effort per universe and per report category in the written scope, and confirm how formatted exports will be handled.
When the estate already draws from one database warehouse, most universes point at the same schema and the main work is translating joins and business definitions into Metabase models on that single source. Connection setup is simple, and the security conversation focuses on which tables and columns each group may see. This starting point usually produces the fewest models and the fastest path to a first working dashboard.
- Model count: Models can often be built once on the warehouse and reused across reports, which keeps the total count lower than in a multi-source estate.
- Report reconciliation: Duplicate universe logic is common in this case, so compare results of the same question across old and new before retiring anything.
- Security mapping: Permissions can be expressed against one set of schemas, which simplifies the group matrix but still needs review of sensitive columns.
- Query performance: Test the heaviest Web Intelligence queries against the warehouse directly, because self-service questions can be more expensive than scheduled reports.
- Connectivity: Confirm the database driver and version that Metabase supports for your warehouse before planning the build.
Check whether the warehouse holds any data that must stay under a separate access policy, and confirm how that policy will be enforced in Metabase.
An estate that pulls from several databases, flat files or SAP sources needs a clear rule for where each business subject lives. Universes often combine data from more than one source, and a single Metabase model cannot always reproduce that join without a prepared table or view. Model count tends to rise, and reconciliation must check that a figure built from two sources still matches the BusinessObjects result.
- Model count: Expect more models, and decide whether to build cross-source models in a database view, a staging table or a Metabase model.
- Report reconciliation: Test each cross-source report against its BusinessObjects output, including date cut-offs and currency handling.
- Security mapping: Permissions may differ per source, so map each source's access rules separately and then confirm the combined result for each group.
- Data movement: Decide whether consolidation requires a pipeline, which is a separate project with its own cost and operating effort.
- Ownership: Name an owner for each source, since a broken upstream feed affects every model built on it.
Confirm with each source owner which fields are authoritative, because conflicting definitions are the most common reason reconciled totals disagree.
How Metabase models replace universe logic
The core job in this section is re-expressing universe logic as Metabase models, the saved, curated datasets that business users query in the query builder. A universe bundles the join paths between tables, the objects users drag into queries, and the business definitions such as margin, active customer or fiscal period. In Metabase, the join logic moves into a model (a SQL query or a query built in the editor), column names and descriptions are set on that model, and metrics or saved calculations hold the definitions. Map each universe to one or more models, then list every object a Web Intelligence user relied on and confirm it has a home. Universe conditions that filter every query (for example, excluding test accounts) belong in the model itself so they cannot be dropped by a user building a new question.
Metabase stores its own state in the application database, which the team should understand before go-live. That database holds users, groups, permissions, saved questions, models, dashboards, subscriptions and settings, but not the business data itself, which stays in the warehouse. The embedded H2 database is for demos, and the configuration docs recommend PostgreSQL for production, so plan that instance, its backups and its access controls first. Open Source has unlimited users and dashboards, but SSO and row and column level permissions are paid features, so confirm early which BusinessObjects security rules depend on them. The backend runs as a JAR, so the team owns hosting, the Java runtime, the application database and every upgrade, and should schedule upgrades with the application database backup the upgrade docs recommend.
Re-test every rebuilt definition against the BusinessObjects output before retiring a report. Compare row counts, totals and filtered populations for a sample of reporting periods, and confirm that joins with fan-out or many-to-many relationships produce the same figures they did in the universe. Check null handling, time zone and date boundaries, and currency or unit conversions, since these often differ between a universe and a hand-written model. Record each test and its sign-off owner, because finance or regulatory users will ask how a figure was validated. This is also where to decide what an illustrative user-facing definition should be called, so that the same word does not mean two things in the old and new estates.
What drives cost and duration, and how to keep each down
Migration cost follows from how much BusinessObjects content is actually in use, how many sources and security rules sit behind it, and how much of the Metabase feature set you need. The cards below separate one-time work from recurring spend so you can compare written quotes on the same basis.
Universes and Web Intelligence documents in use
The largest driver is the count of universes and Web Intelligence documents that people still open. Each active universe needs its joins, objects and filters rebuilt as Metabase models, and each document needs a query-builder equivalent or a dashboard. Run a usage report from the BusinessObjects audit data before pricing, and ask the quote to state the count of documents in scope and how retired ones are handled.
Number of data sources
Each database or warehouse behind a universe adds connection setup, credential handling, driver testing and data-type checks. Metabase connects to many sources, but each one still needs a tested connection and a review of how dates, currencies and keys behave. Ask the quote to list every source, its owner and whether it is in scope for the pilot or the cutover.
Security complexity
BusinessObjects security often combines folders, groups, row restrictions and universe-level rights. Mapping these to Metabase groups and permissions is one-time design work, and it grows with the number of exceptions. Ask for a written inventory of current rights and an agreed model before build starts.
Plan features required
Metabase's free Open Source edition is self-hosted with unlimited users and dashboards. According to the Metabase pricing page, Starter is $100 per month or $90 per month billed yearly with the first 5 users included, and Pro is $575 per month or $517.50 per month billed yearly with the first 10 users included. SSO, row and column level permissions and usage auditing sit in Pro and Enterprise only, so confirm which of these your security design needs before costing the subscription.
Hosting, backup and upgrades
Self-hosting adds recurring work: servers or containers, a PostgreSQL application database, backups taken before each upgrade, and patching. Metabase runs application database migrations automatically on upgrade, and the documentation recommends a backup first and a single node for major upgrades. Ask the quote who owns each of these tasks and how often they recur.
Reconciliation effort
Business users will compare new dashboards against the BusinessObjects figures they trust, and differences in rounding, time zones or filter logic take time to explain and fix. Reconciliation is one-time per report but can run long for finance and regulatory reporting. Ask the quote to define how many reports are reconciled, who signs off, and what counts as a match.
Questions buyers ask before moving BusinessObjects to Metabase
How much effort and cost does a move from BusinessObjects to Metabase involve?
The cost depends mainly on how many Web Intelligence documents, universes and scheduled reports are still in use, and how much of that logic must be rebuilt as Metabase models, questions and dashboards. Metabase's free Open Source edition has no license fee, so the recurring costs are infrastructure, the application database, support or plan fees if you choose a paid tier, and staff time. Ask any implementation partner for a quote built from a written scope that lists report counts, data sources, security mapping and training, and ask which parts are one-time and which recur each year.
How long does a BusinessObjects to Metabase migration take?
The timeline is set by the inventory, not by the tool. Before any build starts, you need to know which Web Intelligence documents are actually opened, which universes they depend on, which reports are scheduled and who receives them. A small estate with a few shared universes and a short list of active reports can move quickly, while a large estate with many departmental documents needs triage, rebuilding and user acceptance testing. Agree milestones and deliverables in writing before work begins so the duration follows from the agreed scope.
What does the client need to provide for the migration?
The client needs to provide access to the BusinessObjects environment for an export and usage review, the list of databases and warehouses that universes query, and named business owners who can confirm which reports are still needed. You also need a read-only database account for Metabase, a place to host Metabase and its application database, and a decision on how identity will be handled. Owners should be available to validate figures against existing reports, because a rebuilt query that returns different numbers is the most common cause of lost trust.
Can our own BI or platform team do the migration without a partner?
Yes, if the team has SQL skills, access to the source databases and time to rebuild reports. Metabase's query builder lets many business users answer their own questions once a team has defined models, so the work shifts toward governance and model design. The skills that are harder to build internally are reconciling universe logic with SQL definitions, mapping security, and running a supported production deployment with backups and upgrades. A fixed-scope engagement can cover some of these parts while your team keeps ownership of the reports.
Which Metabase features require a paid plan?
According to the Metabase pricing page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in the Pro and Enterprise plans, not in Open Source or Starter. JWT, OIDC, SAML, advanced LDAP group and attribute sync and SCIM provisioning also require Pro or Enterprise, while Google sign-in and LDAP work on the free tier. Confirm the current plan details on the Metabase pricing page before you finalize the security design, because the plan you pick determines how BusinessObjects security groups can be mirrored.
How do Metabase upgrades and LTS support affect the migration plan?
Metabase's LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months, so choosing an LTS line is the usual base for a production estate. Upgrades run application database migrations automatically, so the plan should include a backup of the application database, a single-node reduction for major upgrades because of the migration lock, and release-by-release upgrades from versions older than 40. Budget recurring staff time for these upgrades, and check the version support page for current end-of-life dates.
What happens to the application database if we start on the built-in H2 database?
Metabase ships with an embedded H2 database for demos, and it recommends PostgreSQL for production. If a pilot starts on H2, Metabase documents a one-time load-from-h2 command to move the data to PostgreSQL or MySQL, and it must be run with the same Metabase version that last updated the H2 file. Plan this step before users depend on saved questions and dashboards, and test the move in a non-production environment first. Metabase supports MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 as alternatives.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from SAP BusinessObjects to Metabase runs in your cloud account or data center. We start from an inventory of the Web Intelligence documents, universes and users that matter, then agree the scope, deliverables and timeline in writing before work begins.
How we scope
- Inventory which Web Intelligence documents, universes and schedules are used, and by whom, before any rebuild starts.
- Agree in writing which universes become Metabase models, which reports become dashboards and which are retired.
- Map BusinessObjects groups and folder rights to Metabase groups and permissions, and confirm which sign-in methods your plan supports.
How we build
- Deploy Metabase with PostgreSQL as the application database, following the vendor's production guidance for your environment.
- Rebuild agreed models, key dashboards and subscriptions, and test each output against the figures produced by BusinessObjects.
- Configure SSO, groups and row or column level permissions only where the plan you select includes them.
How we hand over
- Document the data model definitions, dashboard catalog, permission matrix and deployment configuration for your own team.
- Run a walkthrough with business users on the query builder, so ad hoc questions move to self-service without a rebuild.
- Provide a backup and upgrade runbook covering application database backups and the version-by-version upgrade path.
How we support
- Engagements are fixed-scope, so the handover package and its acceptance criteria are defined before the work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after the migration closes.
- Ask any quote to itemize licensing, implementation, report rebuilding and retainer effort, so each cost component is visible.
