Migrate from SAP BusinessObjects to Apache Superset

Migrate from SAP BusinessObjects to Apache Superset: what the move involves

If your BusinessObjects estate is facing renewal or an upgrade decision and you want to self-host, plan for a rebuild of semantic models and report logic, not a file copy. Web Intelligence documents, Crystal Reports and universes do not load into Apache Superset. Each universe's joins, objects and filters have to be recreated as Superset datasets, metrics and dashboards against your databases. Effort depends mostly on how many documents are still used and how much of the estate depends on scheduled distribution and formatted output. Start by inventorying usage so you rebuild only what the business still reads.

Most teams do this work with an internal BI team supported by an implementation partner, since the hard part is business logic: metric definitions, row-level access and reconciliation against the figures people already trust. Apache Superset is licensed under Apache-2.0 and maintained at the Apache Software Foundation, and the project has no paid edition, so the software itself carries no license fee. Your recurring costs will be the infrastructure, including a metadata database, caching and Celery workers for alerts and reports, plus the people who operate and change the platform. Confirm those components against the Superset architecture documentation before you size the environment.

The main risk is output parity. Superset does not replicate every BusinessObjects output format, so pixel-perfect Crystal Reports, some bursting and certain formatted exports need a decision: rebuild them in a different form, keep a small number of reports elsewhere, or accept the change with the report owners. Confirm with your business owners which outputs are contractual or regulatory before you commit to a date, and pilot scheduled distribution early, since that is where the rebuild is most likely to surprise you.

Which BusinessObjects capabilities map to Superset, and which need rework

This table compares the main BusinessObjects capabilities with their closest Apache Superset equivalents and marks each row as clean, needs rework or gap. Use it to scope rebuild effort, then confirm each behavior against the Superset version you plan to deploy, because features in the scheduling and export areas change between releases.

Capability	BusinessObjects	Apache Superset	Status and what to confirm
Semantic layer	Universes with joins, objects and conditions	Datasets with virtual SQL, calculated columns and metrics	Needs rework: joins and business logic must be rewritten as SQL or dataset definitions. Confirm metric behavior against your target database dialect.
Ad hoc reporting	Web Intelligence documents built on universe objects	Charts on dashboards and SQL Lab for SQL-literate users	Needs rework: business users lose the drag-and-drop universe query builder. Plan training or a curated dataset set.
Formatted reports	Crystal Reports pixel-perfect layouts, grouped sections and printed output	Dashboards and charts, with no direct equivalent to pixel-perfect print layouts	Gap: print-precise Crystal layouts usually need redesign or a separate document tool. Confirm PDF or image export options in your version.
Scheduled distribution	Scheduled instances sent to recipients and folders	Alerts and reports sent on a schedule, using the caching layer and Celery workers	Needs rework: the reports feature depends on worker components and a mail or messaging channel. Confirm delivery formats and recipient limits for your release.
Drill-down and multi-query documents	Drill paths and multiple queries in one document	Dashboard filters, cross-filtering and separate charts	Needs rework: multi-query documents become several datasets or one dashboard per view. Test each drill path with users.
Security and access	Universe and document security via BI groups and folders	Roles and permissions, with LDAP or OAuth groups mapped through AUTH_ROLES_MAPPING	Needs rework: map groups to roles and row-level rules to dataset filters. Confirm role behavior with your identity provider and test each role.
Authentication	Enterprise authentication through SAP BI platform	Database, LDAP and OAuth2 authentication through Flask-AppBuilder	Clean for common identity providers. Confirm LDAP and OAuth2 group claims in staging before cutover.
SAP data source connectivity	Native connectors to SAP HANA and SAP ERP sources	SQLAlchemy and DB-API drivers for the database behind the SAP source	Gap for native SAP connectivity. Confirm driver availability, licensing and extraction approach for each SAP source with your vendor.

What moves cleanly and what does not

The data source question is usually the first gate. Apache Superset connects to any SQL datastore that has a Python DB-API driver and a SQLAlchemy dialect, so a BusinessObjects universe that sits on a relational database can usually be pointed at the same tables, views or schemas from Superset. The harder case is a universe built on a source that has no such driver or only offers a vendor-specific connection, or a universe that depends on SAP-specific connectivity. Before any rebuild starts, confirm for each universe which database sits underneath, whether a maintained driver and dialect exist for that version of it, and whether the service account the universe uses can be granted equivalent read access. Confirm these with your data platform team and the Superset database connection documentation for your target version, not from memory.

SQL logic, joins and dashboard layouts reproduce well; pixel-perfect output does not. The business logic inside a universe, meaning its joins, aliases, derived objects and filters, can usually be written as SQL views or Superset virtual datasets and then charted in dashboards. That is where most of the effort goes, and it is effort that also cleans up undocumented logic. Crystal Reports layouts with exact page breaks, grouped headers, cross-tabs with fixed column positions and print-ready formatting are different. Superset dashboards are designed for interactive screens, and scheduled PDF or CSV output does not replicate Crystal's pixel-level layout. Multi-query Web Intelligence documents, where several data providers are combined in one document, usually need to be split into separate datasets or redesigned as a single consolidated query. Plan a parallel period for these reports, or accept a redesign, and record which outputs your auditors or regulators require in their original form.

Migration sequence from inventory to decommission

This sequence moves a BusinessObjects estate to Apache Superset in controlled stages, so that every report kept has a documented owner, a rebuilt dataset, reconciled numbers and a confirmed schedule before BusinessObjects is switched off. Each step ends with a named artifact that the next step depends on.

Inventory Web Intelligence, universes and Crystal reports
Export a full register of every Web Intelligence document, Crystal Reports file, universe and connection in your BI 4.x environment, using the BusinessObjects administration tools and the repository exports your platform team can produce. Record each item's owner, source database, refresh schedule, distribution list and the universe it depends on. The step is complete when the inventory register accounts for every object in the CMC and can be reconciled against the repository counts. Ask your SAP partner or platform team to confirm which exports are available in your version before work starts.
Decide what to keep using usage data
Pull access and refresh history from the BusinessObjects audit repository, then classify each report as actively used, used occasionally, or unused. Send the candidate list to the named business owners and ask them to confirm, retire or merge each report with a written decision. The output is a keep-retire-merge decision log with an owner signature per line, which becomes the scope baseline for every later step. Unused reports should not be rebuilt at all, and the log is what you point to when a stakeholder asks why something was dropped.
Pilot the universe-to-dataset rebuild
Choose a small set of high-value reports that cover the common universe patterns, such as a multi-table join, a context-dependent measure and a prompt-driven filter. Rebuild the underlying joins and business objects as Superset datasets, with metrics defined in the dataset layer and charts or dashboards built on top. Document each mapping from universe object to dataset column or metric in a rebuild specification. The pilot is done when a reviewer can trace every universe object used by the chosen reports to a Superset dataset element, and the team agrees the pattern can be repeated.
Run a parallel period with reconciled numbers
Run the rebuilt Superset content alongside the original BusinessObjects reports for the same reporting periods. Compare row counts, totals, filter results and rounding for each report, and log every difference with its cause in a reconciliation log. Differences caused by source timing, time zones or known defects should be recorded and signed off by the report owner, not silently absorbed. The step closes when every kept report has a reconciliation entry marked accepted by its owner. Confirm the length of the parallel period with your business owners, since the researched facts do not set one.
Rebuild schedules, alerts and formatted outputs
Identify every scheduled distribution, bursting job and formatted export that the register flagged, and decide how each is replaced. Superset supports alerts and reports, but it does not replicate every BusinessObjects scheduling or pixel-perfect formatted output, so record any gap as a named exception with an agreed workaround or a business acceptance. Superset's alerts and reports depend on a caching layer and Celery workers, so confirm those components are deployed and monitored before cutover. The output is a schedule replacement matrix that lists each job, its Superset equivalent and the exceptions.
Cut over users, schedules and access
Move access groups first, mapping BusinessObjects groups to Superset roles through your identity provider, then switch the scheduled jobs from the register to Superset on the agreed date. Communicate the new URLs, provide short guidance for the users who built their own Web Intelligence queries, and keep BusinessObjects read-only during the transition. The cutover is complete when the schedule replacement matrix shows every job running in Superset and an owner has confirmed each user group can reach its content. Prepare a rollback step for each scheduled job in the cutover runbook.
Decommission BusinessObjects and archive evidence
After the agreed stabilization period, export the final BusinessObjects content and metadata to archival storage that your records and retention policy requires, then shut down the BI servers and remove the related licenses through the contract process. Retain the inventory register, the decision log, the reconciliation log and the cutover runbook as the migration record. Confirm the retention requirements with your compliance and legal teams, because they determine how long the records must be kept. The step is done when the servers are off, the archive is verified and the license termination is confirmed in writing.

Data, metadata and integrations to rebuild

Reports are only part of a BusinessObjects estate. The universe definitions, the user and group model, and the infrastructure behind scheduling all have to be rebuilt or replaced before Superset can serve the same audience. Each card below is a component to inventory and confirm early in the project.

Universe definitions and join logic

A universe holds the business objects, joins, aggregate awareness and conditions that Web Intelligence and Crystal Reports depend on. Export what your BusinessObjects version supports, typically the universe definitions and the SQL behind each document, then document every join and filter by hand. Superset does not import universes, so each join becomes a dataset or a virtual dataset in SQL Lab, and each object becomes a column or metric. Confirm which export formats your BI version provides before you plan the extraction work.

User and group mappings to roles

BusinessObjects security sits in users, groups and security conditions that also restrict rows. Superset controls access through roles and permissions, and it can map LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. Build a table that maps each BusinessObjects group to a Superset role, then list which data restrictions must be rebuilt in the database or as row-level filters. Verify the mapping with a test user from each group before cutover.

Metadata database selection

Superset stores dashboards, charts, datasets, users and roles in a metadata database. The supported options are PostgreSQL and MySQL, with PostgreSQL 10 to 17 and MySQL 5.7 and 8.x listed in the configuration documentation. The SQLite default and the Docker Compose PostgreSQL container are not recommended for production. Plan backups of this database as part of the migration, because the upgrade process starts with a backup of the metadata database.

SECRET_KEY and configuration hygiene

Superset will not start without a user-specified SECRET_KEY, a requirement added in version 2.1.0. Store the key in your secrets manager, not in a checked-in configuration file. The configuration documentation also describes rotating it with PREVIOUS_SECRET_KEY, which lets existing sessions and encrypted values survive a change. Record who owns the key and how it is rotated, because losing it can break access to stored database connections.

Caching and worker components

Alerts and reports, async queries and dashboard thumbnails need the caching layer and Celery worker and beat processes, and most installations use Redis and Celery for them. BusinessObjects scheduling and bursting have no direct equivalent in a bare Superset install, so the scheduled report list from your inventory decides whether you need these components on day one. Size and monitor the worker tier as its own service, and confirm the delivery channels your distribution list requires.

Connectivity to source databases

Universes point at databases through connection definitions stored in the BI platform, and those credentials do not move automatically. Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, so confirm that every source database used by your universes has a supported driver. Create service accounts with read-only permissions, store their credentials in a secrets manager, and test each connection from the Superset host before rebuilding dashboards on it.

Running BusinessObjects and Superset in parallel without double-counting truth

A parallel run works only when every report has one named owner and one agreed source of truth for the overlap period. Pick a fixed window, select the reports that carry financial, regulatory or board-level figures first, and have both platforms answer the same questions against the same data cut. Record the BusinessObjects output, the Superset output and the difference for each report in a shared reconciliation log, with the owner signing off each variance. Expect differences from join logic, rounding, time zones and filter defaults that were inherited from the universe, and decide in advance which platform is the reference for each metric. Without that rule, two dashboards showing different totals will both be quoted in meetings and nobody will know which number to trust.

The new platform needs the same operational discipline as the old one. Superset cannot start without a user-specified SECRET_KEY, so the key must be generated, stored in your secrets manager and never left at a default value. Keep a PREVIOUS_SECRET_KEY plan for rotation so that a key change does not break saved sessions or stored credentials. Back up the metadata database before every change, because dashboards, saved queries, datasets, alert definitions and role mappings all live there. Run superset db upgrade and superset init in staging against a copy of production metadata, and check the release notes in UPDATING.md before each version change. Confirm with your platform team which environment will hold the reference copy of the metadata database during the parallel period. Treat cutover as complete only after those staging tests pass and the reconciliation log shows no open variance on the reports in scope.

How the migration differs by estate size and starting point

A small BusinessObjects estate usually has a handful of universes, a few dashboards and reports that a small group of people open regularly, and little Web Intelligence authoring outside a central team. In this situation the inventory is quick to finish, and the migration is mostly a question of deciding which content is still needed and rebuilding it as Superset datasets and charts. The main effort sits in the modeling decisions, not in volume.

Scope: List every universe and document, then mark which ones have been opened in the last usage period you can export from the BI platform. Retire the rest before any rebuild starts.
Sequencing: Rebuild the universes that feed the most-used reports first, because their joins and metrics become the shared Superset datasets the other charts reuse.
Hosting: A single Superset node with PostgreSQL metadata may be enough for a small user group, but the Superset architecture documentation says the default SQLite and Docker Compose PostgreSQL setups are not recommended for production, so plan a proper metadata database.
Scheduling: Count how many scheduled reports exist. A few can often be replaced with Superset alerts and reports, which depend on the caching layer and Celery workers.
Ownership: Name one owner who signs off each rebuilt dashboard against the original figures.

Before starting, confirm with your own users which reports they really read, since small estates often hide long-unused content.

What drives cost and duration, and how to keep each down

This table lists the factors that change the effort and cost of moving BusinessObjects reports to Apache Superset, why each one matters and how to reduce it. Read it before requesting a quote, because the largest savings usually come from retiring unused documents and universes before any rebuilding starts.

Driver	Why it changes cost or effort	How to keep it down
Active universes and documents	Each Web Intelligence document and Crystal Report usually needs its own rebuild or retirement decision, so the count sets the bulk of the work.	Pull usage logs from the BusinessObjects audit repository and retire documents nobody has opened in your agreed window before scoping.
Universe complexity and join depth	Deep joins, context loops and derived objects must be re-expressed as Superset datasets, virtual datasets and metrics, which takes more testing per object.	Simplify universes during migration, and rebuild shared metrics once in a governed dataset rather than per dashboard.
Scheduled and formatted outputs	Superset alerts and reports cover scheduled delivery, but BusinessObjects bursting, formatted PDF and Excel layouts and distribution lists may need custom work or a different output approach.	Inventory every schedule with its recipients and format, then mark which outputs can become Superset dashboards and which need a documented exception.
Data source count	Each source needs a SQLAlchemy dialect and Python DB-API driver, connection testing, credential handling and query tuning for dashboard workloads.	List every connected database, confirm driver availability for each, and consolidate sources where the business logic allows.
Security model complexity	BusinessObjects security combines users, groups, row-level security and object rights, and these must map to Superset roles, datasets and row-level filters through AUTH_ROLES_MAPPING and OAuth or LDAP groups.	Export group memberships and document the rules before design, and reduce the number of custom roles to the smallest set that matches access needs.
Parallel run length	Running BusinessObjects and Superset side by side keeps two sets of licenses, servers and report owners active, and reconciling numbers between them takes time.	Set a fixed reconciliation window per report group, agree exit criteria in writing, and decommission reports as each one passes.
One-time versus recurring costs	One-time work includes inventory, rebuilding, testing and staff training. Recurring costs include hosting the metadata database, caching and worker layer, support retainers and upgrade effort.	Ask each quote to split fixed-scope migration fees from ongoing support, and to state which infrastructure items recur after cutover.

Questions buyers ask before migrating BusinessObjects to Superset

Can we migrate from BusinessObjects to Superset in-house?

Yes, many teams do the work with their own staff, and the answer depends on whether you have people who know SQL, your data warehouse and the business logic inside your universes. The main drivers are the number of Web Intelligence documents and Crystal Reports in active use, how many universes hold join logic and custom objects, and whether your team has run a Python-based web application before. Superset installation itself is a small part of the effort. Most of the time goes into inventorying reports, rebuilding datasets and metrics, and reconciling numbers with the business. If internal capacity is limited, ask an implementation partner for a fixed-scope proposal that separates the inventory, rebuild and operations work so you can compare it with an in-house plan.

What drives the time and effort of a BusinessObjects to Superset migration?

Effort rises with the number of reports that remain in use after the inventory, the complexity of each universe, and the number of distribution and security rules that must be recreated. A universe with many joins, contexts and derived objects takes longer to translate into Superset datasets and metrics than a simple flat view. Multi-query Web Intelligence documents and Crystal Reports with complex grouping, subreports or exact print layouts also add work. Scheduled delivery, formatted exports and row-level security each add a separate workstream. Ask for the effort to be broken down by report family and by workstream so you can see which assumptions drive the total.

What must our team provide before a Superset migration starts?

Your team must provide read access to the BusinessObjects repository and the list of folders, users and schedules, so that usage can be measured before any rebuild starts. You also need named data owners who can confirm what each key report means, the database credentials or service accounts Superset will use, and a decision on which reports will be retired. Reconciliation sign-off is essential: a business owner should agree in writing which figures must match the BusinessObjects output and what tolerance is acceptable. Without these inputs, rebuilt dashboards tend to be rechecked several times and the schedule slips. Confirm the list of owners and sign-off steps in your written scope.

Can Crystal Reports layouts be reproduced exactly in Superset?

Usually not pixel for pixel. Superset is built around interactive dashboards, charts and SQL Lab, so it reproduces the data, grouping and key metrics of a Crystal Report more readily than its printed layout, page breaks or precise formatting. Reports that are really tabular exports are the easiest to rebuild as tables or exported datasets. Reports that depend on formula-driven headers, grouped subtotals across pages or precise print templates will need either a redesigned output or a document generation tool kept alongside Superset. Decide, per report, whether the business needs the same layout or the same numbers, because that choice changes the effort more than any other.

Does Superset replicate BusinessObjects scheduled distribution?

Superset offers alerts and reports, but it does not replicate every BusinessObjects scheduling and bursting pattern out of the box. Its alerts and reports feature depends on the caching layer and Celery worker components described in the architecture documentation, so these must be deployed, monitored and sized as part of the platform. Bursting to many recipients with personalized filters, and formatted report bundles delivered in the exact BusinessObjects output, need to be tested case by case. Build an inventory of every schedule, recipient group and output format, then mark each as supported, partially supported or needing an alternate delivery path. Confirm the exact behavior of each item in the version you deploy.

What does Apache Superset licensing look like compared with BusinessObjects?

Apache Superset is released under the Apache License 2.0 and has no paid edition, so there is no per-user or per-server software license to buy. Your recurring costs move to infrastructure, including the application, metadata database, caching layer and workers, plus the people who operate and upgrade the platform. BusinessObjects costs typically include licenses, maintenance and the servers and upgrade projects around them. Ask any vendor or partner to show these components separately in the quote, and check whether support, hardening or upgrade work is priced per year or per project. Confirm the license terms and any third-party component licenses with your legal team before you commit.

How do we keep Superset upgrades from breaking reports?

Plan upgrades as a routine change with a staging environment and a documented rollback. The upgrade documentation says to back up the metadata database, run the database upgrade and initialization commands, test in staging first and check UPDATING.md for breaking changes between versions. Pin your version, keep the dataset and metric definitions in version control where possible, and keep a regression set of reports with known good values. Superset also requires a user-specified SECRET_KEY, and supports rotating it with PREVIOUS_SECRET_KEY, so include key handling in your runbook. Ask for an upgrade procedure and a test plan as part of the handover.

What usually goes wrong and how to prevent it

Most failed BusinessObjects migrations fail on things nobody wrote down: universe logic, report ownership, exports and access rules. The cards below name six recurring risks and a prevention step for each, so the inventory and cutover plan catch them before users do.

Undocumented universe logic

Universes often hold join paths, aliases, prompts, filters and calculated objects that exist only inside the .unv or .unx definitions. When these are rebuilt as Superset datasets without a written map, reports return different totals and nobody notices until finance does. Before rebuilding, export each universe's objects and joins, record the business meaning of every calculated measure, and reconcile key reports row for row against the original output.

Scheduled reports with no owner

Scheduled Web Intelligence and Crystal Reports jobs often run for people who left the organization or for distribution lists nobody maintains. Recreating every schedule in Superset copies that waste into a new system. Pull the BusinessObjects scheduling history, assign a named business owner to each recurring report, and retire any job that has not been opened or used in the review window your organization agrees on.

Formatted exports users depend on

Finance and operations teams frequently rely on pixel-precise PDF statements, Excel layouts with fixed cell positions or Crystal Reports bursting to files, and Superset does not reproduce these formats one for one. Treat each formatted output as its own line item in the inventory, decide whether it becomes a Superset export, a tabular CSV or Excel download, or a document generated by a separate reporting tool, and get the output owner to sign off on the new format before cutover.

Security mappings that grant too much

BusinessObjects security combines folder rights, universe restrictions and row-level filters, and migration teams often map them to broad Superset roles to avoid breaking access on day one. That leaves sensitive datasets visible to users who never had them. Map BusinessObjects groups to Superset roles through AUTH_ROLES_MAPPING with the least privilege that matches the old rights, test access with sample users from each group, and review row-level security rules before any user is onboarded.

Upgrading without a metadata backup

Superset stores dashboards, datasets, charts, users and alert definitions in its metadata database, and the upgrade path runs schema changes against it. Teams that skip a backup before running the database upgrade step have no clean way back if the migration fails midway. Back up the PostgreSQL or MySQL metadata database, rehearse the upgrade in staging, read UPDATING.md for breaking changes between versions, and confirm the restore procedure works before touching production.

Cutover without a rollback plan

Switching all report consumers to Superset on a single date leaves no path back when a key dashboard is wrong or a schedule fails silently. Run BusinessObjects and Superset in parallel for the reports still in use, move one business area at a time, and define in writing the conditions that trigger a rollback, who decides and how long the old instance stays readable. Ask your implementation partner to show the rollback steps in the written scope before work begins.

How DeployOpen scopes and runs a BusinessObjects to Superset migration

DeployOpen approaches Migrate from SAP BusinessObjects to Apache Superset as a fixed-scope engagement inside your own infrastructure, starting with an inventory of Web Intelligence documents, Crystal Reports and universes. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.

How we scope

Inventory Web Intelligence documents, Crystal Reports, universes and scheduled instances, with owners and last-run dates.
Agree with report owners which reports stay, merge, retire or move to Superset dashboards and SQL Lab.
Record in writing which scheduling, bursting and formatted export behaviors are in scope and which need a documented alternative.

How we build

Rebuild universe joins, filters and objects as Superset datasets and metrics against the same database sources.
Deploy Superset with PostgreSQL or MySQL as the metadata database, plus the caching and Celery worker components for alerts and reports.
Test rebuilt dashboards against BusinessObjects output on agreed reference data before any user cutover.

How we hand over

Document the deployment, configuration keys, role mappings and the upgrade runbook covering metadata database backup and the upgrade steps.
Map BusinessObjects security groups to Superset roles through the documented group mapping, and record every access decision.
Hand over a report-by-report register showing what was rebuilt, what was retired and what needs a manual process.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrades follow a staging-first routine that checks the breaking-change notes for each Superset release before production.
Confirm support boundaries, response expectations and exclusions in the written scope, not in general terms.

Migrate from SAP BusinessObjects to Apache Superset