Which open-source tool replaces Web Intelligence for ad hoc queries?
For business users who build their own queries on universes, Metabase suits people who ask questions through its query builder and models, while Apache Superset suits SQL-literate analysts who work in SQL Lab and the chart builder. The choice depends less on feature counts than on who will write the questions after go-live. If most of your Web Intelligence authors have never written SQL, Metabase's models give them a governed set of tables and joins to pick from. If your analysts already write SQL against the warehouse, SQL Lab gives them direct access with fewer layers in between. Make this decision before the BI 4.3 maintenance date or your renewal notice, because the answer determines which team trains first and which universe objects you rebuild first.
Web Intelligence features do not map one to one onto either tool. Multi-query documents, where several data providers feed one report, need to be split into separate questions, dashboards or SQL queries, and you should confirm how each candidate handles combined results before you commit. Drill-down paths and formatted, pixel-level exports such as the layouts your finance team prints will also need to be rebuilt rather than copied. The sibling pages cover this in detail: migrating BusinessObjects to Metabase is not the right next read for that, so use the internal migration pages for Metabase and Apache Superset as your starting point, and run a usage inventory of your Web Intelligence documents first so you know which ones actually need replacing.
How Web Intelligence capabilities map to Metabase and Apache Superset
This table maps the main Web Intelligence capabilities that BusinessObjects users rely on to the closest Metabase and Apache Superset features, with gaps marked. Read each row as a starting point for a pilot, not a guarantee, and confirm exact behavior against the current documentation for the version you plan to run. The main takeaway is that query building and dashboards map well, while pixel-perfect formatted reports and some document-level behaviors need a deliberate replacement plan.
| Web Intelligence capability | Metabase | Apache Superset | Coverage notes |
|---|---|---|---|
| Query building on universes | Query builder and models let users pick tables, joins and filters without writing SQL | SQL Lab for SQL queries; chart builder works on datasets with defined metrics | Universe joins and objects must be rebuilt as models or datasets; confirm whether any universe metadata can be imported |
| Drill-down | Click-through exploration from charts and dashboards; confirm drill levels for your version | Drill options vary by chart type; confirm drill-to-detail and drill-by support in your version | Hierarchies defined in universes must be recreated as ordered fields and tested with real users |
| Multi-query documents | A dashboard combines several saved questions, each with its own query | A dashboard combines charts from different datasets or SQL queries | Gap to test: shared filters and synchronized behavior across unrelated queries in one document |
| Prompts and filters | Dashboard filters and question variables let users enter values at run time | Native filters on dashboards and Jinja templating in SQL Lab; confirm template support for your database | Prompt logic in complex universes often needs to be redesigned, not copied one to one |
| Formatted exports | Downloads of results in common spreadsheet and text formats; confirm the current list | Chart and data exports; formatted report output depends on scheduled reports and their components | Gap in both: neither replaces pixel-perfect report layouts, so plan a separate tool for those reports |
| Scheduled distribution | Subscriptions with scheduled delivery; confirm channels and availability for your plan | Alerts and reports need the caching layer and Celery worker components, usually Redis and Celery | Size the worker and cache components before go-live, since they add operational work |
| Row-level security | Row and column level permissions are included only in the Pro and Enterprise plans | Row-level security rules can restrict data by role; confirm setup and limits in your version | Map Web Intelligence security profiles to groups and permissions before rebuilding reports |
| Authentication | Google sign-in and LDAP in open source; SAML, OIDC and SCIM require Pro or Enterprise | Database, LDAP and OAuth2 authentication; AUTH_ROLES_MAPPING maps groups to roles | Confirm which identity protocol your directory needs and which Metabase plan provides it |
When Metabase or Apache Superset fits Web Intelligence users
Web Intelligence users build their own queries on universes, so the replacement has to match how far those users go into SQL and how much operational work the team can carry. The three cards below cover the two self-hosted candidates and a transition option, each with the trade-off a CIO or BI lead should weigh before choosing.
Metabase for guided self-service
Metabase fits teams whose business users want to ask their own questions through a query builder and curated models, without writing SQL. It suits data sources that already have clean, well-named tables, because models are where you define the business meaning that a universe used to hold. The trade-off is that row and column level permissions and SSO sit in the paid Pro and Enterprise plans, so confirm which controls your security team requires before you commit. Ask whether your access rules can be met on the open source edition or whether they push you to a paid plan.
Apache Superset for SQL-fluent analysts
Apache Superset fits analysts who are comfortable in SQL Lab and teams that need many database types through SQLAlchemy drivers. It is Apache-2.0 with no paid edition, so licensing cost is not the deciding factor. The operating cost is the platform itself: production runs need a PostgreSQL or MySQL metadata database, and alerts, reports, async queries and thumbnails add a caching layer and Celery workers. Confirm your team can own those components, back up the metadata database and test upgrades in staging before adopting it.
Keeping Web Intelligence for a subset
Some documents will not move on the first wave, such as multi-query reports with complex formatting or scheduled bursts that depend on BusinessObjects features. A transition plan can keep Web Intelligence running for that subset while high-use documents are rebuilt. The trade-off is running two reporting estates, with their own licenses, servers and security models, for longer than planned. Put an end date on each retained document and record who owns it, so the parallel period does not become permanent.
What happens to drill-down, multi-query documents and formatted exports
In Web Intelligence, a drill path usually follows a hierarchy defined in the universe, such as year, quarter, month and day, and users move up and down it inside one document. Metabase lets users click a chart element to see the underlying records, and the drill behavior depends on how the model and its fields are described. Superset offers drill-by and drill-to-detail actions on supported charts, so the hierarchy is set chart by chart. Neither tool imports the universe object tree automatically, so the hierarchy has to be rebuilt deliberately.
- Hierarchy definition: Write each universe hierarchy as an ordered list of columns in a Metabase model or a Superset dataset, and document that order before building charts.
- Drill-to-detail access: Confirm that detail rows respect the same restrictions the universe applied. Row and column level permissions in Metabase are part of the Pro and Enterprise plans, so check the edition you intend to run.
- Modeler work: A data modeler should define joins, calculated fields and date grains once, so business users are not rebuilding them in every question.
- Reconciliation: Compare drill results for a sample of parent members against Web Intelligence output, including nulls, time zones and subtotals.
Confirm that each drill path opens the same detail population as the original document for a fixed date range.
A Web Intelligence document can hold several data providers and report blocks that share one layout. In Metabase, each question is a separate query, and a dashboard combines them with filters that can be mapped to columns across several questions. Superset runs each chart as its own query against a dataset, and native filters on a dashboard apply to every chart that has a compatible column. Blocks that merge results from two sources into one table have no direct equivalent, so the usual approach is a joined view in the warehouse or a governed SQL query that a developer exposes as a dataset.
- Separate queries: Each data provider becomes a Metabase question or a Superset chart, and readers see the results side by side on a dashboard.
- Shared filters: A filter that appears in several Web Intelligence queries needs one dashboard filter mapped to a column in each query.
- Merged results: Cross-source merges need a warehouse view or a SQL Lab query built by someone who knows the join keys and grain.
- Edge cases: Test totals across blocks, filter behavior when a value exists in one source but not the other, and the refresh order of dependent queries.
Check that every block in the source document has a named owner, a documented query and a matching result on the same test date.
Web Intelligence exports are often used for printed or PDF packs with headers, page breaks, sections and cell formatting. Neither Metabase nor Superset reproduces that paged layout at pixel level, so the target should be designed around what each tool produces well. Metabase exports query results and dashboards to spreadsheet and CSV formats, and column settings control how numbers and labels appear. Superset supports data exports from charts and tables, and it can send dashboard content through its reports feature, which depends on worker components.
- Spreadsheet output: Confirm column order, number formats, date formats and header text in CSV and Excel files against the original export.
- Printed layouts: Page breaks, running headers, footers, logos and multi-section packs usually need either a dedicated reporting tool for that subset or an accepted new layout agreed with the business owner.
- PDF output: Test dashboard PDFs in the target version for fonts, page size, chart rendering and how long each page takes to generate.
- Template ownership: Decide who maintains any custom report output after cutover, because a developer may still be needed for it.
Compare a complete export from each report used for regulatory, board or customer packs with the original, using identical parameters and date ranges.
Web Intelligence scheduling sends documents to recipients in set formats, with prompts and conditions defined by the publisher. In Metabase, scheduled delivery is handled through subscriptions, and recipients can receive results by email or other configured channels. In Superset, alerts and reports send dashboards or charts on a schedule. The Superset architecture documentation notes that alerts and reports depend on the caching layer and worker components, and most installations use Redis and Celery for them.
- Recipients and channels: Map who receives each schedule, through which channel, and whether recipients need their own data permissions to see the content.
- Added infrastructure: Superset scheduling requires Redis and Celery workers, which are additional services to operate, monitor and back up.
- Prompts and filters: Scheduled runs that relied on prompts need default filter values or a documented alternative, and the behavior should be verified in the target.
- Failure handling: Test what happens when a source is late or a query fails, and confirm who is notified.
Run each schedule in staging for several cycles and confirm that delivery times, formats and recipient lists match the current BusinessObjects schedules, and confirm which Metabase edition includes the delivery options you need.
Running Web Intelligence and the new tool side by side
Most teams keep Web Intelligence running for documents that still depend on universe logic while new ad hoc questions move to Metabase or Apache Superset. The practical question is not whether both tools can coexist, since they can read the same underlying databases, but which definition of a metric, join or filter is authoritative when both produce a number. Start by listing the Web Intelligence documents that users open each month and marking those whose results depend on universe joins, aggregate awareness or prompts. Those documents stay on BusinessObjects until a replacement is validated. Everything else becomes a candidate for the new tool.
Reading the same databases from two BI layers creates a duplicate logic risk. A revenue figure defined once in a universe and again as a Superset dataset metric, or as a Metabase model, will drift the first time someone changes a filter on one side only. Confirm which database accounts each tool uses, whether the new tool connects through a supported driver for your source system, and whether the source system's own connector support has been checked for the version you run. Do not assume a connector exists for a SAP-specific source without confirming it with the vendor or in your own test environment.
Assign an owner to each definition before anyone builds a new query. A workable rule is that the BI platform team owns shared measures that appear in executive or regulatory reporting, while business analysts own exploratory definitions in the new tool and must reference the shared measure rather than copy its SQL. Record the owner, the source of truth and the tool that publishes each measure in a short register, and review that register at each reconciliation. Reconcile totals for a sample period between the two tools before retiring any Web Intelligence document, and treat any unexplained difference as a blocking defect until someone has traced it.
How to migrate Web Intelligence users and their queries
The sequence moves Web Intelligence documents and the universe definitions behind them into Metabase or Apache Superset, with a pilot group confirming results before any document is retired.
Inventory Web Intelligence documents and usage
The BI platform administrator lists every Web Intelligence document, its owner, its folder and its last refresh or view, using the platform's audit and usage reporting. Business owners then mark which documents are still needed, which are duplicates and which are abandoned. Confirm the export method and audit data available in your BI 2025 environment with SAP before relying on it. The step is done when each retained document has a named owner and a business purpose written against it.
Map each document to its universe
For each retained document, the BI developer records which universe it uses, which classes and objects it pulls, and which joins, filters and prompts it depends on. Many documents share one universe, so grouping by universe shows the real rebuild scope. Note any calculated objects, aggregate awareness or security restrictions in the universe, because these must be re-expressed in the new tool. The output is a dependency table linking documents, universes, objects and owners.
Rebuild business definitions as models or datasets
In Metabase, the analytics engineer rebuilds the universe's business meaning as models with defined columns, joins and descriptions, so business users can query them in the query builder. In Apache Superset, the same work produces datasets with virtual SQL where needed, plus saved metrics and calculated columns. Test each rebuilt definition against a known figure from the original document, and record any difference and its cause. The step is done when each key business number reconciles or has a documented reason for the gap.
Stand up and migrate the application database
For Metabase, the platform team runs the embedded H2 database only for evaluation, then uses the load-from-h2 command to move the application database to PostgreSQL or MySQL, using the same Metabase version that last updated the H2 file. For Superset, the team provisions a PostgreSQL or MySQL metadata database, sets a user-specified SECRET_KEY before first start, and configures authentication. Before any upgrade later, back up the application database, and for Metabase reduce a cluster to a single node for major upgrades. The step is done when the tool starts against the production database and a test login succeeds.
Migrate users, groups and permissions
The security administrator maps BusinessObjects groups and folder rights to the new tool's groups and collection or dataset permissions. Confirm which single sign-on, LDAP and row-level controls your chosen edition supports before designing the mapping, since some of these depend on paid plans. For Superset, role mapping from LDAP or OAuth groups is configured through its authentication settings. The step is done when a test user from each business group sees exactly the data their BusinessObjects access allowed.
Test upgrades and configuration in staging
The platform team repeats the install and migration in a staging environment that mirrors production. For Superset, this includes running superset db upgrade and superset init, and checking the upgrade notes for breaking changes between versions. For Metabase, it includes confirming the migration of the application database and checking the version support dates for the release chosen. The step is done when a documented upgrade runbook has been run successfully in staging and the rollback from the backup has been tested.
Pilot with one business user group
A single group that already uses Web Intelligence for recurring analysis runs its real questions on the rebuilt models or datasets for a fixed period agreed with the business owner. Participants compare results against the original documents and log every gap in drill-down, filtering or export. The group also confirms that the formatted outputs they depend on are either reproduced or replaced by an agreed alternative. The step is done when the pilot group signs off on each document in writing.
Retire Web Intelligence documents
Once each document has a signed-off replacement, the owner confirms it can be archived, and the administrator removes scheduled instances and access before deletion. Keep a read-only archive of the document definitions and the universe export for audit and reference, following your records retention policy. The step is done when the inventory shows every document as replaced, archived or deliberately dropped, with the date and approver recorded.
Questions buyers ask about replacing Web Intelligence
What does replacing Web Intelligence with open source cost in components?
The software itself can be free: Apache Superset is Apache-2.0 licensed with no paid edition, and Metabase's Open Source edition is free to self-host with unlimited users and dashboards. The recurring costs sit elsewhere: the servers and database for the metadata store, backups, monitoring, and the people who maintain the platform. If you want Metabase's paid features, the Metabase pricing page lists Starter at $100 per month or $90 per month billed yearly with the first 5 users included, and Pro at $575 per month or $517.50 per month billed yearly with the first 10 users included. Additional users cost $6 (Starter) or $12 (Pro) per month. SSO and row and column level permissions are included only in Pro and Enterprise, so check that before you assume the free edition covers your access rules.
How long does it take to rebuild Web Intelligence queries?
The duration depends on the size and condition of your inventory, so it has to be scoped rather than estimated from a generic number. Start by counting the Web Intelligence documents, the universes they depend on, and how many are still used. Documents with many queries, complex filters, or multi-query structures take longer to recreate as Metabase questions or Superset datasets and charts than single-query documents do. Ask any provider to scope the work against your inventory and to state the deliverables and timeline in writing before work starts.
Can our internal BI staff rebuild the queries themselves?
Often yes for simple, well-documented reports, and this is usually the cheapest path for business-owned queries. Metabase's query builder suits users who work from a model, and Superset's SQL Lab suits analysts who are comfortable writing SQL. The harder part is the universe logic: joins, aliases, prompts and security filters that users never saw directly. Someone who knows the universe must document that logic before anyone rebuilds reports. Plan for a few people to own the platform after go-live, including upgrades, which both tools require regularly.
What makes the migration effort go up?
Effort rises with the number of universes, the number of documents that depend on each one, and how much of the logic lives inside the universe rather than in the database. Other drivers include:
- Security mappings, since BusinessObjects groups and row-level restrictions must be rebuilt as Metabase groups and permissions or Superset roles.
- Scheduled distribution and formatted output, which need separate design.
- Data source changes, such as moving from a SAP source to a database that Superset or Metabase connects to directly.
- Validation work, where each rebuilt report is compared with the original numbers before users rely on it.
Do drill-down paths and formatted exports carry over?
Not automatically. Drill-down that follows a universe hierarchy has to be rebuilt as dashboard filters, linked charts or a deliberate drill path in the new tool, and you should test each path with real users. Multi-query Web Intelligence documents usually become several linked questions or charts rather than a single document. Pixel-precise formatted exports, such as paginated layouts from Web Intelligence or Crystal Reports, are a separate question: confirm the export formats each tool supports for your reports before you promise them to finance or regulators.
What should a quote for this work include?
Ask for a written scope that lists the inventory method, the number of documents and universes in scope, and which reports are excluded as retired. The quote should separate one-time work from recurring work. Request the following items:
- Inventory and usage analysis, with the criteria for keeping or retiring reports.
- Rebuild and validation effort per report type, with acceptance criteria.
- Security mapping and testing of access rules.
- Hosting design, backup of the metadata database, and upgrade procedure.
- Training, handover and any ongoing support or retainer, priced separately.
Ask each provider to state what the work does not cover, such as formatted exports or scheduled distribution.
Does DeployOpen scope this replacement before work starts?
Yes. DeployOpen plans, implements, customizes, integrates, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not publish a price list. Ongoing support and upgrades are available as retainers. Your inventory of Web Intelligence documents and universes is the first input to that scoping conversation.
Decisions to settle before rebuilding queries
Rebuilding Web Intelligence queries as Metabase models or Superset datasets forces choices that the old universe answered by default. The four cards below cover who owns definitions, how access rules carry over, where the tool and its metadata database run, and who fixes things when they break.
Who owns semantic definitions
A universe defines joins, measures and filters once, and every Web Intelligence user inherits them. In Metabase, that role falls to models and metrics; in Superset, to datasets and metrics. Decide whether IT or a named business data owner approves each definition before users can build on it. Confirm who signs off changes to revenue, customer count or margin logic, and how that approval is recorded. Without this, users will create competing versions of the same measure.
Mapping row-level security
Universe restrictions and security profiles often decide which rows a user sees, and that logic may not map one to one. Metabase enforces row and column level permissions only on Pro and Enterprise plans, so confirm that requirement against your user count before design starts. Superset maps LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING and needs its row filters defined per dataset. Export the existing BusinessObjects restrictions and test each one with a sample user.
Hosting the application and metadata database
Both tools keep their own metadata in a database. Metabase recommends PostgreSQL for production and ships an embedded H2 database for demos, while Superset is tested with PostgreSQL and MySQL and does not recommend its SQLite default for production. Decide where that database runs, who backs it up, and how a major upgrade will be rehearsed. Alerts, scheduled reports and async queries in Superset also need a caching layer and Celery workers, which adds components to operate.
Support and upgrade ownership
Open-source BI has no vendor queue to call, so the support model must be written down. Confirm who triages a broken dashboard, who applies security releases, and who reads release notes before an upgrade. Metabase publishes end-of-life dates for each version, which sets the schedule your team must meet. Superset requires checking UPDATING.md for breaking changes and a staging test before each upgrade. Decide whether this stays in-house, moves to a retainer or is split between both.
How DeployOpen scopes and delivers a Web Intelligence replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms inside your own infrastructure, including the Metabase or Apache Superset environment that replaces Web Intelligence. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which Web Intelligence documents are actively run, and which universes and objects they depend on
- Agree in writing which query, drill-down, multi-query and export behaviors are in and out of the replacement
- Confirm the data sources, database versions and network paths the new BI tool must reach from your environment
- Record which user groups need ad hoc query building and which only need scheduled or shared views
How we build
- Deploy Metabase or Apache Superset in your cloud accounts, data center or air-gapped network, with the application database on PostgreSQL or MySQL
- Rebuild universe joins and business objects as Metabase models or Superset datasets and metrics, then test results against the original reports
- Map existing BusinessObjects groups to Metabase groups or Superset roles, and configure SSO through your identity provider
- Document the query logic, permissions and configuration so your team can review and change it later
How we hand over
- Provide written documentation of the deployed architecture, configuration keys, backup procedures and upgrade steps
- Walk your administrators and power users through the query builder, SQL editor and dashboard workflows used in your estate
- List reports that were not replicated, such as formatted exports or document-level features, with the agreed alternative for each
- Deliver a runbook for backing up the metadata database and running upgrades in staging before production
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Review each new platform release against its breaking-change notes before applying it to your environment
- Retest key reports and permissions after upgrades, and keep the evidence your internal or external reviewers request
- Confirm with us in writing what support covers, since retainer terms are set out in the agreed scope
