Kubernetes vs Docker Swarm: when a handful of servers is enough
For a small number of servers running a few services, Docker Swarm is often enough if your team wants the least moving parts, and Kubernetes is the better choice when you expect the platform to grow in tooling, people or lifespan. Swarm mode is built into Docker Engine, so a cluster is formed from engines you already run, without a separate control plane product to install. Docker's documentation describes it as a way to natively manage a cluster of Docker Engines called a swarm, and notes that it should not be confused with the older Docker Classic Swarm, which is no longer actively developed.
Swarm's service model is declarative: each service declares how many tasks should run, and updates are applied to nodes incrementally at rollout time. Nodes communicate with mutual TLS and encryption enforced by default, which covers a common first security question without extra components. Choose Swarm when the workload is a few stateless services, the team already knows Docker Compose, and you can accept a smaller ecosystem. Choose Kubernetes when you need Apache 2.0 licensed software with a large third-party ecosystem, a release cadence of roughly three minor releases a year (about every 14 weeks), and a conformance program that lets you move between distributions. The CNCF Certified Kubernetes program, which lists over 90 offerings, checks that those distributions support the required APIs.
The decision turns on three questions. First, which tools you need beyond scheduling, such as ingress, certificate management, GitOps, policy enforcement or operators for databases, since those are where Kubernetes has the broader catalog. Second, your hiring pool: confirm whether candidates and contractors you can realistically reach already know Kubernetes or Swarm. Third, how long the platform must run. A cluster expected to live for many years with several teams usually justifies Kubernetes' operating load, while a short-lived internal service may not. Ask DeployOpen or your own engineers to write down those answers before choosing, and check the current Swarm and Kubernetes support windows in the official documentation.
Which platform fits which scenario
This table maps common team situations to the platform that usually fits better and the condition that decides it. Read each row against your own host count, skills and audit obligations, and treat the rows marked as items to confirm as questions to settle before committing.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| A few stateless services on two or three hosts | Docker Swarm mode | Swarm needs only Docker Engine and a manager quorum, so it suits a small footprint if you do not need operators, custom resources or a broad add-on ecosystem. |
| Existing Docker Compose files to keep running | Docker Swarm mode | Swarm accepts Compose-style service definitions with less rewriting; confirm which Compose keys your files use and whether Swarm supports them before migrating. |
| Need for multi-team namespaces and policy | Kubernetes | Kubernetes namespaces, RBAC and admission controls such as Pod Security Standards give finer tenant separation than Swarm, which you must confirm meets your isolation requirements. |
| GitOps-driven delivery with a controller watching Git | Kubernetes | Tools such as Argo CD and Flux target Kubernetes resources directly; with Swarm you would build and maintain the reconciliation loop yourself. |
| Regulated environment needing audited configuration | Kubernetes, if the auditor accepts its controls | Kubernetes has more documented hardening guidance and third-party benchmarks, but Secrets are stored unencrypted in etcd by default, so encryption at rest must be configured and evidenced. |
| Team with no container orchestration experience and a tight operations budget | Docker Swarm mode | Swarm has fewer moving parts to learn, but the smaller tool set means more custom work later; confirm your team's capacity for that trade-off. |
| Growth expected to dozens of nodes or many services | Kubernetes | Kubernetes is the wider ecosystem and has regular releases; confirm your planned version support window against the project's published end-of-life dates. |
| Docker Classic Swarm is already in use | Confirm before deciding | Docker states Classic Swarm is no longer actively developed and is distinct from Swarm mode, so confirm which one your current setup runs. |
How Swarm and Kubernetes are built, and what that means for operations
Swarm and Kubernetes both schedule containers across several machines, but they put very different components under your care. The cards below cover what each platform asks you to run, back up and upgrade, with the etcd layout that drives most of the Kubernetes overhead.
Swarm managers and workers in Docker Engine
Swarm mode is built into Docker Engine, so every node already runs the same daemon. You declare manager and worker roles on those nodes, and the managers hold the cluster state and elect a leader through Raft. Because the control plane lives inside the engine you already operate, there is no separate cluster database to install. Check how many managers you run, since a small manager set is what keeps the cluster available when a node fails. Also confirm that you are using Swarm mode and not Docker Classic Swarm, which Docker no longer actively develops.
Kubernetes control plane and kube-apiserver
Kubernetes splits the control plane into kube-apiserver, kube-controller-manager, kube-scheduler and the etcd datastore, and each component is a separate process you install, configure and upgrade. kubeadm bootstraps these components on your hosts, but it does not manage their lifecycle afterward. Plan for a TCP load balancer in front of kube-apiserver on port 6443 so that kubelets and operators keep a stable endpoint when one control plane node is down. Confirm who owns certificate rotation and component upgrades before you commit.
Stacked and external etcd layouts
kubeadm documents two topologies. In stacked etcd, each control plane node also runs an etcd member, so the minimum is three control plane nodes. In external etcd, the etcd cluster runs on its own hosts, which adds machines but separates control plane failures from datastore failures. Either way, etcd should have an odd member count, and five members is the recommended production size. Ask your team who will patch and monitor those extra hosts, because that work does not appear in the Swarm model.
etcd backups and restores
Every Kubernetes cluster stores its state in etcd, so losing etcd without a backup means rebuilding workloads from manifests and secrets outside the cluster. Kubernetes documentation expects you to have a backup plan and to take snapshots with etcdctl snapshot save. Restores use etcdutl, which is a separate tool that you must install and rehearse on every control plane image you run. Schedule snapshot jobs, store them off the cluster, and test a restore before you need one. Swarm stores its Raft state on managers, so the same discipline applies there, but the procedure and tooling are simpler.
Side-by-side capabilities, scheduling, updates, security and ecosystem
This table compares Kubernetes and Swarm mode on license, scheduling, updates, support windows, authentication, secret storage and ecosystem. Where a cell says to confirm, the supplied research does not settle that point, so verify it with Docker or in the Kubernetes documentation before you decide. The main takeaway is that Swarm's declarative service model is simpler to start with, while Kubernetes has the more detailed published release, authentication and conformance record.
| Capability | Kubernetes | Docker Swarm mode |
|---|---|---|
| License | Apache 2.0, per the kubernetes/kubernetes repository. | Licence terms not covered in supplied facts. Confirm with Docker. |
| Desired state and scheduling | Not covered in supplied facts. Confirm scheduling behavior in the Kubernetes docs. | Declarative service model: each service declares the number of tasks to run. |
| Scaling | Not covered in supplied facts. Confirm scaling options for your workloads. | Scale by changing the declared task count for a service. |
| Rolling updates | Not covered in supplied facts. Confirm update strategy in the Kubernetes docs. | Applies service updates to nodes incrementally at rollout time. |
| Upgrade cadence and support window | Three minor releases a year on about a 14-week cycle. Three latest minors maintained; patch support about one year. | Confirm Swarm release and support window with Docker. |
| Authentication options | X.509 client certificates, OpenID Connect and JWT bearer tokens, webhook tokens, or an authenticating proxy. | Nodes use TLS mutual authentication. Confirm user authentication options with Docker. |
| Secret storage defaults | Secrets are stored unencrypted in etcd by default. Enable encryption at rest or use an external store. | Not covered in supplied facts. Confirm secret storage defaults with Docker. |
| Network policy and admission controls | Pod Security Standards are documented. Confirm which policy and admission controls you run. | Not covered in supplied facts. Confirm network policy and admission options with Docker. |
| Ecosystem and CNCF conformance | CNCF Certified Kubernetes program, with over 90 certified offerings. | Classic Swarm is no longer actively developed. Swarm mode is separate. Confirm ecosystem and roadmap with Docker. |
What is free, what is paid, and what each platform's license means for you
Kubernetes is licensed under Apache 2.0, as stated in the kubernetes/kubernetes repository. That license lets you run, modify and redistribute the software inside your own infrastructure without paying the project a license fee. Nothing in the upstream license points to a paid tier of the project itself, so confirm that point with any vendor you buy from. What you usually pay for is staff time, infrastructure and any support contract you choose.
- Apache 2.0 terms: The license covers use and modification in your own environment. Have your legal team review it if you plan to ship modified builds to customers.
- Third-party support: Commercial support and distributions come from vendors and community projects. The CNCF conformance program lists over 90 certified offerings, which shows variety but not equal support terms.
- Conformance is not a support promise: Certification checks that the required Kubernetes APIs are present. It does not set response times, patch windows or who answers when a control plane node fails.
- Recurring internal cost: Upgrades, etcd backups and control plane operation are work your team carries every release cycle, and that work usually costs more over time than any support fee.
Before budgeting, ask each candidate vendor for a written list of what its support fee covers, which Kubernetes versions it supports and how long each version receives patches.
Swarm mode is built into Docker Engine, so clustering comes with the engine you already run. Docker's documentation describes it as the native way to manage a cluster of Docker Engines. Do not confuse it with Docker Classic Swarm, which that documentation says is no longer actively developed. Your budget question is the Docker Engine license and any paid tier for the version you deploy, and this page cannot settle that for you.
- Orchestration sits in the engine: Swarm mode ships with Docker Engine, so you do not license a separate cluster product for orchestration itself.
- Confirm Docker's current terms: Check Docker's current license terms and any paid tiers for your Engine version before budgeting. Get the answer in writing and keep it in your procurement file, because container runtime terms change.
- Classic Swarm is a different product: If an old guide or tool refers to Swarm, confirm which one it means before you copy its setup steps.
- Recurring operating work: Patching the engine on each node, rotating the certificates Swarm uses for TLS between nodes and watching manager quorum stay with your staff regardless of license price.
Ask Docker for the license terms that apply to your Engine version and for a statement of which features, if any, sit behind a paid tier, then compare that answer with the support terms in the Kubernetes tab.
Open-source platform costs fall into a few buckets: license fees, vendor support, implementation work and ongoing operations. License fees for Apache 2.0 Kubernetes are not charged by the project, and Swarm is included with Docker Engine subject to Docker's terms. Support, implementation and operations are where the money moves, and each one is paid to a different party. Separate them in every quote you compare so one platform does not look cheaper only because its work is missing from the estimate.
- Vendor support: You pay a support provider by subscription if you choose one. Subscriptions usually recur, and their price depends on the scope and response terms in the contract.
- Implementation: One-time work to plan, build, harden and document the platform. DeployOpen works under fixed-scope agreements, with scope, deliverables and timelines agreed in writing before work starts, and quotes follow from that written scope.
- Ongoing operations: Upgrades, backups, testing and on-call coverage recur. DeployOpen offers retainers for ongoing support, upgrades and continuous testing, so you can set that option against in-house staffing.
- Infrastructure: Servers, storage and network capacity are paid to your cloud provider or data center operator and scale with cluster size and redundancy choices.
When you request quotes, ask each provider to separate one-time build work from recurring support, and to state which Kubernetes or Docker versions the quote covers.
What drives the running cost of each platform
Running cost for a small server fleet comes from four places: the hosts that run the control plane, the people who install and upgrade it, the support contract you buy, and the upgrade cadence you must keep up with. Kubernetes and Swarm differ most on the first two and the last one, so each card below asks what you pay for and what to put in a written quote.
Control plane and etcd hosts
Kubernetes needs at least three control plane nodes in the kubeadm high availability model, with etcd either stacked on those nodes or run as a separate cluster on its own hosts. The Kubernetes documentation recommends an odd number of etcd members and a five-member cluster in production, so the host count can rise faster than your workload. Swarm uses manager nodes that share cluster state, and those managers also run workloads unless you drain them. Ask any quote to price the control plane hosts, the load balancer in front of the API server and the etcd backup storage as separate line items.
Skilled staff time for operations
Most of the recurring cost is engineer time spent on installs, upgrades, certificate rotation, etcd backups and incident response. Kubernetes asks for people who understand the API server, scheduler, controllers, kubelets and etcd, plus the add-ons you choose. Swarm needs fewer components, so a generalist administrator can often run it, but that advantage shrinks once you add monitoring, secrets handling and ingress by hand. Your quote or internal estimate should state how many named people are on call, what hours are covered and whether the work is one-time build or ongoing operation.
Support contracts and consultant scope
Upstream Kubernetes and Docker Engine are open source, so the license itself carries no fee. What you buy is support, an implementation engagement or a retainer. Commercial Kubernetes distributions are listed in the CNCF conformance program, which checks that a distribution supports the required APIs, so conformance does not by itself tell you who answers the pager. Docker's Swarm documentation covers the mode built into Docker Engine, and vendor support terms vary. Ask whether a quote is a fixed-scope build, a recurring retainer or both, and what happens to scope when a version reaches end of life.
Upgrade cadence and version skew
Kubernetes ships about three minor releases a year, and the project maintains only the three most recent. Upgrades must move the kube-apiserver one minor version at a time, and kubelets may lag by up to three minor versions. Every minor upgrade therefore becomes a planned cycle covering control plane, nodes and add-ons, and it repeats on a schedule you cannot skip for long. Swarm has a smaller surface to upgrade, but Docker Engine upgrades still need node drains and testing. Ask the provider for the upgrade calendar, the rollback plan and whether the quote covers two or more upgrades per year.
Moving from Swarm to Kubernetes, or back, step by step
This sequence turns a Swarm stack into a Kubernetes deployment (or the reverse) with a clear inventory, a rebuilt security baseline, and a cutover that can be rolled back until the old stack is retired. Each step ends with a check that tells you it is safe to move on.
Inventory services, stacks and stateful data
List every stack, service, network, secret, config object, published port and volume on the Swarm cluster, along with the image tag each service runs. Mark each service as stateless or stateful, and record which ones depend on a database, a shared volume or a fixed host. This is usually done by the platform owner with the application teams, and the output is a single register that every later step refers to. You are done when each service has an owner, a data classification and a named target (Kubernetes, Swarm, or retire), and the register has been reviewed by the people who run the applications. Stateful services belong at the top of the list because they set the schedule for everything else.
Decide what becomes manifests or Helm charts
Translate each Swarm stack file into the Kubernetes objects that will replace it: Deployments or StatefulSets for workloads, Services for internal discovery, Ingress or Gateway objects for published routes, and ConfigMaps for non-sensitive settings. Decide whether a Helm chart, Kustomize overlays or plain manifests fit your team's review process better, and whether the same definitions will serve more than one environment. Confirm with the application owners which Swarm placement constraints and resource limits must be carried over, since these are rewritten rather than copied. You are done when a written mapping exists for every service in the register and a reviewer has signed off the translation of networking and access rules.
Stand up the cluster with the chosen install path
Build the Kubernetes cluster using the install path your team has selected, following the kubeadm high availability guide where a multi-node control plane is required, and confirm the control plane layout (stacked etcd or external etcd) before provisioning hosts. For a handful of servers, check the etcd member count and backup plan against the Kubernetes documentation before any workload moves. Establish the cluster's authentication model, such as OIDC or certificate-based access for administrators, so that human access is defined before applications arrive. Your check is a healthy cluster that passes node readiness, a test deployment that schedules, and a tested etcd snapshot that can be restored in a non-production environment. Ask your implementation partner to confirm the hardware and host count in writing before work starts.
Rebuild secrets handling before any secret moves
Swarm secrets do not carry over, and Kubernetes Secrets are stored unencrypted in etcd by default. Before you load any credential, configure encryption at rest for the API server's stored data, restrict list and watch access to Secrets with least-privilege RBAC, and decide whether an external store is needed through the Secrets Store CSI Driver. Rotate every credential that was exposed in Swarm configuration files during the migration rather than reusing it. The output is an encryption configuration applied to the control plane, a written RBAC matrix, and a test showing that a service account without rights cannot read another namespace's secrets. Do not proceed until that test passes.
Move volumes and stateful data
For each stateful service in the register, choose the data path first: export a consistent backup from the Swarm volume, restore it into a Kubernetes persistent volume, and validate the application against the restored copy. Stateful databases should be moved with their own native dump or replication tooling, not by copying live files. Test restore time in a rehearsal, because this is the step where switching cost grows fastest with the number of stateful services. Your check is a restore of each dataset into the target cluster, a read-back test by the application owner, and a documented rollback path that keeps the Swarm source intact until cutover succeeds.
Cut over traffic in stages
Move one service at a time, starting with stateless, low-risk services that have clear health checks. Point DNS or the external load balancer at the new endpoint with a short rollback window, and watch error rates, latency and logs for the agreed period before moving the next service. Keep the Swarm service running and reachable until the new path is proven. The output is a traffic record for each service showing the date of switch, the owner who accepted it, and any rollback that was used. Stateful services move last, after the data step has been rehearsed under production-like load.
Retire the Swarm stack and close the register
Once every service has run on the target platform for the agreed observation period, remove the Swarm stacks, revoke the Swarm join tokens, drain and leave the nodes, and delete the stored secrets and configs from the Swarm managers. Archive the stack files, the translation mapping and the cutover records so that auditors and future operators can trace each change. Update monitoring, backup jobs and runbooks to point at the new platform. You are done when the Swarm cluster no longer serves traffic, no credentials remain on its managers, and the register shows every service with an owner and a live target.
Where implementation projects usually run long
The etcd backup and restore test is where Kubernetes projects most often overrun, and it is the first item to scope in writing. Swarm keeps its cluster state in the managers' Raft store, so the setup surface is smaller: you initialize a manager, join workers and tokens, and the cluster enforces TLS mutual authentication and encryption between nodes by default. Kubernetes asks you to make more structural choices before the first workload runs. The kubeadm high availability guide describes a stacked topology, with etcd on the control plane nodes, or an external etcd cluster, with at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. Kubernetes documentation says etcd should run with an odd number of members, recommends five in production, and needs a backup plan. Budget time for etcdctl snapshot save and, more importantly, for a restore rehearsal with etcdutl in a test environment, because a snapshot that has never been restored is not evidence of recovery.
Identity integration and Pod Security Standards are the next two places where effort accumulates. Kubernetes does not create user objects. It accepts X.509 client certificates, bearer tokens including OpenID Connect and JWT, webhook token authentication or an authenticating proxy, so you must choose which mechanism matches your directory and then test group mapping, token lifetimes and the RBAC roles that follow from it. Swarm has no equivalent user model to configure. On the workload side, Pod Security Standards need namespace labels, a rollout from warn and audit modes to enforce, and fixes for workloads that run as root. Secrets are stored unencrypted in etcd by default, so encryption at rest and least-privilege RBAC for list and watch access are part of the same workstream. Monitoring also grows with the cluster, since you will need metrics and alerting for the control plane, not only for applications.
Upgrade planning is the most underestimated item. The version skew policy requires kube-apiserver to be upgraded one minor version at a time, ahead of the controller manager, scheduler and kubelets, and kubelets may lag up to three minor versions. The Kubernetes project maintains only the three most recent minor releases, so a cluster on an old minor needs a planned path, not a single jump. Confirm your change windows, the staff who will run each upgrade, and a staging cluster that mirrors production before signing a fixed-scope agreement. Ask DeployOpen to state these inputs in the written scope, with deliverables for backup verification, identity testing, admission policy rollout and an upgrade runbook. Scope and timelines are agreed in writing before work starts, so these items should be listed as deliverables rather than assumed.
Questions buyers ask before choosing or hiring help
Can a small team run Kubernetes without outside help?
Yes, a small team can run Kubernetes on its own, but the practical question is whether it has enough people who can operate the control plane, etcd, networking, storage and upgrades without depending on one person. Upstream Kubernetes is open source under Apache 2.0, so the software cost is zero, and the effort sits in people. The kubeadm high availability guide describes stacked and external etcd topologies that start at three control plane nodes with a TCP load balancer in front of kube-apiserver on port 6443. Before deciding, confirm that at least two engineers can perform a control plane upgrade and an etcd restore from a snapshot, and that someone owns on-call for the cluster. If those skills are missing, a fixed-scope implementation with documentation and handover is one way to close the gap.
What drives the effort and cost of Kubernetes compared with Swarm?
The main cost is staff time, and Kubernetes carries more of it because it has more moving parts. Swarm mode is built into Docker Engine, so there is no separate orchestrator license or install, and its declarative service model, incremental updates and built-in TLS between nodes cover the basics. Kubernetes adds a larger set of components: an etcd datastore that needs backups, a control plane that must be upgraded in order, a container network, ingress, storage classes and an authentication model based on X.509 certificates, OpenID Connect or webhook tokens. Effort rises with the number of clusters, the number of add-ons, how often you upgrade and how many compliance controls you must evidence. Ask any provider for a quote that separates one-time build work from recurring upgrades, monitoring and support, and that lists each add-on in scope.
How long does a typical implementation take, and what decides it?
No supplied fact gives a typical duration for either platform, so treat any number you hear as unverified until it is tied to a written scope. The timeline is decided by how many hosts and clusters are involved, whether etcd runs stacked or external, how much of the platform is hardened and documented, which add-ons such as ingress, storage, backup and monitoring are included, and how many systems must integrate with existing identity and logging. Swarm usually takes less time to stand up on a few servers, but any engagement that adds security hardening, testing or compliance evidence will extend the schedule for either option. Ask the provider to show milestones, acceptance criteria and the client responsibilities that could delay each one.
What does the work need from our own staff?
Your staff must own decisions that a provider cannot make for you: which applications run where, who approves access, which backup retention applies, and who is paged when the cluster degrades. For Kubernetes, the engineering skills include Linux administration, certificate and token management, network policy, storage, and reading etcd health and snapshot output with etcdctl and etcdutl. For Swarm, the skills are narrower but still include manifest authoring, overlay networking and node join tokens. Expect a named technical owner, access to the hypervisor or cloud accounts, change windows for upgrades and a plan for training. Confirm these items in writing before work starts so that handover is measured against an agreed list.
Can we keep Swarm and add a few Kubernetes services?
Yes, you can run both in the same environment, but you should treat them as two platforms with separate ownership, not as one cluster that happens to contain both. Swarm stacks and Kubernetes workloads do not share a scheduler, so you must decide how service discovery, ingress, secrets and TLS certificates cross the boundary, and how each platform is patched and monitored. The added operating load is usually the second set of runbooks and the duplicated identity and logging integrations. Before committing, list the services that would move, confirm that the Kubernetes portion will meet your Kubernetes version support window, and check whether a split across hosts is simpler than a shared network. Docker's documentation describes Swarm mode as a built-in cluster feature, so verify its current roadmap with Docker directly.
How do we ask for a fixed-scope quote that we can compare?
Ask for a quote built from a written scope that names the platform, the number of hosts, the topology, the add-ons, the documentation set, the testing and the handover criteria. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list, so the quote follows from that scope. Request the same scope from every bidder so the numbers are comparable, and ask each one to separate one-time build work from recurring upgrades, support and testing retainers. Also ask what is excluded, what client inputs are required, what happens if the scope changes and how acceptance is verified. A useful test is whether the quote lets you explain, line by line, who does what and when.
Which Kubernetes version and support window should we plan around?
Plan around the minor versions the Kubernetes project still maintains, because patches stop for older releases. The project maintains the three most recent minor releases, and as of September 2026 those were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027), according to kubernetes.io. Releases arrive about three times per year on a cycle of roughly 14 weeks, so an upgrade plan is a recurring task, not a one-off. The version skew policy requires the API server to be upgraded one minor version at a time and allows kubelets to lag by up to three minor versions. Confirm your upgrade cadence, your test environment and the staff who will run each upgrade before you agree on a support model.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Kubernetes or Swarm decision can be tested against your environment before anything is built. We start from your workloads, team and existing tooling, then agree the scope in writing before work begins.
How we scope
- We review your server count, workload mix, uptime needs and the team that will operate the cluster.
- We define in writing which platform fits, and which parts of the migration or build are in scope.
- Engagements are fixed-scope, with deliverables and timelines agreed before any work starts.
- We identify what your own environment must confirm, such as hosts, networking and storage.
How we build
- We install and configure the chosen platform on your virtual machines or bare metal hosts.
- For Kubernetes, we lay out the control plane and etcd topology and configure encryption at rest for Secrets.
- For Swarm, we configure the manager and worker nodes, service definitions and rolling update settings.
- We run security testing against the build, covering applications, APIs and infrastructure.
How we hand over
- We document the architecture, configuration, backup steps and the day-two procedures your team will run.
- We deliver tested backup and restore procedures, including etcd snapshots for a Kubernetes control plane.
- We provide a migration plan for moving existing workloads, with rollback steps agreed in advance.
- We walk your operators through the runbooks so the handover is tested by the people who will run it.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
- Upgrades follow the release and support windows of the platform you choose, planned with your team.
- We can prepare systems and evidence for compliance assessments, although independent auditors issue any reports.
- Ask any provider which upgrade path, support window and skew policy applies to your chosen version.
