Looker alternative outside Google Cloud

Why a Looker alternative outside Google Cloud starts with hosting

If a residency, sovereignty or network rule requires your BI platform to run on your own premises, on another cloud or inside a customer's network, Google-hosted Looker cannot meet it. Looker (Google Cloud core) runs only in Google Cloud, and customer hosting is offered only for Looker (original). That single fact decides the first question before any feature is compared, so it is the place to start the search.

The short answer is that Lightdash, Apache Superset and Metabase can all be self-hosted in your own infrastructure, but they differ in how they model data. Lightdash reads metrics from a dbt project in your Git repository, Superset relies on datasets and its own semantic features, and Metabase uses models and metrics inside its application. Those trade-offs matter, yet they are a separate question. This page only tests the hosting constraint, so each option is checked for whether it can run where your rule requires. Feature depth, governance and embedding are covered on the sibling pages.

Before you shortlist anything, write down where the platform must run, which network zones it may reach, and where its metadata and cached query results may be stored. Then confirm with each vendor or your own platform team that the chosen deployment method (Kubernetes, Docker Compose, a JAR or a container image) fits that environment. Ask also which features depend on a paid license key, because a self-hosted tier that is free to run can still gate capabilities you need.

What an on-premises or private-cloud BI deployment must satisfy

Looker (Google Cloud core) runs only in Google Cloud, so a team that must keep BI inside its own network needs a tool that meets a short set of hosting, data, identity and modeling requirements. The cards below set out those requirements, what each one means for your team, and what to confirm with a vendor or in your own environment before you commit.

Runs in your infrastructure

The first requirement is that the BI application, its metadata store and its caches run in your own data center, air-gapped network or cloud account, not in a vendor-hosted tenant. Looker (Google Cloud core) instances are hosted by Google in Google Cloud and are not offered for customer-hosted or multicloud environments. Check that the candidate can be installed from images or charts you control and that it does not require a phone-home license check for its core features. Ask each vendor which features, if any, need outbound connectivity.

Metadata in PostgreSQL or MySQL

Dashboards, users, permissions and saved queries are stored in an application database, and that database becomes a system you must back up, patch and restore. Apache Superset stores its metadata in PostgreSQL or MySQL, and Metabase recommends PostgreSQL for production. Confirm which engine versions the tool supports, who operates the database service, and how you will test restores. Do not assume the bundled default database is suitable for production.

Authentication through LDAP or OAuth

A self-hosted tool has to plug into the identity provider you already run, so that joiners, leavers and group changes flow into BI roles without manual account creation. Superset supports database, LDAP and OAuth authentication and maps LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING. Metabase's open source edition supports Google sign-in and LDAP, while SAML, JWT, OIDC and SCIM provisioning require its Pro or Enterprise plans. Verify group sync and role mapping in a test directory before you rely on it.

Semantic layer kept in version control

Looker keeps each LookML project in a Git repository, which gives metric definitions review, history and rollback. Lightdash reads metrics from dbt YAML in your own repository, so definitions live beside the dbt models rather than inside the BI tool's database. When evaluating alternatives, confirm where metric definitions are authored, whether changes go through pull requests, and whether you can export the full model set without the BI tool running.

Secrets and key handling

Self-hosted BI tools hold database credentials, OAuth client secrets and, for some products, license keys, and each one needs a documented place to live. Superset requires a user-specified SECRET_KEY to start and supports rotating it with PREVIOUS_SECRET_KEY. Lightdash Enterprise reads its license key from an environment variable. Confirm how each tool stores warehouse credentials, how keys rotate without downtime, and whether your secrets manager can inject them at startup.

Upgrade and licensing discipline

Once BI runs in your network, upgrades are your responsibility, and release cadence affects how often you must test. Superset's upgrade process calls for a metadata database backup, running database upgrades, staging tests and a review of breaking changes. Metabase publishes support windows that differ for LTS and non-LTS releases. Lightdash ships releases frequently. Confirm the support window for the version you deploy and which features sit behind a paid license key before you design the platform.

Where Looker (Google Cloud core) meets the constraint and where it does not

Looker (Google Cloud core) is the constraint at the center of this page. According to Google Cloud documentation, Looker (Google Cloud core) instances are hosted by Google in Google Cloud and are not available for customer-hosted or multicloud environments. It is sold in Standard, Enterprise and Embed editions, and each of those editions runs in Google's infrastructure. If your requirement is to run the BI platform in your own data center, on another cloud or inside a customer's network, the Looker (Google Cloud core) runtime itself does not meet it, regardless of edition. Before you rely on that conclusion, confirm with Google any hosting option that is not described in the supplied documentation, and get the answer in writing from your account team.

The part that does move is the modeling layer. Each LookML project corresponds to a Git repository, and Looker connects to remote providers such as GitHub, GitLab or Bitbucket over HTTPS or SSH. That means the view, model and explore files live in version control under your control, not only inside the Looker instance. Start by confirming which repository holds each project, who has administrative rights on it, and whether any project depends on Looker-only features such as certain Looker-specific parameters or caching behavior. Those files are the input to any migration, and they are also the first thing a security or compliance reviewer will ask to see.

What does not move automatically is everything the Google-hosted instance does around the models: users, groups, permissions, scheduled deliveries, dashboards and the warehouse connections that Looker uses to run queries. Those need to be rebuilt or re-established in the new platform, and the identity provider and network paths must be redesigned for the new location. Plan for the warehouse to remain the place where queries execute, since the self-hosted BI tool will still need network access to it. Treat the repository export as the easy step and the access model and the verification of results against existing dashboards as the work that determines whether the move is complete.

Which self-hosted option fits which constraint

This table compares the three self-hosted options on license model, semantic layer, metadata database, authentication and what the paid tier adds. Read the trade-off column first if your constraint is a semantic layer that must stay in version control or an air-gapped network.

Criterion	Lightdash	Apache Superset	Metabase
License model	Open core: content outside the ee directory is MIT licensed, and the ee directory has a separate license	Apache-2.0 with no paid edition	Open core: AGPL-3.0 open source edition, with enterprise code under the Metabase Commercial License
Semantic layer	Metrics defined in dbt YAML in your Git repository, so definitions sit beside the dbt models	Datasets with metrics defined in Superset, plus the SQL editor and chart builder; governed logic usually lives in dbt or SQL views	Models and metrics defined inside Metabase; LookML logic must be rebuilt or moved into the warehouse or dbt
Metadata database	PostgreSQL with the pgvector extension, plus S3-compatible object storage	PostgreSQL 10 to 17 or MySQL 5.7 and 8.x; SQLite is not recommended for production	PostgreSQL recommended for production; MySQL 8.4.0 or MariaDB 10.6.0 and later also supported
Authentication	Login and SSO depend on edition; SAML and SCIM 2.0 are on the Enterprise plan	Database, LDAP and OAuth through Flask-AppBuilder, with group-to-role mapping via AUTH_ROLES_MAPPING	Google sign-in and LDAP in the open source edition; SSO, SAML and SCIM need Pro or Enterprise
What the paid tier adds	AI agents, embedding, custom roles, service accounts and SCIM unlock with a LIGHTDASH_LICENSE_KEY on Enterprise on-prem	No paid edition; you pay for your own infrastructure, operations and any outside support	Pro adds SSO, row and column level permissions and usage analytics; only Enterprise offers air-gapped deployment
Trade-off to plan for	Requires a dbt project; teams without dbt must build that layer first, and frequent releases need a regular upgrade routine	Less governed modeling than a semantic layer; LookML users must redo explores and joins in datasets or dbt	Governed permissions for regulated teams may need a paid tier, and air-gapped use requires Enterprise quoted by sales
Best fit for	Teams with dbt and a Git-based metric workflow that want LookML-style governance	Teams that want a general-purpose self-hosted BI tool and can keep modeling in SQL or dbt	Teams that want self-service dashboards with fewer modeling requirements and can accept the tier boundaries

Choosing a deployment path by team skills and network

Lightdash documents two self-hosting routes: an official Helm chart for Kubernetes, or a minimal Docker Compose deployment. Both need a PostgreSQL metadata database and S3-compatible object storage. The self-hosting guide is written for DevOps engineers who already work with Docker and Kubernetes, so this path assumes that skill set exists in-house or in a partner's hands. Enterprise on-premises features also need a license key supplied through the LIGHTDASH_LICENSE_KEY environment variable and a PostgreSQL database with the pgvector extension.

Helm chart on Kubernetes: Suits teams with an existing cluster, ingress, secrets handling and a storage class that can satisfy S3-compatible object storage.
Docker Compose: Fits a single host for evaluation or small internal use, but it still needs a managed PostgreSQL and object store plan for anything production-facing.
pgvector requirement: Confirm your PostgreSQL service allows the extension if you plan to use Enterprise features.
Upgrade routine: Lightdash ships releases frequently, so the platform team needs a standing upgrade process, not a one-time install.
Warehouse access: Confirm the cluster can reach your warehouse and dbt Git repository from inside the network.

Check with the platform team whether the cluster and object storage are approved for the data classes that BI will touch.

Apache Superset has four components: the Flask and React application, a metadata database, an optional caching layer and optional Celery worker and beat processes. Alerts and reports, async queries and dashboard thumbnails depend on the caching layer and workers, and most installations use Redis and Celery for them. This path therefore assumes a team comfortable operating several stateful services, not just one web app. Superset requires a user-specified SECRET_KEY at startup, and the upgrade process expects a metadata database backup before running superset db upgrade and superset init.

Metadata database: Use PostgreSQL or MySQL in production. The SQLite default and the Docker Compose PostgreSQL container are not recommended for production.
Caching and Celery: Plan for Redis and Celery workers if you need scheduled reports, alerts or async queries.
Kubernetes packaging: The Helm chart is marked deprecated in current development docs, which point new deployments to the Apache Superset Kubernetes Operator. Confirm which route your platform team will adopt.
Authentication: Plan LDAP or OAuth2 integration with your identity provider and the AUTH_ROLES_MAPPING group mapping.
Network egress: Confirm the workers can reach your data sources and any mail or chat endpoints for reports.

Confirm the target version against the release notes and UPDATING.md before the build starts, since upgrades carry breaking-change checks.

Metabase is a JAR-based application that stores its own state in an application database. It ships with an embedded H2 database for demos and recommends PostgreSQL for production, with MySQL 8.4.0 or MariaDB 10.6.0 and later also supported with utf8mb4. This path is the lightest to operate on paper: one application process plus one database. It assumes the team can run a PostgreSQL service, manage backups and handle application upgrades that run database migrations automatically.

Application database: Move off H2 early. Metabase documents a one-time load-from-h2 command that must run with the same version that last wrote the H2 file.
Upgrade discipline: Back up the application database first, and for major upgrades reduce a cluster to a single node because of a migration lock.
Version path: Upgrade release by release from versions older than 40.
Edition gating: SSO, row and column level permissions and advanced directory sync need Pro or Enterprise. Confirm which controls your access model requires before choosing the edition.
Air-gapped needs: Only the Enterprise plan offers air-gapped deployment, so confirm this with Metabase if your network is isolated.

Verify whether your required access controls exist in the open source edition before assuming a single-node install meets your policy.

How to deploy the chosen option inside your network

This sequence takes a team from a confirmed hosting boundary to a running, authenticated BI instance inside its own network, with a tested upgrade routine in place before users depend on it. The order matters: the metadata database and secrets come before the semantic layer is connected, and authentication is wired before any real data is shared.

Confirm the hosting boundary and owners
Before installing anything, the platform owner and the security lead agree in writing where the BI servers, metadata database and object storage will run, which network segments can reach them, and which warehouse credentials the BI service will hold. Record who operates each component and who approves upgrades. The step is done when this boundary is written down and signed off by the people who own the data and the network. Note that Looker (Google Cloud core) is hosted only by Google in Google Cloud, so this boundary is the reason the team is moving in the first place.
Stand up the metadata database
Provision a production PostgreSQL or MySQL instance for the application's metadata, separate from the analytics warehouse. Superset is tested with PostgreSQL and MySQL, and its configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. Metabase recommends PostgreSQL for production and supports MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4. Lightdash requires PostgreSQL with the pgvector extension on Enterprise. Do not keep the SQLite default or the Docker Compose PostgreSQL container in production. The step is done when a backup job for this database runs and a restore has been tested once.
Configure application secrets and license keys
Set the secrets each tool needs before first start, stored in your secret manager and injected as environment variables or configuration. Superset requires a user-specified SECRET_KEY to start, and PREVIOUS_SECRET_KEY supports rotation. Lightdash Enterprise features need the LIGHTDASH_LICENSE_KEY environment variable, and the open source core does not. Metabase Enterprise images use a separate image from the open source one, so confirm which edition and license your contract covers. The step is done when the service starts cleanly with secrets sourced from the vault and none of them appear in the Git repository or container image.
Connect the semantic layer and warehouse
Connect the BI tool to the warehouse with a read-only service account, then attach the modeling source. For Lightdash, point it at the dbt project in your Git repository, which supports dbt v1.4.0 and above with dbt Core targets or dbt Cloud environments, so metric definitions stay under version control. For Superset, register database connections through its SQLAlchemy dialects and define datasets with governed metrics. For Metabase, define models and metrics in the application. The step is done when a sample dashboard built on a governed metric returns the same figures as the query run directly against the warehouse.
Wire authentication and group mapping
Connect the tool to your identity provider and map directory groups to application roles before inviting users. Superset supports database, LDAP and OAuth2 authentication through Flask-AppBuilder, with AUTH_ROLES_MAPPING for groups. Metabase's open source and Starter plans support Google sign-in and LDAP, while SAML, OIDC, JWT, SCIM and advanced LDAP group sync need Pro or Enterprise. Lightdash SSO with SAML and SCIM 2.0 sits on its Enterprise plan. Confirm these tiers against current vendor pricing before you rely on them. The step is done when a test user from each group lands with the expected role and a user outside the groups is refused.
Run staging first and back up before each upgrade
Install the same version in a staging environment that mirrors production's database and authentication setup, and run every upgrade there first. For Superset, back up the metadata database, run superset db upgrade and superset init, and check UPDATING.md for breaking changes between versions. For Metabase, back up the application database, and for major upgrades reduce a cluster to a single node because of the migration lock. Upgrade release by release from versions older than 40. Metabase 64 is an LTS release with end of life on 1 December 2027, and Lightdash ships new versions frequently. The step is done when the staging upgrade completes, dashboards and logins pass a checklist, and the rollback from backup has been rehearsed.
Promote to production and schedule the upgrade routine
Repeat the staging upgrade in production during an agreed window, with the backup taken immediately before the change. Restore the same secrets, database connections and identity mappings verified in staging, and confirm that scheduled reports, alerts or caching workers (Celery and Redis for Superset) are running if you use them. Record the version, the backup identifier and the approver in the change log, and set a recurring review of vendor release notes and security advisories. The step is done when production serves the agreed dashboards, the change log is complete, and the next upgrade date is on the operations calendar.

What moving the LookML layer takes

LookML lives in Git, so exporting the model definitions is a repository task, not a BI task. Each LookML project corresponds to a Git repository, and Looker connects to providers such as GitHub, GitLab or Bitbucket, so the view files, model files and dashboard definitions can be cloned and kept as an archive before any tool is chosen. Confirm that your team has read access to that repository, that the account used holds the correct permissions, and that the project's branches and pull request history are captured as well. The files alone do not carry everything Looker does at runtime. Explores, the permissions attached to them, persistent derived tables and the scheduled deliveries configured in the Looker instance must be rebuilt by hand or re-created in the target tool.

On Lightdash, the rebuild starts in dbt. Lightdash reads its semantic layer from a dbt project and defines metrics in YAML under meta: metrics: at column or model level, so LookML measures and dimensions become dbt definitions that sit next to the models they describe. Superset and Metabase take a different route: Superset uses datasets with metrics, and Metabase uses models and metrics, so the team must decide where governed definitions live (in the warehouse as views, in dbt, or in the BI tool). Each choice moves the modeling work to a different owner and a different review process. Ask which team will maintain those definitions after go-live and how changes will be reviewed.

Permissions and derived tables are the parts most often underestimated. LookML access controls, model-level grants and row-level filters need to be mapped to the target's role and group model, and the identity provider's group mapping must be designed before users are migrated. Derived tables that Looker materializes in the warehouse need an owner, a schedule and a place in your data pipeline. Plan a side-by-side validation period in which the same questions are answered in both tools and the numbers are compared, and confirm with each vendor which identity and permission features your chosen edition includes before you commit to a design.

Questions buyers ask before hiring outside help

What drives the cost of self-hosting a Looker replacement?

The biggest cost drivers are people, infrastructure and the modeling work, while the open-source cores of Lightdash, Superset and Metabase carry no license fee. Recurring costs include hosting the application, a PostgreSQL metadata database, object storage where needed, staff time for upgrades and backups, and monitoring. One-time costs include converting LookML views, explores and derived tables into dbt models or Superset datasets, and validating dashboards against Looker outputs. Warehouse query spend and model size push totals up because heavier dashboards run more queries. When you request a quote, ask for each component separately: LookML conversion scope, infrastructure assumptions, support hours and retainer terms. Compare the result with your current Looker contract.

Can our internal team run Lightdash or Superset without outside help?

Many teams with DevOps and analytics engineering skills can, but the work goes beyond installing a container. Lightdash documents self-hosting on Kubernetes with an official Helm chart or a minimal Docker Compose deployment, with PostgreSQL and S3-compatible storage, and its guide targets DevOps engineers familiar with Docker and Kubernetes. Superset's architecture documentation says alerts, async queries and dashboard thumbnails need a caching layer and Celery workers. The skills gap usually sits in dbt modeling, identity integration and disciplined upgrades. Ask whether you have engineers who can own a release cycle, a tested backup restore and a dbt project. Lightdash's self-host guide is a useful starting point for that assessment. A fixed-scope engagement can cover the parts you do not want to staff.

What does our team need to provide during the engagement?

Outside work moves faster when your team supplies access and decisions. Typical inputs include:

Read access to the Looker instance, the LookML Git repository and a list of active dashboards and their owners
Warehouse credentials for a non-production schema, plus the people who know the data and the dbt project
A named business owner for each metric who can settle definitions and sign off on reconciled results
Identity provider details for SSO, LDAP or OAuth group mapping
A place to run the new stack, such as your cloud account, data center or air-gapped network

The scope document should list these inputs, the people responsible for each one and the dates they must be available.

How long does a Looker to self-hosted BI migration take?

Duration depends on scope, and the timeline is agreed in writing before work starts. The variables that matter most are the number of LookML views, explores, derived tables and dashboards, how many metrics need a business decision, and how many data sources sit behind them. Teams that keep a Looker renewal running in parallel usually validate both tools side by side, which extends the calendar. Ask for milestones: repository clone and inventory, metric conversion, dashboard rebuild, validation against Looker outputs, identity integration, cutover and handover. DeployOpen does not publish durations; the written scope sets the timeline. Also align the plan with your Looker renewal date, because a short window shapes the cutover.

What do paid Lightdash and Metabase plans add to the cost?

Paid tiers add features on top of the open-source core, and the price depends on each vendor's plan. Lightdash's pricing page lists Cloud Pro at $3,000 per month with no per-seat pricing and Enterprise at custom pricing. Its on-premises Enterprise features, such as SAML and SCIM 2.0, custom roles and service accounts, need a license key set through the LIGHTDASH_LICENSE_KEY variable. Metabase's pricing page lists Starter at $100 per month, or $90 per month billed yearly, with the first 5 users included and $6 per additional user per month. Its Pro plan is $575 per month, or $517.50 per month billed yearly, with the first 10 users included and $12 per additional user. SSO, row and column level permissions and auditing sit in Pro and Enterprise. Metabase Enterprise starts at $20,000 per year by quote.

Does self-hosting Superset or Metabase carry ongoing maintenance costs?

Yes, self-hosting has recurring costs even when the software is free. Superset is released under Apache-2.0 and has no paid edition, so its recurring spend is infrastructure, staff time and upgrades. Its upgrade documentation says to back up the metadata database, run superset db upgrade and superset init, test in staging and check UPDATING.md for breaking changes. Metabase runs application database migrations automatically during upgrades, and its docs recommend backing up the application database first and reducing a cluster to one node for major upgrades. Metabase LTS releases are supported for 14 months, which gives you a planning cadence. Budget for a regular release routine, and for support if you want it.

How do we keep Looker's governed metrics after self-hosting?

Governed metrics move into version-controlled definitions. In Lightdash, metrics are defined in dbt YAML under meta: metrics: in your Git repository, so definitions stay with the dbt models instead of inside the BI tool's database. LookML already lives in Git, so the workflow feels familiar, but the conversion is manual work. Aggregates, percentiles and post-calculations such as running totals need checking against Looker results. Superset uses datasets with metric definitions, and Metabase uses models and metrics, both of which need verification against the source logic. Ask any partner to show a sample measure converted, reconciled against a Looker result and reviewed by the business owner before you commit to the full scope.

Evidence that shows the deployment stays inside the constraint

The reason to run BI outside Google Cloud is usually a residency, network or control requirement, so the proof has to show where every component runs and who can reach it. The artifacts below connect the architecture to the records an assessor will ask for. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any attestation.

Network and placement diagrams

Draw where the BI application, the metadata database, the caching layer and any worker processes run, with every network boundary and egress path marked. For Lightdash, include the PostgreSQL database with pgvector and the S3-compatible object storage. For Superset, include the Celery worker and beat processes if alerts, reports or async queries are enabled. Confirm that the warehouse connection stays inside the approved network and that no component calls a Google-hosted endpoint at runtime.

Authentication configuration records

Keep the exported configuration for the identity provider, including OAuth2 or LDAP settings, the group-to-role mapping and the secret handling for the application. In Superset, record the AUTH_ROLES_MAPPING entries and the SECRET_KEY rotation history. In Metabase, record which sign-in methods are enabled for your plan, since SAML and SCIM require Pro or Enterprise. Store the files in version control with review, not in a shared drive.

License key and edition records

Where a paid edition is used, record which license key is installed, the edition it unlocks and the date it was issued. For Lightdash Enterprise, the LIGHTDASH_LICENSE_KEY variable controls features such as SCIM and custom roles, so the deployment record should show that variable's source and who can change it. For Metabase, record whether the instance runs the open source image or the enterprise image, since the two are separate. Confirm the terms of each license with the vendor before relying on them.

Metadata database backup and restore tests

Keep dated backup records for the application or metadata database and at least one documented restore test into a separate environment. Superset's upgrade guidance requires a metadata database backup before running superset db upgrade. Metabase recommends backing up the application database before upgrades and documents a load-from-h2 path for moving off the embedded H2 database. A backup that has never been restored is not evidence of recovery, so record the restore result and the time it took.

Upgrade logs against release notes

Each upgrade should have a log that names the source and target versions, the staging test result and the release notes or UPDATING.md entries reviewed. Lightdash ships new versions frequently, Superset publishes breaking changes in UPDATING.md, and Metabase runs database migrations automatically, sometimes with a migration lock that requires a single node for major upgrades. Tie each entry to the version support status, so the assessor can see that the platform was within its supported window.

Access reviews for BI users and roles

Run a recurring review of who holds admin, creator and viewer roles, who can edit the semantic layer, and who can export data. In Lightdash, check the role and service account lists, since the dbt repository and the BI roles are controlled separately. In Metabase, row and column level permissions are a paid feature, so the review should confirm which restrictions are enforced. Keep signed-off review records with dates and reviewer names.

How DeployOpen deploys BI inside your constraint

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Looker replacement, that means starting from where your BI platform must run and what your LookML layer depends on, then building the stack in that environment.

How we scope

We confirm where BI must run: on-premises, another cloud, or inside your network boundary.
We inventory LookML projects, Git repositories, warehouse connections, users and dashboards in scope.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We deploy the chosen tool, such as Lightdash, Superset or Metabase, with its metadata database and supporting services.
We connect authentication to your existing directory, such as LDAP or OAuth, and map groups to roles.
We test metric definitions and dashboards side by side with Looker output before any cutover decision.

How we hand over

We document the architecture, configuration, backup routine and upgrade steps for your own operators.
We record the license and edition decisions, including which features need a paid key or plan.
We provide a runbook covering the metadata database backup and the staged upgrade process.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can prepare systems and evidence for your compliance assessments, though auditors issue the actual reports.
Ask any provider to confirm the support scope, response expectations and upgrade cadence in writing.