Does self-hosting Apache Superset cost less than SAP BusinessObjects?
Apache Superset carries no license fee. It is released under the Apache License 2.0 and the project has no paid edition, so the cost question moves from a recurring license line to the components you must pay for yourself: infrastructure, the migration of Web Intelligence and Crystal Reports content, and staff time. If you are weighing a BI 2025 upgrade or renewal against a move, your decision rests on comparing a known SAP contract figure with a set of costs you have to estimate. BusinessObjects prices, maintenance terms and any upgrade fees must come from your own SAP contract and order documentation, not from published rates. Ask SAP for the full renewal scope, including the components and user types it covers, before you compare.
On the Superset side, the recurring costs are the servers for the application, the metadata database in PostgreSQL or MySQL, and, for alerts, reports and async queries, the caching layer and Celery workers that the architecture documentation describes. Those are one-time setup and then ongoing hosting, patching and backup effort. Upgrades carry their own work: the upgrade documentation asks you to back up the metadata database, run superset db upgrade and superset init, test in staging and check UPDATING.md for breaking changes. Ask your platform team to estimate those hours per year as a line item, because they recur with every release.
The largest variable is the migration itself. Rebuilding Web Intelligence documents, universe joins and Crystal Reports layouts as Superset datasets and charts is staff work that scales with report count and the number of reports still in active use. Scheduled distribution and formatted exports also need a plan, since they are not a one-to-one match. The net result depends on how many reports you retire, how many users you have and how much rebuild effort your team can absorb. Build a per-report inventory first, then price the rebuild and the ongoing run cost side by side with the SAP quote.
Which cost components change when you move from BusinessObjects to Superset
This table compares each cost component of a BusinessObjects estate with its self-hosted Apache Superset counterpart, marking whether it is one-time or recurring. Read the commercial column against your current contract and the self-hosted column against your own infrastructure and staffing plan. The main takeaway is that Superset removes the software license line, while the server, rebuilding, upgrade and staff costs move to you and must be priced in a written scope.
| Cost component | Commercial side (BusinessObjects) | Self-hosted side (Superset) | One-time or recurring |
|---|---|---|---|
| BusinessObjects licenses and maintenance | Named-user or processor licenses plus annual maintenance, confirmed against your SAP order form | No license fee. Apache Superset is Apache-2.0 with no paid edition | Recurring (commercial); none (Superset) |
| BI 2025 upgrade project | Upgrade from BI 4.3 to BI 2025 with SAP or a partner, scoped per estate | Not required if you move to Superset, but the reporting inventory and cutover still need effort | One-time |
| Servers and hosting | SAP-supported BI server tiers in your data center or cloud account | Virtual machines or Kubernetes nodes for web, worker and beat processes in your own cloud or data center | Recurring |
| Metadata database and caching layer | Included in the BusinessObjects repository and CMS setup | PostgreSQL or MySQL for metadata, plus Redis for caching, alerts, async queries and thumbnails | Recurring (infrastructure), one-time (setup) |
| Report and universe rebuilding | Largely sunk for existing Web Intelligence documents, universes and Crystal Reports | Rebuilding universe joins and objects as Superset datasets, metrics and dashboards; effort depends on report count and complexity | One-time |
| Support and upgrades | SAP support contract and planned BI version upgrades | Your team or a retained partner applies Superset releases, runs db upgrade and init, and tests in staging | Recurring |
| Staff time and operations | Existing BI administrators for the CMS and servers | Platform engineers for hosting, backups, SECRET_KEY management, security patching and access mapping | Recurring |
| Training | Vendor courses and internal training on Web Intelligence and universe design | Training for analysts on SQL Lab and charts, and for administrators on Superset operations | One-time, with refreshers |
What moves the cost comparison most
Six drivers decide whether a self-hosted Superset estate costs less than BusinessObjects over several years. Each one moves a specific cost component, so the quote you request should price them separately rather than as a single migration figure.
User count and access model
BusinessObjects is licensed per named or concurrent user, so the number and type of users is the first line of the current bill. Superset has no per-user fee, which shifts cost into identity integration, hosting capacity and support hours. Check how many people actually log in each month, which groups need edit rights, and whether access will be granted through LDAP or OAuth group mapping. Superset maps directory groups to roles with AUTH_ROLES_MAPPING, and that configuration work is a one-time effort your implementer should price.
Number of reports and universes to rebuild
The rebuild is usually the largest one-time cost. Each Web Intelligence document, Crystal Report and universe join or object must be inventoried, pruned and recreated as a Superset dataset, metric or chart. Many estates contain reports nobody opens, so retiring them early reduces the rebuild line directly. Ask the quote to break effort down by report family and by universe, and to state which reports are excluded.
Data volume and query load
Heavy dashboards against large warehouses drive compute costs on the database side, which you pay whether or not the BI tool is licensed. On the Superset side, query load determines how much the caching layer and metadata database must be sized for. Measure your current peak concurrent queries and the largest tables that reports scan, then ask the quote to size those components explicitly.
Alerting and scheduled delivery needs
Alerts, scheduled reports and dashboard thumbnails depend on the caching layer and Celery worker and beat processes in Superset, and most installations run Redis and Celery for them. BusinessObjects scheduling and bursting is a licensed feature of the platform, so self-hosted delivery adds components to operate, monitor and patch. If you need uptime for scheduled distribution, price a highly available worker set and the on-call effort it implies. Formatted exports that Superset does not replicate may need separate work.
Team SQL and Python skills
Superset is built around SQL Lab, a chart builder and a semantic layer defined as datasets and metrics, which means analysts with SQL skills can maintain it directly. If your BusinessObjects estate relies on universe designers who understand the semantic layer, that skill set must be retained, retrained or contracted. Estimate who will own datasets after go-live and whether that work sits with your staff or with a retained support arrangement.
SAP source connectivity
Whether BusinessObjects connects to SAP data sources natively determines whether a connector must be found or built for Superset. Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, so SAP systems exposed through a supported database or a replicated warehouse are straightforward. Direct access to SAP application-layer data may need a custom integration. Confirm your SAP source types and whether they reach the BI tool through a database interface before requesting a quote.
How to build the comparison with your own numbers
This sequence turns a vague renewal conversation into a three-year total cost model built from your own contract, report inventory and written quotes, so each figure can be traced to a source you hold.
Inventory reports and measure real usage
Your BI platform administrator exports the full list of Web Intelligence documents, Crystal Reports, universes, scheduled instances and dashboards from the BusinessObjects CMC or audit logs, along with owners and last-run dates. Business owners then mark each item as business critical, periodic, or retired. The step is done when every item has an owner, a usage figure from the logs, and a keep, rebuild or retire decision. Do not estimate usage from memory; if audit history is incomplete, record that gap as an open item.
List SAP licenses and maintenance from the contract
Procurement and finance pull the current SAP order forms, license metrics, named-user counts, support and maintenance terms, and renewal dates for BusinessObjects and any related SAP components. Record each line item as a recurring fee, a one-time fee or a term commitment, and note the currency and notice periods. The output is a single licensing ledger that states the contract's own figures. If a line item cannot be traced to a signed document, flag it and confirm it with your SAP account team before using it in the model.
Price the BI 2025 upgrade path against replacement
Ask SAP for a written quote covering the BI 2025 upgrade, including licenses, any new maintenance terms, and the services needed to move the existing system. In parallel, ask for quotes from implementation partners for replacing the estate with Superset, including what is in and out of scope. Put both quotes side by side with the same time horizon and the same report inventory as the basis. Confirm with SAP which BI 2025 maintenance commitments apply to your edition before you compare renewal lines.
Size the Superset stack by component
Your platform engineers size the self-hosted Superset deployment by component: the metadata database (PostgreSQL or MySQL, not the SQLite default), the optional caching layer, and the Celery worker and beat processes needed for alerts, reports, async queries and thumbnails. Include the application servers, backup storage for the metadata database, and separate environments for staging and production, since upgrades should be tested there first. The output is an infrastructure bill of materials from your own cloud or data center rates, with the database and worker sizing written down as assumptions to validate in a proof of concept.
Estimate rebuild effort per report class
Group the inventory from step one into classes such as simple tables, formatted reports, universe-based queries, scheduled distributions and dashboards. For each class, estimate the analyst and engineer hours needed to rebuild a representative sample, then extrapolate using the counts from your inventory. Mark where data model work, such as rebuilding universe joins as Superset datasets and metrics, is a larger effort than the report itself. Record the hours as your own estimates with the sample that supports them. The output is an effort table by class that a reviewer can challenge line by line.
Add support, staff time and parallel running
Add the recurring costs that are easy to miss: platform administration time, security patching, upgrade testing against the upgrade documentation, vendor or partner support if you buy it, and the time business users spend validating rebuilt reports against the old ones during parallel running. Also include training and change management. Ask any implementation partner to itemize support, upgrade and retainer fees in the written scope. The output is a list of recurring and one-time staff and service costs, each with a named owner and the quote or internal rate it came from.
Model the three-year total and test the assumptions
Build a spreadsheet with one row per cost component and three yearly columns, separating one-time costs (migration, rebuild, initial setup) from recurring costs (licenses, maintenance, hosting, staff). Run two scenarios: the BI 2025 path and the Superset path, each with the same inventory and time horizon. Change the largest inputs, such as rebuild hours and staff rates, to see which assumptions drive the result. Have finance and the BI owners review it. The step is complete when every cell links to a contract line, a quote, an internal rate or a named estimate, and no figure rests on an unsourced number.
What the BI 2025 upgrade project adds to the BusinessObjects side
Staying on BusinessObjects is not a standing cost. It is a project. Teams that keep the platform must plan a BI 2025 upgrade with its own servers, test environments, regression testing of universes and reports, and a cutover window. BI 4.3 leaves mainstream maintenance on 31 December 2026, and BI 2025 carries maintenance to at least 2031. That gives a clear end date for the current release, but it does not remove the upgrade work from the budget. Ask SAP or any implementation partner to quote the upgrade as separate line items: license or maintenance changes, infrastructure for the new environment, installation and configuration, universe and report regression testing, user acceptance, cutover and hypercare. Ask which of these assume your current report count and which assume a reduced inventory.
The most expensive question is whether you will still need BI 2025 in three years. Upgrading every report and universe before deciding which ones the business uses means paying to move content that may be retired during the migration. A replacement path changes the order of work. Run the reporting inventory first, retire unused documents, and then decide which remaining reports justify a BI 2025 upgrade and which should be rebuilt in Apache Superset. Illustrative example: if a large share of scheduled reports has had no viewers for a year, those reports should not enter the upgrade test plan at all.
Before accepting any upgrade quote, confirm two things with the vendor and in your own environment. First, which BusinessObjects components, such as the Central Management Server, Web Intelligence processing and scheduling, are in scope, and what the vendor assumes about your server sizing. Second, what happens to your existing universes and scheduled instances during the move. Document the answers alongside the cost of a parallel run, so that the upgrade option and the replacement option are compared on the same scope and the same date.
How the Metabase figures change the picture
The Open Source edition of Metabase is free to self-host, and the published pricing page lists it with unlimited users and dashboards. The cost you carry is the infrastructure, the application database, and the staff time to install, patch, back up and upgrade the service. Because the plan has no license fee, the recurring cost is almost entirely your own operations.
- Price: Free, according to the Metabase pricing page.
- Users: Unlimited users and dashboards.
- Authentication: Google sign-in and LDAP are included, but JWT, OIDC, SAML and SCIM provisioning are not.
- Row and column permissions: Not included, so access control must be designed around groups and collections.
- Support: No vendor support is included in this plan.
Before you rely on this tier, confirm with Metabase which authentication path your identity provider needs and whether group-based access alone meets your data access rules.
The Starter plan is the lowest paid tier. The pricing page lists $100 per month, or $90 per month billed yearly, with the first 5 users included. Additional users cost $6 per month each, so cost rises with headcount in a way the Open Source edition does not.
- Price: $100 per month, or $90 per month billed yearly, per the Metabase pricing page.
- Included users: The first 5 users are included.
- Additional users: $6 per month each beyond the included users.
- Included features: Support is added, along with Google sign-in and LDAP, which the Open Source edition also provides.
- Excluded features: SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are not included.
At the Starter tier, a team with more than a handful of users should compare the per-user charge with the one-time effort of running Superset's own user and role model.
The Pro plan adds the controls that regulated teams most often ask for. The pricing page lists $575 per month, or $517.50 per month billed yearly, with the first 10 users included and $12 per month for each additional user. SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing sit at this tier and above.
- Price: $575 per month, or $517.50 per month billed yearly, per the Metabase pricing page.
- Included users: The first 10 users are included.
- Additional users: $12 per month each.
- Security features: SSO, row and column level permissions, and auditing are included.
- Identity features: JWT, OIDC, SAML with documented setups, advanced LDAP group sync and SCIM provisioning are included.
If you need these controls, the annual Pro cost is a recurring line item that Superset does not carry, since Superset has no paid edition and implements its own access controls.
The Enterprise plan is priced by quote, and the pricing page states it starts at $20,000 per year. It is the only Metabase tier that offers air-gapped deployment, which matters for networks with no outbound connectivity. Enterprise pricing depends on scope, user count and support terms, so treat the starting figure as a floor rather than a budget.
- Price: Quote-based, starting at $20,000 per year, per the Metabase pricing page.
- Air-gapped deployment: Available only on Enterprise.
- Included features: All Pro features plus the Enterprise deployment options.
- Quote drivers: Expect pricing to depend on user count, deployment model and support level.
- Comparison point: Superset has no paid edition, so its licensing line is zero, but staff and infrastructure costs remain.
Ask Metabase for a written quote that states the user count, deployment model, support terms and any air-gapped requirements before comparing it with the operating cost of a self-hosted Superset estate.
Questions buyers ask before hiring help with the cost model
How much does a migration from BusinessObjects to Apache Superset cost?
No supplied figure exists for a Superset migration, so the honest answer is that cost follows the written scope, not a fixed number. The main drivers are how many Web Intelligence documents, Crystal Reports and universes are still in use, how many of them need rebuilding as Superset datasets and charts, how many source databases sit behind them, and how much scheduled distribution must be replaced. Ask for a quote that prices each of these separately, so you can see which items move the total up or down before you agree to the scope.
How long does a BusinessObjects to Superset project take?
No researched duration is available, so treat any timeline as something to confirm in writing rather than assume. Duration depends on the reporting inventory, the number of reports that survive the usage review, the complexity of universe joins and the amount of formatted output that must be recreated. Parallel work on the Superset platform itself, including the metadata database, authentication and the caching layer, can run alongside report rebuilding. Ask for milestones tied to report groups, so progress is visible and you can stop after the highest-value reports if priorities change.
What does our team need to do internally during the migration?
Your team supplies the business knowledge that no external party can infer: which reports are actually used, who owns each metric, which figures finance or regulators rely on, and who approves the cutover. Your data owners also need to confirm source database access, service accounts and the rules that control row-level visibility. Plan for reviewers to check rebuilt reports against the BusinessObjects output during a parallel run. Ask the provider to name these internal roles in the written scope so the dependencies are agreed before work starts.
Can we run the Superset migration ourselves instead of hiring help?
Yes, Superset is licensed under Apache-2.0 and has no paid edition, so the software itself carries no license fee. The work you would take on is the platform build (metadata database, authentication, caching and workers), the rebuild of each report, security configuration, backups and upgrades. Upgrades require backing up the metadata database, running superset db upgrade and superset init, testing in staging and checking UPDATING.md for breaking changes. Be realistic about staff time: a team that has not run Superset before should estimate its own effort against the scope in the table below before deciding.
What recurring costs remain after go-live?
Once Superset is live, the recurring costs are infrastructure (application servers, a PostgreSQL or MySQL metadata database, and Redis and Celery workers if you use alerts, reports or async queries), monitoring, backups, security patching, and the upgrade effort that follows each Superset release. Support is the other recurring line, whether it is internal staff time or a retainer with an outside provider. The BusinessObjects license and maintenance fees end only when the platform is retired, so ask for a decommissioning date in the plan. Review these costs annually so they stay visible next to the old license line.
What should a quote for the migration include?
A useful quote lists the scope in writing: the reporting inventory and usage review, which BusinessObjects documents and universes are in and out, the number of Superset datasets, dashboards and charts to rebuild, how scheduled distribution and formatted exports will be handled, and what is excluded. It should separate one-time items (discovery, rebuild, testing, cutover, documentation) from recurring items (hosting, support, upgrades) and state the acceptance criteria for each deliverable. Ask who pays for infrastructure, who owns the source code and documentation, and how changes to scope are priced. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes a fixed-price Superset implementation
DeployOpen plans, implements and hands over self-hosted Apache Superset inside your own cloud accounts, data centers or air-gapped networks, starting from a written scope. The scope sets which BusinessObjects reports, universes and data sources are in, what the cost comparison needs from your licensing records, and what the handover covers.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The scope lists which Web Intelligence documents, Crystal Reports and universes are migrated, retired or left in place.
- We ask for your current BusinessObjects license, maintenance and BI 2025 upgrade quotes so the cost comparison uses your real figures.
- The written scope names the databases Superset will connect to and the authentication source it must use.
How we build
- We deploy Superset with PostgreSQL or MySQL as the metadata database, following the upstream architecture guidance.
- Caching, Celery workers and Redis are sized for the scheduled alerts and reports your scope actually requires.
- Universe joins and objects are rebuilt as Superset datasets, metrics and dashboards, and tested against existing report output.
- Authentication is wired to your OAuth2 or LDAP source, with AUTH_ROLES_MAPPING translating your existing groups into Superset roles.
How we hand over
- Deliverables include the deployment, configuration, dataset and dashboard inventory, and the access model documented in writing.
- Runbooks cover the upgrade path: backing up the metadata database, running the documented upgrade commands, and testing in staging first.
- Your team receives the cost-of-ownership worksheet, so recurring costs for hosting, staff time and support are visible to the budget owner.
- Handover sessions walk your administrators through secret key rotation, backups and reading the upstream UPDATING.md notes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover applying Superset releases to staging, reviewing breaking changes and running the upgrade in production.
- Ask any provider to confirm in writing which upgrade, backup and incident response tasks are included in the retainer scope.
- Security testing of the deployed Superset instance can be scoped separately as part of the same written agreement.
