Thanos vs Grafana Mimir: when each one fits
Choose Thanos when you already run Prometheus servers and want long-term, highly available storage in object storage without replacing them. Thanos components are added beside those servers. The Thanos sidecar runs next to each Prometheus, implements the Store API on top of the remote-read API, and uploads TSDB blocks as Prometheus produces them. If Prometheus cannot be changed to push, the Thanos Receive component accepts remote write instead. The project is Apache-2.0 licensed, which most license reviews clear without a special process. The trade-off is that you operate several components (Query, Store, Compactor and optionally Receive or Ruler) and the Compactor must run as a singleton per bucket.
Choose Grafana Mimir when you want one horizontally scalable cluster that many teams push into through remote write, with tenant isolation built in. Mimir is distributed under AGPL-3.0-only, so your legal team must accept that license for a service you run and possibly modify. It is multi-tenant by design: every HTTP request carries a tenant ID header, and authentication and authorization sit in an external reverse proxy that you provide. Mimir also runs in monolithic mode for smaller tests, but a production cluster is a microservices deployment, usually installed with the mimir-distributed Helm chart. Confirm that your team can run that cluster and its object storage backends before committing.
The decision turns on four questions. First, tenancy model: one platform team with a few Prometheus fleets, or many independent teams that need isolated queries and limits. Second, license review: whether AGPL-3.0 is acceptable for the way you deploy and modify the software. Third, ingest path: Thanos sidecars keep Prometheus as the write path, while Mimir 3 offers a Kafka-based ingest architecture alongside the classic ingester design, so confirm which path your team can operate. Fourth, operating capacity: count the people who will carry upgrades, bucket maintenance and on-call for either stack. Ask DeployOpen, or your own architects, to write those four answers into a scoped plan before choosing.
Thanos vs Grafana Mimir for a small platform team or a multi-team estate
This table maps common team situations to the platform that fits better and the reason behind it. Read each row against your own Prometheus count, tenancy needs and license policy, and treat the rows marked as dependent as questions to settle before choosing.
| Scenario | Better fit | Why it fits and what decides it |
|---|---|---|
| One or a few Prometheus servers that need a global query view | Thanos | The sidecar sits beside existing Prometheus servers and reuses their local storage format, so there is no remote-write cluster to introduce. Confirm that the team can still run a distributed set of components such as Query and Store. |
| Many independent teams that need isolated tenants | Grafana Mimir | Mimir stores each tenant's series in its own TSDB and isolates data and queries by tenant. Thanos can separate sources through external labels and Receive tenant headers, but Mimir is built around tenancy. Confirm how authentication and per-tenant authorization will be handled, since Mimir leaves them to an external reverse proxy. |
| A strict Apache-2.0 requirement for every component | Thanos | Thanos is Apache-2.0, while Grafana Mimir is distributed under AGPL-3.0-only. Whether AGPL-3.0 is acceptable depends on your license review and on whether you modify and offer Mimir to users over a network. Treat this as a license review decision, not a technical one. |
| A Kubernetes-first shop that wants a Helm-managed install | Grafana Mimir | Grafana publishes the mimir-distributed Helm chart to install, configure and upgrade Mimir in a cluster. Thanos can also run on Kubernetes, but you assemble its components yourself. Confirm the chart's values and upgrade path against your cluster policies before committing. |
| A small platform team with little capacity to run a distributed system | Depends on the workload | Thanos is designed as a distributed system and is not recommended for production on a single node, but a small Prometheus fleet can keep the moving parts few. Mimir runs as one binary with a monolithic mode, but a large multi-tenant deployment brings Kafka-based ingest in version 3 and more operating work. Ask which mode and scale you actually need before weighing effort. |
| Historical data already in Thanos blocks that must move to Mimir | Depends on data cleanup | Grafana's migration guide says Mimir does not support Thanos downsampling, so downsampled blocks must be removed before copying, and blocks with unsupported labels need those labels stripped from meta.json. Plan this cleanup and confirm it with Grafana before deciding to migrate. |
| Long-term downsampled history is a key requirement | Thanos | The Thanos compactor downsamples raw data to 5-minute and 1-hour resolution as it ages. Mimir does not support Thanos downsampling, so keeping that history in Mimir means retaining the full-resolution data or keeping Thanos for downsampled views. |
| Multi-team estate where team-level cost reporting or isolation is audited | Grafana Mimir | Per-tenant storage and query isolation give a clear boundary for ownership and access. Confirm with your auditors and your reverse proxy design how tenant boundaries will be evidenced before relying on them. |
How Thanos sidecars and Mimir's remote-write cluster differ in operation
Thanos adds components beside Prometheus servers that already exist, while Mimir asks you to send metrics into a central cluster. The cards below cover the moving parts each path creates, the settings that must be right from day one, and the tenancy and access decisions that fall to your team.
Sidecar beside each Prometheus
The Thanos sidecar runs next to each existing Prometheus server, serves the Store API over the Prometheus remote-read API, and uploads TSDB blocks to object storage as they are produced every 2 hours. Your Prometheus servers keep their current role, so the change is additive. Check that every server you attach is one you can operate for years, because each sidecar is another process to patch and monitor.
Min and max block duration must match
When a sidecar uploads blocks, Prometheus min and max block duration must be set to equal values so local compaction is disabled. The Thanos sidecar docs warn that leaving compaction on can corrupt uploaded data. This is a configuration check you must audit on every Prometheus instance, including ones added later by other teams, and it should be part of your change review.
Receive for push-based setups
Thanos Receive implements the Prometheus Remote Write API, so Prometheus pushes samples into it instead of Thanos reading from local servers. It uploads blocks every 2 hours by default and identifies tenants by the THANOS-TENANT header by default. Choose it when you cannot place a sidecar next to each server, and confirm how tenant headers are set and enforced at your ingress.
Singleton compactor per bucket
The Thanos compactor downsamples raw data older than 40 hours to 5-minute resolution, and 5-minute data older than 10 days to 1-hour resolution. It must run as a singleton against each object storage bucket, so two compactors on one bucket is a configuration error you must prevent. Plan for its disk and runtime during backfills, and confirm your alerting covers a stopped or failed compactor.
Mimir's distributor and query frontend
In Mimir, Prometheus writes through the remote write API to the distributor, and PromQL queries go to the query frontend. Ingestion and querying are separate paths in one cluster, so you operate a central service that every team depends on. Ask who will own capacity planning and on-call for that cluster before you commit to it.
Per-tenant TSDB and the -target modes
Mimir stores each tenant's series in its own Prometheus TSDB in object storage, and its components are compiled into a single binary. The -target parameter selects which components a process runs, and monolithic mode runs them all in one process. Monolithic mode suits a smaller footprint and simpler operations, while microservices mode suits large scale. Confirm which mode fits your expected load before choosing a deployment.
Tenant header and external authentication
Mimir requires a tenant ID header on every HTTP request and leaves authentication and authorization to an external reverse proxy. Nothing in Mimir itself stops a client from sending another tenant's header, so the proxy is part of your security boundary. Specify who owns that proxy, how it maps identities to tenants, and how its configuration is tested and audited.
Thanos vs Grafana Mimir feature by feature
This table compares Thanos, added beside existing Prometheus servers, with Grafana Mimir, a multi-tenant remote-write cluster, row by row on license, release status, downsampling, tenancy, ingest, storage and operating model. Read each row with its confirmation note, because several figures are vendor statements or depend on your own sizing and environment.
| Feature | Thanos | Grafana Mimir |
|---|---|---|
| License | Apache-2.0 | AGPL-3.0-only. Confirm with your legal team what AGPL obligations apply if you modify and offer the software to users over a network. |
| Governance | CNCF Incubating project. Confirm the current project status on the CNCF site before you rely on it. | Distributed by Grafana Labs under the grafana/mimir repository. Confirm the support model and any commercial options with Grafana Labs. |
| Latest versions | v0.42.4, published July 30, 2026. Confirm the current release and your upgrade path before you standardize on it. | 3.2.2, published October 7, 2026, with 3.1.7 for the previous line on October 6, 2026. Confirm which line your team will support. |
| Downsampling | Compactor downsamples raw data older than 40 hours to 5-minute resolution and 5-minute data older than 10 days to 1-hour resolution. Confirm these windows fit your retention needs. | Does not support Thanos downsampling. Downsampled blocks must be removed before historical Thanos blocks are copied in. Plan retention accordingly. |
| Multi-tenancy | Tenants identified by the THANOS-TENANT header on Receive by default. Isolation depends on how you deploy Receive and Query. | Architecture isolates each tenant's series in its own TSDB and requires a tenant ID header on every request. Confirm the isolation model against your audit requirements. |
| Ingest path | Sidecar uploads TSDB blocks every 2 hours. Receive implements remote write and uploads blocks every 2 hours by default. Confirm the data-loss window for your design. | Remote write to the distributor. From Mimir 3.0, the preferred ingest path uses Kafka. Classic mode uses ingesters with local write-ahead logs. Confirm which mode you will run. |
| Object storage backends | Any object storage is an optional dependency. Confirm the backend you plan to use is supported by your Thanos version. | Amazon S3, Google Cloud Storage, Microsoft Azure Storage, OpenStack Swift and local filesystem (single node only). Confirm your backend in the Mimir docs. |
| Scaling claim | No single published figure in the sources. Confirm sizing with your own series counts and query load. | Vendor-tested to handle up to 1 billion active time series in internal testing. Treat this as a vendor claim and confirm it in your environment. |
| Authentication | Authentication is not built in as a tenant gate in the sources. Confirm how your reverse proxy or access layer will enforce it. | Leaves authentication and authorization to an external reverse proxy. Confirm the proxy design before you expose the cluster. |
| Deployment | Components added beside existing Prometheus servers. Not recommended for production on a single node. Confirm the component layout with your platform team. | Helm chart mimir-distributed installs, configures and upgrades Mimir in Kubernetes. Monolithic mode runs all components in one process. Confirm which mode fits your scale. |
Licensing and editions: what AGPL-3.0 and Apache-2.0 mean for your team
Thanos is licensed under Apache-2.0, a permissive license that lets you use, modify and redistribute the code with conditions mainly around notices and patent terms. Grafana Mimir is distributed under AGPL-3.0-only. The AGPL carries the copyleft obligation of the GPL, and it adds a network clause: if you modify Mimir and let users interact with that modified version over a network, the license can require you to offer those users the corresponding source. Whether and how that applies to your internal deployment, contractor-operated clusters or customer-facing services is a question for counsel, not for this page.
- Thanos license: Apache-2.0, as stated in the thanos-io/thanos repository.
- Mimir license: AGPL-3.0-only, as stated in the grafana/mimir repository. The "only" variant matters because it names one version of the license rather than allowing later versions.
- Network clause: triggered by offering modified software to users over a network, so internal-only use and external-facing use can be treated differently.
- Unmodified use: running either project without changes generally carries lighter source obligations, but counsel should confirm how your own distribution and hosting model is classified.
- Procurement file: record which license applies to each component you deploy, including any Helm charts or operators you add around them.
Ask counsel to confirm the network-use analysis for your specific deployment model before the platform team commits to a design.
For platform engineers, the license question is mostly about what you can change and what commercial support exists. The facts supplied for this topic do not name a paid edition, enterprise tier or commercial subscription for either Thanos or Mimir. Prometheus itself has no paid enterprise edition, so the cost of running it comes from infrastructure, storage, implementation and the people who operate it. Confirm directly with Grafana Labs or the Thanos maintainers whether any commercial support or add-on is offered before you assume one exists.
- No paid edition supplied: neither project is described here as having an enterprise build, so do not budget for one until a vendor confirms it in writing.
- Cost components: storage, compute for the components you run, network egress, and the engineering time to operate each project.
- Recurring costs: object storage and compute recur monthly; upgrades and on-call effort recur with each release cycle.
- Forking and patching: the Apache-2.0 license for Thanos makes internal patches simpler to keep private, while Mimir patches carry the AGPL sharing question described above.
- Quote request: ask any vendor to state the license of each component, the support scope, and whether commercial terms change the AGPL obligations.
Before signing any support arrangement, confirm in writing which components it covers and whether it changes your license position.
The license does not change what a compliance assessment asks for. An assessor looks at the controls you have implemented and the evidence that they operate, such as configuration, access records, backup tests, change history and monitoring of the metrics store itself. Choosing Apache-2.0 or AGPL-3.0 does not produce an attestation, a certificate or a regulator's acceptance. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors or certification bodies make those determinations.
- Evidence scope: the same evidence set applies to both options, covering tenant isolation, access control, retention settings and backup or restore records.
- Tenant isolation: Mimir isolates each tenant's data by a required tenant ID header, while authentication is left to an external reverse proxy. Thanos Receive identifies tenants by the THANOS-TENANT header by default. Document how each one is enforced, whichever license you choose.
- Retention records: keep configuration exports for retention and downsampling so an assessor can trace what was kept and for how long.
- Third-party code review: the AGPL network clause may matter to a supplier review, so record the license for each component in your software inventory.
- Confirm with the assessor: ask your auditor which evidence formats they accept before you design the logging and access controls around them.
Raise the license classification with counsel and the assessor early, so the evidence plan reflects your actual deployment model.
Where a Thanos or Mimir implementation usually runs long
The effort in either path sits less in installing components and more in the decisions made before the first block is written. On the Thanos side, a team must size the object storage bucket, lay out its prefixes, set the Prometheus min-block-duration and max-block-duration to equal values when the sidecar uploads blocks, and make sure exactly one Thanos Compact runs against each bucket, because the compactor must run as a singleton per bucket. On the Mimir side, the equivalent work is designing the tenant model, configuring the mimir-distributed Helm chart for the chosen ingest architecture, and placing an authentication and authorization proxy in front of the tenant ID header, since Mimir leaves that job to an external reverse proxy. Confirm with your storage vendor the request and capacity model for your bucket before sizing it, and check the current Helm chart values against your target Mimir release.
Three things slip most often. The first is tenant design, which teams postpone until dashboards already exist. Mimir stores each tenant's series in its own TSDB, so moving a team to a different tenant later means re-homing data, and Thanos Receive identifies tenants by the THANOS-TENANT header by default, which means the header mapping must be agreed with every remote writer. The second is HA-pair deduplication. Thanos merges Prometheus HA pairs through external labels and deduplication, while Mimir ignores Thanos deduplication labels and does not inject external labels into query results, so a historical backfill from both replicas will double-count unless only one replica of each pair is uploaded. The third is alerting rules that depend on query behavior. Recording and alerting rules written against Thanos Query may return different results once the data path changes, so each rule should be tested against the new query endpoint before cutover.
Plan for the upgrade cycle as a recurring cost, not a one-time task. Helm chart upgrades for Mimir touch the ingest path, the store-gateway and the compactor, and the Kafka-based ingest architecture that Mimir 3 prefers adds a stateful dependency that the classic ingester design does not have. Thanos components are upgraded separately from Prometheus and from each other, so the team needs a written compatibility matrix and a rollback plan for each. Ask any implementation partner for a fixed scope that names the upgrade path, the backup of the bucket and the test set used to confirm query parity, because those items decide how long each upgrade stays in a maintenance window.
What drives the running cost of Thanos and Mimir
Both options cost more to run than the software is worth on paper, because the bill is spread across object storage, compute, the people who operate the components and the upgrades that follow. The four cards below separate what recurs from what is paid once, so you can ask every vendor and partner for the same breakdown.
Object storage and compute
Your cloud or hardware provider bills you for the bucket and for the machines that run the components. Storage grows with retention and with the number of active series, and Thanos compaction and downsampling add read and write load on top. Mimir's ingesters, compactors and store-gateways each need capacity sized to the series count. Ask for a sizing estimate tied to your active series, retention period and query rate, and for the object storage class assumed in it.
Operating skills
Mimir runs as a set of microservices from one binary, deployed through the mimir-distributed Helm chart, so your team needs Kubernetes and Helm skills to run it well. Thanos adds components beside existing Prometheus servers, so the skills are Prometheus operations plus running Sidecar, Store, Compact and Query, with a singleton compactor per bucket. Count the engineers who can carry the on-call load for each option, and whether they already know these components.
Support and upgrade work
Mimir 3 adds a Kafka-based ingest path, so a Kafka cluster becomes a dependency you must patch, monitor and upgrade alongside Mimir. Thanos ships releases on its own cadence, and you choose when to take each one, with upgrades touching several components. Grafana offers commercial support for its products, and you should confirm which support terms cover Mimir and what they cost. Ask for a written upgrade plan and the expected effort for each minor release.
One-time migration and design
Migration from Thanos into Mimir is a one-time cost. Thanos blocks must have downsampled data removed, unsupported labels stripped from meta.json and be uploaded from one Prometheus replica per HA pair. Uploaded blocks take about 15 minutes to appear in the bucket index. Design work covers tenant mapping, retention and the ingest path. Ask a partner for a fixed-scope migration plan that lists each cleanup step, the validation queries and the rollback path before any data moves.
Moving Thanos blocks into Mimir and what that move loses
This sequence shows how historical Thanos blocks are cleaned and copied into a Mimir tenant bucket, and what the reader gives up when that history stops being downsampled, deduplicated and immediately queryable.
Confirm the target tenant and bucket layout
Before touching any data, the platform team confirms with the Mimir operators which tenant ID will own the history and which object storage bucket Mimir reads from. The team also confirms that Mimir's compactor is running against that bucket, because uploaded historical blocks depend on it. Done means a written tenant ID, bucket name and tenant prefix are agreed, and a test copy of one block can be listed under that prefix. Ask Grafana whether your Mimir version and storage backend follow the migration guide as written.
Select one Prometheus replica per HA pair
Each Thanos sidecar uploads blocks for its own Prometheus server, so an HA pair produces two overlapping copies of the same series. The team picks one replica from each pair as the source of truth for upload. Because Mimir ignores Thanos deduplication labels, copying both replicas would store duplicate samples under one tenant. Done means a list of source blocks, with each HA pair reduced to a single replica, has been reviewed by the owner of the Prometheus fleet.
Remove downsampled blocks from the copy set
Thanos compaction writes 5-minute and 1-hour resolution blocks alongside raw data. Mimir does not support Thanos downsampling, so these blocks must be excluded before copying. The team filters the candidate list by resolution in each block's metadata and leaves only raw-resolution blocks in the working set. Done means the working set contains no block whose resolution is above raw, and the count of excluded blocks is recorded so the loss can be stated later.
Strip unsupported labels from meta.json
Mimir rejects Thanos blocks that carry labels it does not recognize. For each remaining block, the team edits the meta.json file to remove those labels, working on a copy so the original Thanos bucket stays intact. Done means a validation pass on the edited copies shows no rejected labels, and every original block still exists unchanged in the source bucket for rollback.
Copy blocks under the tenant prefix
The team copies the cleaned blocks into the Mimir bucket under the tenant prefix confirmed earlier. Mimir stores each tenant's series in its own TSDB, so the prefix determines which tenant can query the history. Done means object counts and sizes under the prefix match the working set, and a sample of block directories opens without error when read by the operator tooling.
Load Prometheus history with mimirtool
Where the team also holds plain Prometheus blocks, those go through mimirtool backfill instead of a raw copy, as the migration guide describes. This keeps the two historical paths separate and easier to audit. Done means each backfill command reports success and the team has a log of which blocks came from which path.
Wait for the compactor to update the bucket index
Uploaded historical blocks are not queryable at once. The migration guide says the compactor typically updates the bucket index in about 15 minutes, so the team waits for that cycle and does not read the gap as a failure. Done means a query against the tenant for a known historical time range returns the expected series, and the team records the timestamp of the first successful query.
Document what the move gave up and the reverse path
The team records what the migrated history no longer has: the downsampled resolutions removed earlier, the Thanos deduplication labels Mimir ignores, and the need for a wait before queries work. It also notes that Mimir does not inject external labels into query results, so dashboards must be checked. The reverse path is kept as a documented procedure, since the untouched Thanos source bucket allows a return to Thanos. Done means a signed-off note lists each loss and the rollback steps, and the questions to confirm with Grafana are answered in writing before the move starts.
Questions buyers ask before choosing Thanos or Mimir
Does Thanos or Grafana Mimir cost less to run?
Neither is cheaper by default, because the bill is driven by your estate, not the license. Thanos runs as components beside existing Prometheus servers, so its main costs are the object storage bucket, the query and store layers, the compactor and the Prometheus servers you already operate. Mimir is a multi-tenant cluster that receives remote writes, so its costs center on the ingest path, the compute for its microservices and the object storage holding each tenant's TSDB. Both use the same kind of object storage, so storage cost is shared. Ask any quote to price compute, storage, network egress, backup, the staff hours to run upgrades, and the cost of the Kafka cluster if you adopt Mimir's ingest storage architecture. Both projects are open source, so the recurring cost is infrastructure and people, not a subscription.
How long does a migration from Thanos to Mimir take?
No fixed duration can be given without your data volume, bucket layout and tenant count, so treat any single number with caution. The work has concrete steps: Thanos blocks must be cleaned up and copied into the Mimir bucket under a tenant prefix, downsampled blocks must be removed because Mimir does not support Thanos downsampling, and labels Mimir rejects must be stripped from meta.json. Uploaded blocks are not queryable immediately, and the compactor typically updates the bucket index in about 15 minutes. Scope drives the timeline: the number of blocks, whether you run both systems in parallel, and how many dashboards and alerts move. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for those terms in the proposal.
What skills and time does the work need from my team?
Your team needs working knowledge of Prometheus, object storage access policies and Kubernetes or VM operations, plus a clear owner for the bucket. Thanos adds the most moving parts to existing Prometheus servers, including a sidecar or Receive, a querier, store gateways and a compactor that must run as a singleton per bucket. Mimir asks for familiarity with its microservice targets, the tenant header model and an external reverse proxy for authentication, and it is commonly deployed with the mimir-distributed Helm chart. Plan time for upgrades, capacity tuning, alert rules on the storage pipeline and runbooks for failed compaction. Ask a partner to name the skills it brings, the skills it transfers and the documentation it delivers.
Can an in-house team deploy and run Mimir or Thanos alone?
Yes, many teams do, provided they have the skills above and accept the on-call load. Both are open source, so nothing needs to be purchased to start. The risk lies in day-two work: compactor failures, bucket growth, misconfigured Prometheus settings (for example, block durations that must be equal when the sidecar uploads), and upgrades across releases. If the team is small, a fixed-scope implementation for design, deployment and handover, followed by an optional retainer for upgrades and support, can reduce single-person dependency. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and it works from a written scope.
Does Mimir's AGPL-3.0 license block commercial use?
No. AGPL-3.0 permits commercial use, but it has obligations that your legal team should review. If you modify Mimir and offer it to users over a network, the AGPL requires you to make the source of your modified version available to those users. Running unmodified Mimir inside your own organization does not trigger that obligation for internal users, but your counsel should confirm how your deployment and any customer-facing services fit. Thanos is Apache-2.0, which carries fewer conditions. Treat this as a question for your legal and procurement teams, not a technical default.
How does the Kafka-based ingest path change operations?
From Mimir 3.0, the preferred ingest storage architecture uses Kafka as a central pipeline to decouple reads from writes, while the classic architecture uses stateful ingesters with local write-ahead logs. Adopting Kafka adds a broker cluster to run, monitor, back up and upgrade, along with its own capacity and retention settings. In exchange, ingesters no longer hold the only copy of recent writes in local logs, which changes failure and recovery procedures. Confirm which architecture your target version and deployment chart use, who owns the Kafka cluster, and how recovery is tested. Thanos has no equivalent broker dependency because Receive and the sidecar work directly with Prometheus and object storage.
How DeployOpen helps you choose, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For Thanos vs Grafana Mimir, we start with your Prometheus footprint, retention needs and tenancy model, then write down what the chosen path will and will not do before any work starts.
How we scope
- We confirm how many Prometheus servers, HA pairs and tenants you run today and which teams need access.
- We record retention, downsampling and query requirements, and whether historical Thanos blocks must move.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We deploy the chosen option in your cloud accounts, data centers or air-gapped network, including object storage.
- We configure remote write or sidecar uploads, compaction, tenant headers and authentication at the reverse proxy.
- We test failover, query results and deduplication against your HA pairs before any production cutover.
How we hand over
- You receive architecture notes, runbooks for upgrades and bucket maintenance, and the configuration under your control.
- We document the licensing position and the features in scope so your legal and procurement teams can review them.
- Your operators are trained on day-two tasks such as compactor health, retention changes and restore steps.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning follows the upstream release and support windows you confirm with each vendor.
- Support scope, response expectations and testing cadence are set in the written agreement, not assumed.
