Why the BI 4.3 deadline forces a decision about SAP BusinessObjects
A BusinessObjects team with a BI 4.3 estate has to decide before 31 December 2026, when BI 4.3 leaves mainstream maintenance. The deadline is the constraint, and the choice comes down to three options. The first is to upgrade to the BI 2025 release line, which carries maintenance to at least 2031. The second is SAP's managed cloud option, if its scope and data location fit your requirements. The third is to replace the platform with self-hosted Apache Superset or Metabase. Each option has a different cost profile and a different amount of rework, so the decision cannot rest on the license line alone.
The reporting inventory is what separates the options. Count the Web Intelligence documents, Crystal Reports, universes and scheduled jobs that are still in use, and record which data sources each one reads. Ask your BusinessObjects administrator whether auditing is enabled in the Central Management Console, since usage history is the most reliable way to see which reports people open. Then confirm which reports feed regulatory filings, board packs or customer-facing outputs, because those carry the highest cost of a gap. A universe that feeds three live reports is a very different project from one that feeds a single report nobody has opened in a year.
Once the inventory exists, work backward from the deadline. An upgrade needs a test plan, a staging copy of the content and a rollback path, and a replacement needs rebuilt datasets, dashboards and access rules before any cutover. Ask SAP and any implementation partner for written scope, deliverables and dates, and check SAP's own lifecycle documentation for the current maintenance commitments before you rely on them. If the inventory shows that most content is stale, the deadline becomes a reason to retire reports rather than rebuild them. DeployOpen plans and implements self-hosted replacements in the client's own infrastructure under fixed, written scope, but the scope itself should come from the inventory.
What the maintenance deadline requires from your BI estate
BI 4.3 leaves mainstream maintenance on 31 December 2026, so any path, whether upgrade, SAP's managed option or replacement, starts with the same inventory and controls. The cards below cover the items that decide the timeline and the risk, and each one names what to confirm with SAP for your own release and environment.
A supported target release
Choose the target before you plan the project. BI 2025 carries maintenance to at least 2031, so it is the release line the deadline points toward, but the exact upgrade path from your current BI 4.3 patch level, your server operating system and your database versions must be confirmed with SAP for your environment. Record the target build and the path in writing before scheduling any cutover.
Complete Web Intelligence and Crystal inventory
Build a full list of every Web Intelligence document, Crystal Reports file, and the folders and owners behind them, including reports nobody has opened recently. Pull usage logs and mark each item as keep, rebuild, retire or merge. This list drives the scope of any upgrade test or replacement build, so an incomplete inventory is the most common source of later surprises.
Universe and semantic layer mapping
Document every universe, its data foundation, business layer objects, joins, contexts and the reports that depend on each one. These definitions are the logic your users rely on, and they do not move automatically into a self-hosted tool. Confirm with SAP which universe formats and connections your target release supports, and plan to rebuild the semantic logic as datasets or models if you replace the platform.
Identity and group mapping
Map BusinessObjects users, user groups and folder rights to the identity source you will use going forward, such as LDAP, SAML or OAuth-based sign-in. Record which groups grant access to which content, because rights inherited through nested groups are easy to miss. Confirm with SAP which authentication methods your target release supports, and test that a user sees the same content after the change.
Scheduled distribution and bursting
List every scheduled instance, recipient group, output format and destination, such as email, file shares or printed packs. Scheduled jobs often run quietly for years and feed finance or regulatory processes. Confirm which schedules the target release carries over unchanged, and decide who owns each one. If you replace the platform, plan an explicit replacement for every distribution job, including formatted exports.
Data source connectivity and drivers
List every database, ERP or SAP source each report reads, along with the driver, network path and service account it uses. Old drivers and connection strings are a frequent blocker when the platform or operating system changes. Confirm connectivity from the target environment with your database and SAP teams before the cutover, and verify that each source supports the driver you plan to use.
Tested backup and restore path
Take a full backup of the BI content repository and the underlying CMS database before any upgrade, and restore it to a separate test system. A backup that has never been restored is not a recovery plan. Record the restore time, confirm that scheduled jobs and user rights come back intact, and keep the pre-upgrade backup until the new platform has run through a full reporting cycle.
How each option meets the deadline and what it costs in effort
This table compares the BI 2025 upgrade, SAP's managed cloud option, self-hosted Apache Superset and self-hosted Metabase on how each keeps reporting running past 31 December 2026, what must be rebuilt and the main trade-offs. Read it alongside your reporting inventory, because the rebuild effort depends on how many Web Intelligence documents, Crystal Reports and universes you actually run.
| Option | How reporting continues past 31 December 2026 | What must be rebuilt | Main trade-offs |
|---|---|---|---|
| BI 2025 upgrade (on-premises) | Stays on SAP's supported on-premises line, with mainstream maintenance to at least 2031 for BI 2025 | Little or no report rebuild if the upgrade path holds, but content, universes and connections need regression testing | Keeps the SAP licence and maintenance model and the server and upgrade project cost; confirm the licence terms with SAP |
| SAP managed cloud option | Hosted and operated by SAP; confirm the scope, timing and migration path with SAP before planning | Depends on SAP's migration tooling and which content types are in scope; confirm with SAP | Shifts server operation to SAP, but reporting still depends on SAP's licensing and roadmap; ask for the terms in writing |
| Self-hosted Apache Superset | Runs on your own infrastructure under Apache-2.0 with no paid edition, so reporting continues once the cutover is complete | Web Intelligence documents, Crystal Reports and universe joins are rebuilt as datasets, charts and dashboards; scheduled distribution needs its own design | Lowest licence cost, but you own the caching, worker and database components and the upgrade process |
| Self-hosted Metabase | Open Source edition is free and self-hosted with unlimited users and dashboards, so reporting continues once cut over | Reports are rebuilt as models, questions and dashboards; SSO and row-level permissions need the Pro or Enterprise plan | Free core, but SSO and row-level security require a paid plan; Metabase 64 is LTS with end of life on 1 December 2027 |
Which path fits which BusinessObjects estate
Estates with many Crystal Reports and universes built on SAP sources usually face the hardest rebuild, because pixel-precise documents and their semantic layer do not map one-to-one onto dashboards. The first decision is whether those formatted documents must survive unchanged, or whether the business only needs the figures and can accept new layouts. If the documents must survive, staying on BI 2025 is usually the lower-risk path, and the SAP managed cloud option is worth comparing on paper. If the business can accept new layouts, Apache Superset usually fits, using datasets and metrics in place of universe objects.
- Document count by layout type: Separate Crystal documents that are printed or sent to regulators from those viewed on screen.
- Universe joins and filters: Record which joins, contexts and prompts encode business logic that must be reproduced in SQL or a semantic layer.
- SAP source dependencies: Identify whether reports read from BW, HANA or ECC, and confirm which Superset database drivers your team can run against those sources.
- Shared objects: Count reports that depend on the same universe, since one rebuilt dataset can replace many documents.
- Retirement candidates: Mark documents with no views in the last year as candidates for removal before any rebuild starts.
Confirm with the inventory which documents have a regulatory or contractual layout requirement, because that group often decides the path for the whole estate.
Estates where business users build their own Web Intelligence queries depend on a governed, query-friendly model more than on fixed reports. The first decision is who builds the queries after migration: business users who need a point-and-click builder, or analysts who write SQL. Metabase usually fits the first group, because its query builder runs on models that stand in for universe objects. Apache Superset usually fits analysts who are comfortable in SQL Lab and need a chart builder on top of the results.
- Query owners: List the users who build their own queries and whether each one works from a universe, a saved document or a copied extract.
- Drill behavior: Document which drill paths and multi-query documents are used, because those rarely map directly and need a deliberate design.
- Model count: Estimate how many governed models you need, since many ad hoc queries often reduce to a smaller set of shared definitions.
- Identity source: Confirm whether groups come from LDAP or an identity provider, because SSO and group sync on Metabase depend on the plan.
- Export habits: Record whether users depend on formatted Excel or PDF exports from Web Intelligence.
The answer depends on the inventory, so ask for a list of query owners and their most-used drill paths before choosing a tool.
Estates that send scheduled, personalized reports to many recipients need the distribution pipeline reviewed as carefully as the reports themselves. The first decision is which delivery channels must be kept: per-recipient bursting, bundled PDF or Excel files, or simple dashboard subscriptions. Keeping BusinessObjects on BI 2025 preserves existing scheduling behavior with the least change. Superset can cover subscriptions, but its alerts and reports depend on additional infrastructure, so the design has to account for it.
- Burst lists: Count the recipient groups and the filter values each one receives, since per-recipient bursting is often the hardest behavior to reproduce.
- Infrastructure for alerts and reports: Superset's architecture documentation says alerts and reports require the caching layer and worker components, and most installations use Redis and Celery for them. Plan for these services in your hosting design.
- Output formats: List which formats recipients actually use and test each one in the target tool before committing.
- Failure handling: Record what happens today when a schedule fails and who is alerted, so the replacement has an equivalent.
- Delivery systems: Confirm which mail relays, file shares or portals the outputs must reach.
Before deciding, check how many scheduled jobs and recipients the inventory shows, because that volume drives the infrastructure and testing effort.
Organizations that want to leave SAP licensing entirely are making a platform decision as much as a reporting decision. The first decision is whether the underlying data platform will stay on SAP sources or move to a general SQL warehouse, because that determines whether a non-SAP BI tool can read the data without a large integration project. Apache Superset is Apache-2.0 licensed with no paid edition, so its license cost is zero, but hosting, upgrades, testing and staff time remain. Metabase's free Open Source edition covers many self-hosted uses, while SSO and row-level permissions require a paid plan.
- Source platform: Confirm which SAP and non-SAP systems feed reports and whether each one has a supported driver for the chosen tool.
- Recurring costs: Separate license fees from the ongoing costs of servers, backups, upgrades and the people who run the platform.
- Security requirements: If row-level security or SSO is needed, Metabase's Pro or Enterprise plan may be required, so check the features against the pricing page before deciding.
- Upgrade discipline: Superset upgrades call for database backups, staging tests and reviewing breaking changes, and Metabase upgrades run migrations automatically, so budget for both.
- Exit path: Ask whether your reports, models and users can be exported in a usable form if you change tools again.
Ask for a written cost comparison that lists one-time migration work separately from recurring operating costs, since that comparison usually decides this path.
How a self-hosted Superset stack runs in your infrastructure
A self-hosted Apache Superset deployment has four components: the Flask and React application, a metadata database that stores dashboards, charts, users and permissions, an optional caching layer, and optional Celery worker and beat processes. The application and metadata database are the minimum. Superset is tested with PostgreSQL and MySQL as the metadata database, and the supported versions listed in the configuration documentation are PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. The SQLite default used by Quickstart and PyPI installs, and the PostgreSQL container in the Docker Compose file, are not recommended for production, so plan a managed or dedicated database from the start. Superset also requires a user-specified SECRET_KEY before it will start, and that value must be kept in your secrets store, since it protects stored credentials and supports rotation through PREVIOUS_SECRET_KEY.
Alerts and reports, async queries and dashboard thumbnails depend on the caching layer and the Celery workers, according to the architecture documentation. If your BusinessObjects estate relies on scheduled distribution, plan Redis and Celery as part of the core build, not as an add-on. Confirm with your platform team which Redis and worker hosting model fits your environment, and how worker restarts and queue monitoring will be handled. Check the exact versions you plan to run against the Superset architecture documentation before you size the environment.
Metabase takes a simpler shape. It runs as a single Java application packaged as a JAR, and it stores its own configuration and content in an application database. That database is an embedded H2 file for demos, and PostgreSQL is the recommended choice for production. Teams replacing BusinessObjects with Metabase therefore have fewer moving parts to operate, but they still need to plan the application database backup, the upgrade path, and the choice between the open-source and paid editions, since features such as SSO and row-level permissions sit in the paid plans.
The reporting inventory to complete before choosing a path
This sequence turns the BusinessObjects estate into a dated, owned and classified list of reports, universes and schedules, so the upgrade, managed cloud or replacement decision rests on actual usage. The output is one inventory that every later option can be costed against.
Export the full content list from BI 4.3
The BI platform administrator lists every Web Intelligence document, Crystal Reports file, Design Studio item and universe in the CMC or the content repository, with folder path, object type and parent folder. Confirm the export method in your own BI 4.3 environment, because this page does not supply an inventory tool or a supported export command for your version. Done when the list covers every top-level folder and its row count matches what the platform reports.
Record owners and last-used dates
For each item, record the owner, the creator's department and the last time it was viewed or refreshed. Pull this from the usage and audit logs your environment retains, which depend on how auditing was configured, so check retention with the platform team before relying on the dates. Done when every item has an owner name and a last-used date, and items with no owner are flagged for a business decision.
Mark scheduled jobs and their recipients
List every scheduled instance, its recurrence, output format and distribution list, including email recipients, folder destinations and any bursting or conditional schedules. Scheduled distribution and formatted exports are the items most likely to need a separate design in any target tool, so note them explicitly. Done when each scheduled job has a named business consumer and a stated destination.
Map groups and content access
Export the group membership and the folder and document rights assigned to each group, then trace which business users see each report and universe. Note any row-level restrictions or universe-level security filters, since they are the rules a replacement must reproduce. Done when every item has at least one group with a named purpose and every restricted item has its rule written down.
Identify universes and data sources behind the content
Group the reports by the universe and database connection they use, and list the data sources each universe reads. This shows which items share a semantic layer, which will be rebuilt once, and which depend on a source that will need its own connectivity review. Done when every report traces to a universe or a direct connection and each source is named.
Classify each item as retire, rebuild or keep
Using owners, last-used dates and schedules, assign each item one of three labels. Retire covers unused or superseded content, rebuild covers content needed in a new tool, and keep on SAP covers content that stays on the current platform or upgraded BI 2025 platform. Agree the labels with business owners in writing. Done when every item carries one label and the counts for each label are signed off by the owners.
Use the classified list to compare paths
Take the rebuild and keep counts, the number of universes and the scheduled job list into the comparison of upgrading to BI 2025, SAP's managed cloud option and replacing with Apache Superset or Metabase. Ask each vendor or partner to quote against this same list, so the figures are comparable. Done when the upgrade, managed cloud and replacement options are costed on the same inventory.
Evidence to keep for the upgrade or replacement decision
A steering committee or auditor will want to see how each BusinessObjects report was judged and how the chosen path was carried out. The cards below cover the decision records, the technical backups and the change trail that connect the inventory to the final cutover. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any attestation.
Signed reporting inventory
Keep a dated inventory of every Web Intelligence document, Crystal Report, universe, scheduled instance and distribution list, with its owner, last run date and consuming audience. Sign-off by the business owner confirms the list is complete, which is the baseline for every later decision. Ask the BI administrator to pull usage history from the BusinessObjects audit repository so unused content is evidenced rather than assumed.
Retire, rebuild or keep decisions
Record one decision per report with its rationale: retire (no active use), rebuild on the target platform, or keep on BI 2025 during a transition. Each row should name the approver and the date. This record shows the steering committee why a report was dropped, which matters when a user later asks for it.
Backup and restore record
Keep a dated backup of the BusinessObjects content repository and CMS database before any upgrade, and a tested restore of it on a separate system. For Superset or Metabase, keep the same record for the metadata database or application database. Metabase's upgrade guidance recommends backing up its application database first, and Superset's upgrade guidance says to back up the metadata database before running upgrades.
Report parity checks
For each rebuilt report, keep a side-by-side comparison of row counts, totals and filtered results against the BusinessObjects output for the same period. Record the variances and who accepted them. Rebuilt reports that cannot be reconciled should go back to the decision record rather than being signed off by exception.
Group to role access mapping
Document how BusinessObjects groups, folder rights and universe restrictions map to target roles, groups or permissions. For Superset, record the AUTH_ROLES_MAPPING entries used with LDAP or OAuth. For Metabase, record which features each plan gives you, since SSO and row or column level permissions appear only in Pro and Enterprise. Have an access reviewer sign the mapping before cutover.
Change records for each upgrade step
Keep a change ticket for every upgrade or migration step, listing the version, the staging test result, the rollback point and the approver. For Superset, record the upgrade commands and the UPDATING.md items reviewed for each version. For Metabase, record the release-by-release path taken. Auditors often ask for this trail to confirm changes were controlled.
How to deploy the chosen path before the deadline
This sequence moves the reporting estate from the current BI 4.3 environment to a tested target, either a BI 2025 upgrade or a self-hosted Superset or Metabase deployment, without cutting over until reports have been checked against the inventory. Each step closes with a check that tells the team whether it can move on.
Confirm the target and owners
Leadership, the BusinessObjects administrator and the business report owners agree which path applies to each part of the estate, such as upgrading to BI 2025 for regulated reporting and replacing the rest. Record the decision, the named owner for each report group and the reports that stay out of scope. The step is done when the decision record is signed off and every report in the inventory has a disposition: upgrade, rebuild, retire or keep for a defined period.
Stand up staging with the target database
Build a non-production environment that mirrors the intended production topology. For Superset, provision PostgreSQL or MySQL as the metadata database, since SQLite and the Docker Compose PostgreSQL container are not recommended for production. For Metabase, provision PostgreSQL or MySQL as the application database rather than keeping the embedded H2 database. For Superset on Kubernetes, use the Apache Superset Kubernetes Operator for new deployments, because the official Helm chart is marked deprecated. The step is done when the staging instance starts, serves a login page and connects to a test data source.
Back up the source and the metadata
Before any change, the administrator takes a full backup of the BusinessObjects content and system databases, and exports the universes, Web Intelligence documents, Crystal Reports and scheduling definitions that the inventory identified. For a Superset or Metabase target, the team also backs up the target metadata database before every upgrade. The step is done when a restore has been tested on a separate host and the team can reproduce the backup content from it.
Run the upgrade or rebuild in staging
For a BI 2025 upgrade, the SAP administrator runs the upgrade procedure from SAP's documentation in staging first and records every deviation. For Superset, the team checks UPDATING.md for breaking changes between versions, runs superset db upgrade, then superset init, and sets a user-specified SECRET_KEY before the first start. For Metabase, the team loads the H2 file with the load-from-h2 command using the same Metabase version that last updated that file, then starts the instance so migrations complete. The step is done when the application starts cleanly and the upgrade log has no unresolved errors.
Rebuild and connect data sources
The data team recreates universe joins and objects as Superset datasets and metrics, or as Metabase models and questions, and configures the same database connections with service accounts that have only the read permissions each report needs. Authentication is set up through the chosen identity provider, using OAuth2, LDAP or, in Metabase, the plan features that the organization has licensed. The step is done when every data source responds from staging with credentials stored in the target's secret handling, not in plain configuration files.
Test reports against the inventory
Business owners compare each priority report from staging with its production output, checking row counts, totals, filters, prompts, drill-down paths and formatted exports. Scheduled distribution and bursting are tested separately, since Superset and Metabase do not reproduce every BusinessObjects scheduling feature. Results are logged against each inventory line with a pass, a documented gap or a decision to retire. The step is done when every priority report has a recorded result and the owner has accepted or rejected it in writing.
Cut over and keep the rollback path
The team schedules the cutover with the business owners, repeats the metadata backup on the final production state, and points users, links and scheduled jobs to the new environment. The BusinessObjects environment stays read-only and recoverable for the period the owners agree. The step is done when production users sign in, the first scheduled runs complete and the rollback procedure has been rehearsed and documented.
Set the upgrade routine going forward
After cutover, the team sets a routine for the chosen platform: back up the metadata database before every upgrade, test each release in staging, review release notes for breaking changes, and track the support window of the version in use. For Metabase, the team tracks the version support page, since LTS and non-LTS releases have different end-of-life dates. The step is done when the routine is written down, assigned to a named owner and reflected in the operations calendar.
Questions buyers ask before the 31 December 2026 deadline
How much effort does replacing BusinessObjects reports take?
Effort depends on how many reports are still in use, how complex the universes are, and how much scheduling and identity work sits behind them. An inventory comes first, and reports nobody opens can be retired before any rebuild starts, which removes work early. Universes with many joins, contexts and derived objects take longer to rebuild as Superset datasets and metrics than single-table reports do. Scheduled distribution, bursting and formatted exports add work because Superset does not replicate every BusinessObjects output format. Identity mapping adds effort when LDAP or OAuth groups need rework to match roles. One-time costs are inventory, rebuild, testing and cutover. Recurring costs are hosting and the staff time to run the platform. Ask any quote to break out these components separately.
How long does a BI 4.3 to Apache Superset rebuild take?
No duration can be stated from the researched facts, so the timeline depends on the inventory and scope agreed in writing before work starts. The main drivers are the number of reports to rebuild, the number and complexity of universes, the number of source databases, and how quickly report owners can review and approve rebuilt outputs. A parallel run, where old and new outputs are compared for a period, usually extends the schedule but reduces cutover risk. Platform setup in staging, including the metadata database and any caching and worker components for alerts, adds fixed steps. Ask for milestones covering inventory, a pilot of representative reports, parallel running, cutover and a rollback plan, each with a date that the client can check.
What does a BusinessObjects migration need from our own staff?
The work needs named people from several areas, and the time they give is often the largest internal cost. Plan for:
- Business report owners who confirm which reports are used and sign off on rebuilt outputs.
- Data owners who confirm source connections, metric definitions and the business meaning of universe objects.
- An identity administrator who maps LDAP or OAuth groups to Superset roles through the configuration of AUTH_ROLES_MAPPING.
- A database administrator for the PostgreSQL or MySQL metadata database, its backups and its upgrades.
- A platform owner for the hosting environment, monitoring and the upgrade calendar.
Agree these roles and time commitments in the scope before the project starts, so reviews do not stall the rebuild.
Can our own team replace BusinessObjects without a partner?
A team with SQL and data modeling skills can build dashboards in Superset or Metabase, but the harder parts are usually the security model, scheduled distribution and running the platform. Superset requires a SECRET_KEY before it starts and supports rotation with PREVIOUS_SECRET_KEY, so key handling must be designed up front. Upgrades need a metadata database backup, superset db upgrade, superset init, a test in staging and a check of UPDATING.md for breaking changes. A Superset upgrade guide lists these steps. Teams without this experience often start with a pilot of a few reports. DeployOpen can plan, implement, document and support the platform in your infrastructure, with ongoing support available as a retainer.
What should a fixed-scope quote for a BI migration include?
A fixed-scope quote should list the deliverables, the boundaries and the acceptance criteria in writing. Ask for:
- An inventory deliverable with report, universe, schedule and user counts, plus a list of retired reports.
- The target platform, the release version and the hosting model.
- A mapping of universe objects to datasets and metrics, and of security roles to target groups.
- A statement of which scheduled outputs and export formats are covered, and which are excluded.
- Testing, parallel running, cutover and rollback steps.
- Documentation, training and handover, plus the backup and upgrade plan after go-live.
DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow that written scope. Compare quotes by these deliverables, not only by total figure.
Does SAP's managed cloud option change the migration decision?
A managed cloud option changes who runs the hosting and upgrades, but it leaves the reporting inventory, the universe rebuild and the identity questions in place. Confirm with SAP what the managed service includes, which BI release it runs, where data is hosted, and how it reaches on-premises data sources. Ask about the contract term, exit terms and whether reports and universes can be exported in a usable form. If you plan to leave the platform later, the work to move content out still applies. Ask SAP to confirm each point in writing, because the answers decide whether the migration is needed now, later or not at all.
How DeployOpen plans and delivers the BI 4.3 exit
DeployOpen starts with a written inventory of what BusinessObjects BI 4.3 actually serves, then decides per report whether it moves to BI 2025, stays on a managed option or is rebuilt on self-hosted Apache Superset or Metabase. The work runs inside your own infrastructure, with each step documented for your team and your auditors.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before any work starts.
- The written scope lists which Web Intelligence documents, Crystal Reports, universes and schedules are in or out.
- Each report is classified as keep on BI 2025, rebuild, retire or hand to a managed option, with the reasons recorded.
How we build
- Upgrade or replacement runs in staging first, with the BI 4.3 metadata database backed up before any change.
- Replacement dashboards, datasets and semantic definitions are rebuilt in your own environment and tested against existing report outputs.
- Access mapping from existing BusinessObjects groups to the target platform is tested with named user samples before cutover.
How we hand over
- Deliverables include the report inventory, the decision log, configuration records and the test results for each migrated report.
- Your team receives runbooks for upgrades, backups and secret rotation in the platform you chose.
- Hand-over sessions are scheduled in the written scope, so your staff can operate the platform without DeployOpen present.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after hand-over.
- Retainers can cover platform version upgrades, reviewing vendor breaking-change notes and re-running report checks.
- Ask for the retainer terms in writing, including response expectations, before you commit to a support model.
