Proxmox VE or OpenStack: which fits your private cloud
Choose Proxmox VE when one integrated cluster will carry your workloads, you want KVM virtual machines and LXC containers managed together, storage comes from Ceph or ZFS, and a small operations group will run the platform. Choose OpenStack when you need multi-tenant self-service, API-driven provisioning across compute, storage and networking, and a dedicated team to operate its modular set of services. The decision turns on four things: how large your cluster will grow, how many tenants will request resources through APIs, how many engineers you can assign to running OpenStack services day to day, and how each platform's upgrade and subscription model fits your budget.
Proxmox VE code is licensed under AGPL version 3, and its subscriptions are priced per CPU socket, include the Enterprise Repository and differ only in support level. That makes the recurring line item easy to forecast for a fixed host count, but it rises as you add sockets. OpenStack's nova repository is Apache-2.0, so the software itself carries no license fee, yet the people who plan, upgrade and troubleshoot its services are a recurring cost you must budget for. OpenStack ships a release every six months, and 2027.1 Indri, a SLURP release that allows skip-level upgrades, is estimated for March 24, 2027, so check the OpenStack release schedule against your upgrade plans. Before you commit, ask each vendor or partner for a written quote covering support, upgrades and the staff hours your environment will need.
Start by writing down three numbers: the cluster size you expect at your next planning cycle, the count of internal tenants that will need self-service API access, and the engineers available for on-call work. If the answers point to one cluster with a few owners, Proxmox VE keeps the operating surface small. If they point to many tenants with separate quotas and API-driven workflows, confirm that Proxmox VE meets those requirements before you shortlist it, and do the same check for OpenStack's staffing demands before you commit to it. Test both answers against your own environment, not against general claims, so the shortlist reflects your actual constraints.
Which platform fits your cluster size and self-service needs
This table maps common operating scenarios to the platform that usually fits better and the condition that decides it. Read each row against your own estate, then confirm the capability details named in the last column with the vendor before you commit.
| Scenario | Better fit | Why and what to confirm |
|---|---|---|
| A single site with a small virtualization estate and a small operations team | Proxmox VE | One integrated product combines the KVM hypervisor, LXC containers and web management, so there is one upgrade path and fewer services to run. Confirm cluster sizing guidance and supported storage layouts with Proxmox. |
| A team that wants Ceph and ZFS managed from one product | Proxmox VE | Proxmox VE includes software-defined storage with Ceph and ZFS as part of the platform, while OpenStack leaves storage to separate projects and backends. Confirm which Ceph release and integration depth the current Proxmox VE version provides. |
| A multi-tenant internal cloud with self-service and API access for several business units | OpenStack | OpenStack is built as a modular set of projects that expose APIs with common authentication across compute, storage and networking. Confirm the tenant, quota and project model you need with the OpenStack project documentation and your chosen distribution. |
| A regulated environment that needs a separate tenant isolation model per business unit | OpenStack | Its project and domain structure and API-driven policy can map to separate administrative boundaries, though the design is your responsibility. Confirm the isolation features your assessor expects, and how your chosen distribution supports them, before you rely on them. |
| A team that already runs Kubernetes and wants VMs alongside containers | Depends on the workload | Proxmox VE runs VMs and LXC containers on its own cluster, while OpenStack can host VMs and containers through its service projects. Confirm how each platform integrates with your existing Kubernetes clusters and identity provider. |
| A team with no dedicated OpenStack operators and a need for predictable upgrades | Proxmox VE | Running OpenStack services means operating several projects, databases and message queues, which adds ongoing skills and effort. Ask any partner or vendor to scope the operational team and upgrade plan in writing. |
| A platform team expecting to upgrade on a fixed long-term cadence | OpenStack | OpenStack ships a release every six months and designates SLURP releases for skip-level upgrades, which suits teams with a planned upgrade process. Confirm the upgrade path and support window for your chosen release with releases.openstack.org. |
| A team comparing subscription terms with release upgrades | Proxmox VE | Proxmox VE subscriptions are priced per CPU socket and differ mainly in support level, which makes the recurring cost easy to model. Confirm current socket pricing and support tiers directly with Proxmox before budgeting. |
How Proxmox VE and OpenStack are built and deployed
Proxmox VE and OpenStack solve the same core problem of running virtual machines on hardware you own, but they get there in different ways. The cards below cover how each product is assembled, where its storage comes from, and what each design asks of the team that runs it day to day.
Proxmox VE as one integrated product
Proxmox VE combines the KVM hypervisor and LXC containers in one platform, with software-defined storage that includes Ceph and ZFS available from the same management layer. A small team can install, cluster and manage hosts without assembling separate projects. Check whether your workloads need KVM virtual machines, LXC containers or both, and whether the storage features you need are covered by the integrated stack before you commit to the platform.
OpenStack as a modular cloud operating system
OpenStack is a cloud operating system that controls pools of compute, storage and networking through APIs with common authentication. It is built as a set of projects and services that you select and combine, so the platform fits the scope of a private cloud rather than a single hypervisor cluster. Expect to design the service catalog, identity model and network layout up front, because those choices shape every later upgrade and integration.
Apache-2.0 licensing of the nova repository
The nova repository, which holds the OpenStack compute service, is licensed Apache-2.0. That permissive license governs the code you deploy, but it does not set your support terms, which come from your distribution or service provider. Ask who provides patches and backports for your chosen release, and confirm whether any vendor distribution you consider adds proprietary components on top of the upstream code.
Ceph as a shared storage backend
Ceph stores data on a single RADOS cluster and exposes object (RGW), block (RBD) and file (CephFS) storage from that one pool. With OpenStack, the same Ceph cluster can back Glance images, Cinder volumes and Nova ephemeral disks, which reduces the number of storage systems to operate. Proxmox VE also supports Ceph, so ask whether you need the object and file interfaces at all, since a Proxmox-only design may not require them.
Fewer moving parts versus more services to run
A Proxmox VE cluster is one product with one upgrade path, one web interface and one set of hosts, which lowers the number of components your team must patch and monitor. An OpenStack deployment runs many independent services, each with its own database, message queue and release cycle, so upgrades must be sequenced and tested across them. Plan monitoring, backup and on-call coverage for each service you enable, not just for the hypervisors.
Confirm which OpenStack services you need
Because OpenStack is modular, the right service set depends on your requirements, and no single list fits every private cloud. Identify which APIs your users, automation and tenants must consume, such as compute, block storage, networking, image and identity, before you choose components. Ask any integrator to write down the included services, their versions and the upgrade path in the written scope so that the deployment matches what you intend to run.
How the two compare on licensing, storage and API features
This table sets Proxmox VE, a single integrated virtualization stack, against OpenStack, a modular private cloud platform, across licensing, storage, API scope, release cadence and identity. Cells marked to confirm reflect facts that depend on your edition, configuration or testing, so verify them before you decide.
| Capability | Proxmox VE | OpenStack |
|---|---|---|
| License of core code | Proxmox VE code is licensed under AGPL-3.0. Paid subscriptions cover support and the Enterprise Repository, not the code itself. | The nova compute repository is Apache-2.0. Confirm the license of each service you plan to deploy, since OpenStack is a set of separate projects. |
| Architecture | Combines the KVM hypervisor and LXC containers in one integrated platform. | A modular set of projects and services that control pools of compute, storage and networking through APIs. |
| Storage options | Software-defined storage including Ceph and ZFS, built into the platform. | Storage is provided through pluggable back ends chosen per deployment. Confirm which back ends your target release supports. |
| Self-service and multi-tenant APIs | Management is centered on a single cluster interface. Confirm how far tenant isolation and self-service portals meet your requirements in your own testing. | APIs control compute, storage and networking with common authentication, which is designed for self-service and multi-tenant use. Confirm tenancy model and quota design for your scale. |
| Identity integration | Confirm supported directory and SSO options for your edition and version with the vendor. | Common authentication runs across services through the platform's identity layer. Confirm the identity back ends your deployment will use. |
| Release cadence and upgrade path | Proxmox VE 9.2, based on Debian 13.5 Trixie, was released May 21, 2026. Confirm upgrade steps between major versions in the vendor's documentation. | A release ships every six months. 2026.2 Hibiscus was released September 30, 2026, and 2027.1 Indri, a SLURP release, is estimated for March 24, 2027, and allows skip-level upgrades. |
What is licensed, what is paid for and what upgrades demand
Proxmox VE code is licensed under the GNU Affero General Public License version 3 (AGPL-3.0). The license covers the code, but the commercial model is set by subscriptions. Subscriptions are priced per CPU socket, each tier includes the Enterprise Repository, and the tiers differ only in support level. The purchase decision therefore turns on two questions: what support terms you need, and what the socket count on each host will cost you over time.
- Per-socket pricing: Fees scale with the CPU sockets in each host. A design with fewer, denser hosts changes the fee total, so model socket counts for the hardware you plan to buy.
- Enterprise Repository: Each subscription tier includes access to it. If your change control requires vendor-tested packages, confirm how updates reach hosts that have no subscription.
- Support level as the only tier difference: Features do not change between tiers, so compare response times, channels and escalation terms in writing.
- Recurring renewals: Subscriptions recur, so ask for the renewal period, price change terms and what happens when a host is retired or added.
- Upgrade effort: Upgrades follow the Proxmox VE release line, such as 9.2 released May 21, 2026, and your team owns scheduling, testing and rollback on each node.
Before requesting a quote, count sockets per host for the hardware you plan to run over the next few years and ask Proxmox for its support tier terms in writing. For current terms, see the Proxmox VE subscriptions page.
OpenStack is a modular set of projects, and its code is open source under licenses that vary by project. The nova repository, for example, is licensed Apache-2.0. The supplied sources do not list a subscription fee for the software itself, so the recurring cost of running OpenStack is usually staff time for operating the services, plus any commercial support you choose to buy from a vendor or distribution.
- Apache-2.0 code: Check the license in each project's repository, because components may carry different terms.
- No software subscription in these sources: Confirm with any distribution or vendor whether they charge for packages, updates or support, and get the answer in writing.
- Six-month release cadence: OpenStack ships a release every six months, and 2026.2 Hibiscus was released on September 30, 2026. Plan a standing upgrade cycle for each release.
- SLURP skip-level upgrades: 2027.1 Indri is estimated for March 24, 2027 and is a SLURP release that allows skip-level upgrades. Treat the date as an estimate until release, and confirm the supported upgrade path before you plan around it.
- Staff time as the main cost: Your engineers operate compute, storage, networking and identity services, and they test every upgrade against your workloads.
Ask any distribution or consulting vendor for its support scope, supported releases and fee basis in writing. Confirm each release date against the OpenStack releases site before you schedule an upgrade.
A fair comparison separates one-time costs from recurring ones and names who is paid for each. For Proxmox VE, the license is free to use, but subscriptions are an ongoing fee to Proxmox per socket. For OpenStack, the software carries no subscription in the supplied sources, so the main payees are your staff, any support vendor you hire and any implementation partner. DeployOpen plans, implements, integrates and supports self-hosted platforms in your own infrastructure, works on fixed scope agreed in writing, and does not publish a price list, so a quote follows from the scope.
- One-time costs: Hardware, design, installation, migration, integration with identity and monitoring, and initial training.
- Recurring costs: Proxmox subscriptions, any OpenStack support contract, staff time for upgrades and patching, and retainers for ongoing support if you buy them.
- Cost drivers: Socket counts and host count on Proxmox, the number of OpenStack services you run and the number of releases you upgrade through each year.
- Scope boundaries: Who handles backups, hardening, documentation and evidence for compliance readiness, and whether that work is in the fixed scope or in a retainer.
- Quote requests: Ask for line items by host and by service, the assumptions behind each line, what is excluded and what changes if the hardware plan changes.
Ask every bidder to price the same three-year scope, with the same hardware, upgrade count and support tier, so the totals can be compared directly.
How self-service and multi-tenant APIs change the decision
API-driven, tenant-aware provisioning is the main reason teams move toward OpenStack. OpenStack controls pools of compute, storage and networking through APIs that share common authentication, and it is built from separate projects that can be deployed and extended independently (see the OpenStack software overview). Proxmox VE is an integrated stack managed through its web interface and API, with permissions granted to users and groups on resource paths. When tenants are few, known and trusted, a single Proxmox VE cluster run by a small administrator group can serve the business well. In that model, the isolation boundary is administrative, so the real question is whether every tenant can safely hold broad access.
Identity is where the two platforms diverge most in practice. For OpenStack, confirm which identity backend your distribution uses, whether it federates with your identity provider over SAML or OIDC in the release you plan to run, and how project-scoped roles map to your existing groups. For Proxmox VE, confirm which authentication realms are configured, whether directory or OpenID realms can map group membership to roles, and how API tokens are scoped, rotated and revoked. Do not assume SSO covers the API as well as the web interface. Ask the implementation partner to document each mapping in writing before any tenant is onboarded.
Self-service changes the decision once developers request resources without filing administrator tickets. You then need per-project quotas, an approval or automation path, network separation between tenants and an audit trail that ties each request to a named identity. OpenStack is organized around projects and quotas, so these controls are part of its model, but they still need to be configured and tested. In Proxmox VE, self-service usually means a portal or automation layer built on the API with pool-level permissions, so confirm which quota controls exist in your version before you commit. A proof of concept should create two tenants, try cross-tenant API calls with a token from the other tenant, check network and storage visibility, and confirm that the audit log records each action.
Where OpenStack and Proxmox VE projects usually run long
Most delays in these projects come from decisions made late or staff who were not planned for, not from installation itself. The cards below cover the points where a written scope should be most specific about who does what and what is confirmed before work starts.
Running multiple OpenStack services
OpenStack is a modular set of projects and services rather than one product, so a private cloud means operating several components that each need configuration, upgrades and troubleshooting. Your team must supply operators who already understand identity, networking and message queues at this level. Ask the implementer to name each service in scope, who owns it after handover, and which operational runbooks are delivered.
Designing tenant networking and storage
Tenant networks, external connectivity and the storage backend are usually the longest design decisions in an OpenStack build, and they are hard to change once tenants exist. Your network team must supply address plans, routing policy and the storage hardware or Ceph design you intend to use. Confirm in writing which network models and storage backends are configured, and how isolation between tenants is tested.
Integrating identity and self-service portals
Self-service and multi-tenant access depend on identity integration with your directory, project-level roles and a portal or API users actually adopt. Your identity team must supply the directory structure, group-to-role mappings and the approval workflow for new projects. Confirm which identity sources, MFA method and portal features are included, and whether tenant onboarding is documented for your operators.
Planning upgrades against the release cadence
OpenStack ships a release every six months, so an upgrade plan must be tied to a supported path rather than a calendar guess. Your operations team must supply a maintenance window, a test environment that mirrors production and an owner for post-upgrade checks. Ask the implementer whether the plan targets skip-level upgrades where a SLURP release is available, and what the rollback procedure covers.
Proxmox VE cluster and storage choices
A Proxmox VE cluster is simpler to stand up, but the storage decision still shapes the project. Choosing between built-in Ceph, ZFS on local disks or another backend affects failure domains, network requirements and how VMs move between nodes. Your team must supply node count, network topology and the workloads that need shared storage. Confirm the storage design, quorum handling and how subscription support levels are chosen for each node.
Migrating existing workloads
Moving running virtual machines, their disks and their network settings is often the step that takes longest, because each workload has its own dependencies and downtime limits. Your application owners must supply an inventory, acceptable outage windows and rollback criteria for each system. Ask the implementer to list the conversion method for each source platform, which systems are pilots, and how data is verified after cutover.
What drives running cost on each platform
Start by separating one-time spend from recurring spend, because the two platforms shift cost into different places. On Proxmox VE, the largest recurring line item is the per-socket subscription, which Proxmox VE subscriptions describes as including the Enterprise Repository, with tiers that differ only in support level. Hardware, storage and network build are one-time costs on both platforms, but on a hyperconverged Ceph or ZFS design, drives and network capacity often move the total more than the license does. Ask the quote to list the socket count per node, the node count, the support level for each tier, and whether storage components are covered in the same line.
On OpenStack, the core software is Apache-2.0 licensed, so the recurring cost sits mainly in people and support rather than in a socket-based fee, unless you buy a commercial distribution. Compute, storage, networking and identity run as separate projects, and each needs operators who understand its failure modes and who patch it on schedule. The release model adds recurring work: OpenStack releases ships a new release every six months, with 2026.2 Hibiscus released on September 30, 2026, and the next SLURP release, 2027.1 Indri, estimated for March 24, 2027. Ask any provider who performs each upgrade, how many upgrade cycles per year the quote assumes, and whether support covers production incidents outside business hours.
Training and migration are the costs most often left out of comparisons. A team with Linux, Ceph and KVM experience can usually run Proxmox VE with a short ramp-up, while OpenStack requires learning its APIs, service dependencies and configuration model before the first production workload. Budget design, migration and initial build as one-time items, and keep them separate from recurring subscriptions, staff time, upgrades and monitoring. Before comparing totals, ask each provider to name every service in scope, the assumed cluster size, who owns each upgrade, and the support level. Then confirm the upgrade path from your current Proxmox VE version against the Proxmox VE roadmap, so the upgrade effort is priced into the plan.
Moving between Proxmox VE and OpenStack later
This sequence lets a team move workloads in either direction without a single cutover, keeping the source platform running until the target has proven its backups, access and tenant boundaries. It ends with a documented, retired source and a target that owners can operate without the migration team.
Inventory workloads, tenants and dependencies
Platform engineering lists every VM, container, template, network, storage volume and API consumer on the source, then maps each one to an owning team or tenant. For OpenStack sources, include projects, quotas and role assignments. For Proxmox VE sources, include cluster membership, node-level configuration and any scripts or tools that call the Proxmox API. The output is a signed inventory with a named owner and a recovery point objective for each item, so nothing moves without a decision on record.
Decide which storage and identity components carry over
Architects decide what stays and what is replaced. Ceph can be kept as the data layer if the target also consumes it, but Proxmox VE with Ceph and OpenStack with Ceph back ends are configured differently, so confirm the pool layout, replication settings and client authentication before assuming reuse. Identity sources such as LDAP or SAML providers usually transfer as external systems, but the way each platform maps groups to roles differs. Write down which components are reused, which are rebuilt and which are retired, with the reason for each.
Build the target platform alongside the source
Engineers stand up the target in a separate environment, sized from the inventory and connected to the same identity sources and backup repositories in read-only or test mode. Cluster configuration, tenant networking, API integrations and automation are built here rather than copied, because they depend on platform-specific constructs. Confirm the target's support and upgrade path before go-live, including OpenStack's release cadence if that is the destination. The check is a working test tenant or test cluster that passes the security baseline and backup restore tests.
Confirm conversion tooling and test in a non-production environment
Before any production move, ask each vendor or project which conversion and import tools they support for the specific source and target versions, and what they do not convert. Run those tools against copies of representative VMs and data sets in a non-production environment. Record disk format changes, guest driver changes, network mapping errors and any manual steps. The output is a tested runbook for each workload class, with failed cases documented and a decision on whether each one moves, is rebuilt or stays put.
Migrate workloads in waves by risk
The team moves lower-risk workloads first, then shared services, then critical systems, one wave at a time. Each wave has a rollback plan that keeps the source copy intact until the owner signs off. Data on shared storage is copied or re-attached according to the decision made earlier, and VM images are converted or rebuilt from templates. Automation and API consumers are switched after their target endpoints are verified. The check for each wave is a documented owner sign-off and a clean monitoring window.
Validate backups, restores and access controls
Operators run restore tests on the target for a sample of migrated workloads, not only the backup jobs that report success. They verify that backup schedules, retention and encryption settings were recreated, that tenant or role boundaries match the approved design, and that administrative access is limited to the intended groups through the identity source. Auditors and compliance leads should receive the evidence of these tests. The output is a restore log and an access review that the security owner accepts in writing.
Retire the source platform in a controlled way
Once every wave is accepted, the team freezes changes on the source, takes a final backup, and records the configuration exports and inventory for audit retention. Licenses or subscriptions on the source are reviewed with the vendor, including Proxmox VE per-socket subscriptions or any OpenStack support contract, so that renewals stop only after the target is accepted. Source hardware is wiped or repurposed according to the data handling policy. The completion check is a closed decommissioning record that names who approved each step and where the retained evidence is stored.
Questions buyers ask before hiring outside help
What drives the cost of a Proxmox VE or OpenStack implementation?
The written scope drives cost more than the platform choice does. DeployOpen does not publish a price list, so a quote follows from an agreed scope that names the number of hosts, the storage design, identity integration, backup targets and any compliance evidence to prepare. Labor is the largest variable. Design, build, hardening, migration and handover are one-time costs. Software costs differ by platform. Proxmox VE subscriptions are priced per CPU socket and recur on each term. The OpenStack code in the nova repository is Apache-2.0 licensed, but the quote should still state which commercial support or distribution contracts it assumes. Ask for an itemized quote that separates one-time work from retainers, lists which OpenStack projects are in scope, states hardware assumptions and names who pays for each license or vendor contract.
How long does a Proxmox VE or OpenStack project take?
Duration depends on the scope, and the written scope sets the timeline for each platform. A single-cluster Proxmox VE build with one storage design and one identity integration is a different project from a multi-service OpenStack deployment with several tenants, self-service workflows and a migration of existing workloads. Drivers include the number of nodes, whether storage uses Ceph or ZFS, network design, how many OpenStack services are in scope, how identity is integrated, how much existing workload must move and how much evidence a compliance assessment will need. DeployOpen agrees timelines and deliverables in writing before work starts, so ask for milestones tied to named deliverables rather than a generic template. Confirm any change windows your organization requires, because they often set the pace of cutover.
What does an implementation need from our internal team?
The work needs named people who can make decisions and grant access. At minimum, expect the team to provide owners for networking, storage, identity and backup, plus someone who can approve the tenancy and self-service model. Access to hardware, out-of-band management, change windows and test environments is needed early. OpenStack places heavier demands on the team because it is a modular set of projects and services that controls compute, storage and networking through APIs, so more people will need to review designs and test upgrades. Proxmox VE asks for fewer distinct services but still needs Linux, storage and network skills to validate the cluster. Ask DeployOpen to list each role, the hours expected from each person and the handover sessions included in the scope.
Can an internal team run Proxmox VE or OpenStack without outside help?
A small Linux team can often run a single Proxmox VE cluster after handover, provided it has storage, networking and backup skills and someone trained to respond to failures. OpenStack is harder to run in-house because it spans many services that must stay in step through each six-month release, and operators need to understand how those services interact. Confirm three things before deciding. First, count the people who can operate each platform during on-call hours and during upgrades. Second, check whether the team has run the storage backend and identity integration before. Third, decide whether you want DeployOpen to build only, to build and hand over, or to provide ongoing support and upgrades through a retainer. The OpenStack software overview describes the modular design that drives this workload.
Are Proxmox per-socket subscriptions cheaper than OpenStack upgrade staff time?
The two costs are hard to compare directly because one is a vendor invoice and the other is internal labor. Proxmox VE subscriptions are priced per CPU socket and differ only in support level, so the license line is predictable and recurs on each term. OpenStack ships a release every six months, 2026.2 Hibiscus was released on September 30, 2026, and 2027.1 Indri, a SLURP release that allows skip-level upgrades, is estimated for March 24, 2027. Upgrade effort recurs with that cadence, and the skip-level path changes how often you must touch the platform. Build a three-year model with your own staff hours, socket counts, release plan and any retainer quotes. The current Proxmox VE pricing page lists the subscription terms to use in that model.
What should we confirm before choosing between Proxmox VE and OpenStack?
Confirm the requirements that decide the platform before you ask for a quote. Start with the expected cluster size over the planning period, the number of tenants, and whether users need self-service provisioning through APIs. Next, confirm the storage backend, the identity provider, the backup targets and the support model your organization requires. Then confirm the licensing position for each platform with your legal team, including that Proxmox VE code is AGPL-3.0 licensed. Also confirm the upgrade cadence your operations team can sustain and whether you need compliance evidence from the start. Ask DeployOpen to document each assumption in the written scope so the team can revisit it when requirements change.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For Proxmox VE vs OpenStack, we start from your cluster size, self-service needs, tenancy model and the team you can staff to run either stack.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which platform fits your workloads, node count, storage needs and identity sources.
- We confirm your team's operating skills and whether an ongoing retainer should cover upgrades and support.
How we build
- We plan the cluster layout, storage design, networking and access model for the platform you select.
- We integrate identity, backup, monitoring and logging with your existing internal systems and controls.
- We run security testing against the build and document the configuration and any open findings.
How we hand over
- You receive architecture, configuration and runbook documentation written for your operations staff.
- Handover includes knowledge transfer so your team can run upgrades, backups and day-two changes.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any attestations.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover platform upgrades, including release changes such as Proxmox subscription or OpenStack upgrade planning.
- Quotes follow from the written scope, so ask for the scope, assumptions and exclusions before comparing offers.
