Proxmox VE vs OpenStack: when each one fits your team
Proxmox VE fits when one small team manages a single cluster of its own hardware and self-service stays limited to a handful of administrators. OpenStack fits when several internal tenants need APIs to request compute, storage and networks on their own, and a platform team has the time and skills to run its services. The decision turns on four things: how large the cluster will get, how much self-service and multi-tenant API access you need, how many engineers you can dedicate to running OpenStack services, and how Proxmox per-socket subscriptions compare with OpenStack's six-month release cadence and upgrade planning.
Proxmox VE is one product: KVM and LXC, with Ceph and ZFS storage, managed from one web interface and one cluster file system. For a team leaving VMware with a few nodes, that single surface is a real advantage, and it stays an advantage only while the cluster is run by people who can handle the whole stack. Its high availability features need at least three nodes, shared storage and watchdog-based fencing, so confirm those requirements against your hardware before you count on failover. Subscriptions are priced per CPU socket per year, and every tier includes the same software, so the recurring cost is a support decision rather than a feature decision. Ask your vendor how socket counts change as you add hosts.
OpenStack is a set of separate projects that expose compute, storage and networking through APIs with common authentication. It suits multi-tenant private clouds, but it adds services to operate, and its deployment guides for 2026.1 describe Kolla-Ansible and OpenStack-Ansible as the main installation paths. Upgrades are planned around releases: 2026.2 Hibiscus came out on September 30, 2026, and 2027.1 Indri, a SLURP release that allows skip-level upgrades, is estimated for March 24, 2027. Confirm your release support window on the OpenStack releases site before you pick a version. Staffing is the largest recurring cost, and it is set by the number of services you run, not by license fees, since OpenStack projects are Apache-2.0.
Which platform fits which scenario
This table matches common team situations to the platform that usually fits better, based on cluster size, multi-tenancy, API needs and staffing. Read each row for the reason, then the note for the condition under which the other platform would win. Treat the rows as starting points, since the final choice depends on your hardware, compliance scope and the skills you can hire or keep.
| Scenario | Better fit | Why, and when the other platform wins |
|---|---|---|
| A single site with a few hosts | Proxmox VE | One management plane, KVM and LXC, and built-in ZFS or Ceph keep the stack small. OpenStack would win only if you expect to grow into many tenants and APIs within the planning horizon. |
| Clustered VMware replacement with shared storage | Proxmox VE | Clusters use a multi-master design with the Proxmox Cluster File System, and high availability needs at least three nodes, shared storage and watchdog fencing. OpenStack wins if the replacement must also serve internal self-service consumers. |
| Team needs per-project quotas and APIs for internal developers | OpenStack | Keystone provides identity with projects, roles and mapping rules for federated users, and the APIs support self-service. Proxmox VE user management is oriented to administrators running the cluster, so confirm fit before choosing it for developer self-service. |
| Multi-site private cloud with several regions | OpenStack | OpenStack is built as a modular set of services that can be deployed and upgraded across sites, with SLURP releases allowing skip-level upgrades. Proxmox VE clusters are designed around a single cluster, so multi-site designs need separate evaluation. |
| Environment with no dedicated platform engineers | Proxmox VE | A single integrated product with a web UI reduces the number of services to operate. OpenStack needs staff who can run several projects and deployment tools, so it fits only when that capacity is funded and retained. |
| Team already committed to Ceph for block, object and file storage | Depends on scale | Ceph works with both platforms. Proxmox VE is simpler when Ceph serves only VM disks, while OpenStack fits when Glance, Cinder and Nova all need Ceph-backed storage. |
| Upgrade planning over several years | Confirm with your schedule | Proxmox VE 9.2 is tied to Debian release support, roughly 3 years per the Proxmox FAQ. OpenStack releases every six months, and 2026.1 Gazpacho and 2027.1 Indri are SLURP releases, so plan around those cycles. |
How each platform is built and what that means for operations
Proxmox VE is one integrated stack that a small team can operate from a single web interface. OpenStack divides the cloud into projects and services that you assemble, upgrade and monitor separately. The cards below show where failures are handled, how many moving parts you watch, and which questions to settle before choosing.
One Debian-based stack for compute and storage
Proxmox VE runs KVM virtual machines and LXC containers on Debian, with local storage on ZFS, LVM and directories, and network storage on iSCSI, NFS, CIFS, Ceph and Proxmox Backup Server. Your operations team handles one host OS, one management plane and one upgrade path per node. Check whether your storage mix can be served by these built-in options, and whether a Ceph cluster would be run by the same people who run the hypervisors.
Multi-master cluster with a shared file system
Every Proxmox VE node can perform all management tasks, and the Proxmox Cluster File System replicates configuration to all nodes in real time. Failures in the management layer therefore do not depend on one controller node. The operational check is whether your team can recover quorum and cluster configuration after a multi-node outage, and whether that procedure is written down and rehearsed before go-live.
High availability depends on fencing and shared storage
Proxmox VE high availability needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing. The watchdog resets a failed node before its guests are recovered elsewhere. Confirm that your hardware supports a working watchdog and that shared storage has its own redundancy, because a fencing or storage fault is the failure mode most likely to surprise a team.
OpenStack as modular projects behind shared APIs
OpenStack is a cloud operating system built from separate projects for compute, storage, networking, identity and images, all exposed through APIs with common authentication. Each project has its own services, configuration and release state. Operationally, you own the interaction between projects, so you need people who can diagnose a failure that crosses identity, networking and compute, and you must plan that ownership before adopting it.
Deployment tooling sets the day-two workload
The 2026.1 deployment guides describe Kolla-Ansible, which runs OpenStack services in Docker containers, and OpenStack-Ansible, which deploys into LXC containers or on bare metal. The choice determines how you patch, roll back and inspect services. Ask your partner or internal team which tool they will operate after handover, and who maintains the inventory, secrets and upgrade playbooks over time.
Ceph as the shared backend for OpenStack
Ceph block devices can back Glance images, Cinder volumes and backups, and Nova guest disks, so VMs can boot from Ceph without local hypervisor storage. This makes Ceph a critical dependency for the whole cloud, not just one service. Before committing, confirm the Ceph cluster's size, network design and on-call ownership, since a storage incident then affects images, volumes and running instances at once.
Proxmox VE and OpenStack side by side on capabilities
This table compares Proxmox VE and OpenStack on license, hypervisors, storage, high availability, identity federation, multi-tenant APIs, release cadence and deployment tooling. Read each row as a question to answer for your own environment, since several Proxmox VE tenancy details depend on how you configure it. The main takeaway is that Proxmox VE is one integrated platform, while OpenStack is a set of services you assemble and operate.
| Capability | Proxmox VE | OpenStack |
|---|---|---|
| License | GNU Affero General Public License version 3 (AGPL-3.0) | Official projects must be licensed under Apache-2.0 |
| Hypervisors and containers | KVM virtual machines and LXC containers on one platform | Compute service manages pools of hypervisors; container support depends on the services you deploy, so confirm with your chosen project set |
| Storage options | LVM, directories, ZFS locally; iSCSI, NFS, CIFS, Ceph RBD, CephFS and Proxmox Backup Server over the network | Storage is delivered through separate services; Ceph block devices can back Glance images, Cinder volumes, backups and Nova guest disks |
| High availability requirements | At least three cluster nodes for reliable quorum, shared storage, redundant hardware and watchdog-based fencing | Availability is designed per service and per deployment; plan control plane and storage redundancy with your chosen deployment tool |
| Identity federation | Authentication and user management are built into the platform; confirm external identity options in the Proxmox user management documentation | Keystone federates via SAML 2.0 and OpenID Connect, with mapping rules that match federated users to groups, roles and projects |
| Multi-tenant APIs and self-service | Tenant and self-service model depends on your setup; confirm roles, pools and permissions in the Proxmox user management documentation | Common authentication across compute, storage and networking APIs, with projects as the tenancy unit in Keystone |
| Release cadence | Major releases track the Debian base; Proxmox VE 9.2 was released on May 21, 2026 on Debian 13 lineage | Six-month cycle; 2026.2 Hibiscus was released on September 30, 2026; SLURP releases allow skip-level upgrades |
| Deployment tooling | Installed as a server platform with a web UI and cluster management built in | Kolla-Ansible (containers in Docker) or OpenStack-Ansible (LXC or bare metal), per the 2026.1 deployment guides |
What licensing and editions cost in each platform
Proxmox VE is licensed under the GNU Affero General Public License version 3, so the software itself is free to install and run. The paid item is a subscription, priced per CPU socket per year, and it buys support entitlements and access to the Enterprise Repository rather than extra features. The Community tier is listed at 120 euros per socket per year with no support tickets. Basic is listed at 370 euros with 3 tickets and a 1 business day response. Standard is listed at 550 euros with 10 tickets and a 4-hour response. Premium is listed at 1,100 euros with unlimited tickets and a 2-hour response, according to the Proxmox VE pricing page.
- Same features in every tier: the pricing page states all tiers include the same software features, so a higher tier does not unlock functions.
- Repository access: the Enterprise Repository requires a valid subscription key and is the recommended repository for production. The no-subscription repository is described for testing and non-production use.
- Socket counting: the yearly total scales with CPU sockets per host, so dual-socket hosts double the per-host line. Confirm how your hosts are counted before buying.
- Recurring cost: the subscription renews yearly, so budget it as an operating line rather than a one-time purchase.
Before purchase, confirm in writing which socket count and tier the quote covers, the response times that apply to your region, and whether the Enterprise Repository key is issued per host.
OpenStack is a cloud operating system whose official projects must be licensed under the Apache License, Version 2.0, and the supplied facts describe no vendor edition or per-socket price list. The software is free to obtain, but running it costs engineering time for the modular services, the deployment tooling and the upgrades on each six-month release cycle. The OpenInfra Foundation hosts the project as part of the Linux Foundation. Commercial support comes from third parties, and their terms, pricing and scope must be verified directly with each provider, since they are not covered by the supplied facts.
- What is free: the Apache-2.0 code for official projects, with no licence fee for the software itself.
- What is paid for: internal or contracted staff for deployment, Keystone federation, storage integration such as Ceph block devices, upgrades and day-two operations.
- Third-party support: contract terms depend on the provider. Ask which OpenStack releases and deployment methods they cover.
- Lifecycle cost: stable branches are maintained for approximately 18 months, so a deployment that falls behind must be upgraded to stay supported.
- Recurring cost: staff time and any support contract recur, while the initial build is largely one-time labour.
Before committing, ask any support provider in writing for the supported release list, the response commitments, the upgrade assistance included and the rate structure for your environment.
The two platforms charge for different things, so the yearly total depends on host count, socket count and how much engineering you can staff. Proxmox VE places a predictable recurring line on each socket, while OpenStack moves the spend into people and any external support. Neither platform's total can be estimated from the supplied facts alone, so the comparison should rest on a written quote built from your own host and staff plan.
- Proxmox scaling: cost rises with each CPU socket, and support tier is the only variable that changes the price per socket.
- OpenStack scaling: cost rises with the number of services you operate, the number of sites, and the frequency of upgrades.
- Illustrative example: a team with a small Proxmox cluster may find one subscription tier covers its needs, while a large multi-site OpenStack estate may need dedicated engineers regardless of licence cost.
- Switching cost: moving off either platform later means migrating workloads and retraining staff, which is a one-time expense that grows with estate size.
- Quote inputs: ask for line items per host or socket, support tier and response time, staff roles included, and upgrade assistance.
Before comparing totals, build the same host and staff assumptions for both options so the quotes are measured against one baseline.
What drives the running cost of each platform
Running cost splits into what you buy (hosts, storage, network, subscriptions) and what you staff (people who operate, upgrade and troubleshoot the platform). The two stacks shift these components in different directions, so the quote you request should itemize each one before you compare totals.
Infrastructure and shared storage
A Proxmox VE cluster runs on hosts, a network and storage you already provide, and high availability needs at least three cluster nodes plus shared storage for guests. An OpenStack deployment commonly adds a storage backend such as Ceph, which brings its own nodes, networks and disks. Ask the vendor or partner to price each host role (compute, controller, storage, network) separately, and confirm whether the Ceph cluster is sized as its own tier or shares hardware with compute. Hardware is largely one-time, but refresh and capacity growth recur.
Staffing for OpenStack services
OpenStack is a set of projects and services that your team must install, configure, monitor and troubleshoot together, including identity, compute, networking and block storage. Deployment tooling such as Kolla-Ansible or OpenStack-Ansible shifts some of that work into code, but someone still owns the control plane, upgrades and incident response. This is the largest recurring cost for most teams and is paid as salaried time or as partner retainer hours. Ask for named roles, expected operator hours per month and what an on-call rotation would require.
Proxmox subscriptions and support tiers
Proxmox VE subscriptions are priced per CPU socket per year, and every tier includes the same software features. The tiers differ in support tickets, response time and access to the enterprise repository, which the vendor recommends for production. The software itself can run without a subscription, so the recurring line is a support and repository decision, not a feature license. Multiply socket count by the tier you need, then confirm how each host in the cluster is counted and whether your Ceph packages require the same tier.
OpenStack six-month release upgrades
OpenStack ships a release every six months, and stable branches are maintained for about 18 months. Between SLURP releases you can skip a release, which reduces how often you must run a full upgrade cycle. Each upgrade consumes engineering time for testing, configuration changes and rollback planning, and that time recurs for as long as you run the platform. Choose a target cadence in advance, check whether your deployment tool supports the path you need, and ask any partner whether upgrades are priced per release or included in a retainer.
Proxmox major upgrades and Debian windows
Proxmox VE major versions follow the Debian release underneath them, and each one is supported at least as long as that Debian release has security support, roughly three years. Moving from one major version to the next is a planned event that touches every node, so it recurs about once per Debian cycle rather than every few months. Plan the upgrade window, rehearse it on a non-production cluster and ask for the effort estimate in writing. Confirm which Debian release your current Proxmox version rests on before you commit to a date.
Where implementation projects with each platform run long
Implementation projects on both platforms slip for the same reason: decisions that look like later details are actually foundations. On Proxmox VE, the early decisions are the network design, the storage choice between shared Ceph and local ZFS with replication, and the high availability prerequisites. High availability needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing, so a failed node is reset before its guests restart elsewhere. Teams that buy hosts before settling whether they want Ceph (which needs its own network and disk planning) or ZFS with Proxmox storage replication (which has a replication schedule and a data loss window) often rebuild the storage layer after the first cluster is racked. Your team must supply the node count, the network layout, the storage performance targets and the identity source for PVE users. DeployOpen would scope in writing the cluster build, the storage design, the HA test plan, and the backup target and integration.
OpenStack projects run long for different reasons. The first decision is the deployment method, since the 2026.1 guides cover Kolla-Ansible (Docker containers managed with Ansible) and OpenStack-Ansible (LXC containers or bare metal), and the control plane layout follows from that choice. Three areas then tend to slip. Tenant and quota models are often left undefined, so Keystone projects, roles and Nova quotas get reworked after users arrive. Keystone federation is often treated as the last step, yet mapping rules that match federated users to groups, roles and projects depend on the tenant design. Storage is the third risk: Glance, Cinder and Nova each need a backend decision, and Ceph RBD is a common choice because it lets VMs boot from Ceph. Your team must supply the tenant structure, the identity provider, the network and multi-tenant policy, and an upgrade plan that accounts for the six-month release cycle. DeployOpen would scope the deployment, federation, storage integration and upgrade procedure in writing before work starts.
Moving workloads between Proxmox VE and OpenStack later
This sequence shows the order of work for moving guests from one platform to the other, so the team can see what carries over and what has to be rebuilt before committing to either stack.
Inventory guests, storage and dependencies
The platform team lists every guest, its operating system, its disks and where they live, its network attachments, its backup jobs and the services that depend on it. Application owners confirm which guests are stateful and which can be rebuilt from automation. The step closes when the inventory is signed off by the application owners and each guest has a named owner and a migration method. Without this list, the later steps cannot be scoped, so treat any gap as a blocker rather than a detail to fix during cutover.
Decide the target storage backend
The team chooses the storage the guests will run on after the move. On Proxmox VE, that may mean local LVM, directories or ZFS, or network storage such as NFS, iSCSI or Ceph. On OpenStack, disk images are typically served through Glance, Cinder or Nova, and Ceph block devices can back all three. The decision depends on whether shared storage is needed for high availability and on who will operate it. The step closes with a written storage design that names the backend, the replication or backup approach and the people who will run it. Confirm the exact integration details with each vendor's current documentation before you commit.
Rebuild networks and identity mappings
Networks, VLANs, firewall rules and DNS records are recreated on the target platform, because bridges on one hypervisor do not map directly onto OpenStack tenant networks or Proxmox VE bridges. For identity, the team decides how users and groups from the directory will be matched to target roles. On OpenStack, Keystone federation uses mapping rules that match federated users to groups, roles and projects, so those rules are written and tested here. On Proxmox VE, user and permission management is set up in the platform itself. The step closes when test users can reach the expected networks and hold only the intended permissions.
Migrate images and disks
Disk images are converted and copied into the target storage, and guest configuration such as CPU, memory and boot settings is recreated, since configuration rarely transfers unchanged. Teams often use a supported import path from the source platform, such as the VMware to OpenStack Migration Guide when the starting point is vSphere. Each migrated disk is checksummed or compared against the source before the source is decommissioned. The step closes with a migration log listing each guest, its target, its copy result and any manual changes made to drivers, guest agents or boot configuration.
Rebuild projects, quotas and automation
Multi-tenant structure does not move as data. On OpenStack, projects, quotas, roles and the API consumers that create resources must be designed and built. On Proxmox VE, the equivalent work is the pool, permission and role layout and the scripts or infrastructure-as-code that provision guests. Backup policies are rebuilt for the new platform and tested with a restore. The owning team reviews each tenant boundary and quota against the inventory from the first step. The step closes when provisioning, quota enforcement and a test restore have each been run successfully on the target.
Validate workloads before cutover
Each migrated workload is started in an isolated network or test window and checked against defined acceptance criteria: application health, performance under expected load, connectivity to dependencies, monitoring coverage and the backup restore path. Security checks confirm that firewall rules, certificates and access controls behave as documented. Application owners sign off per workload, and any failed check returns the guest to the migration step. The step closes with a signed validation record for every guest in the inventory.
Cut over and retire the source
Production traffic is moved to the migrated guests during an agreed change window, with a documented rollback path that keeps the source running until the team is satisfied. DNS, load balancer and monitoring targets are updated, and the old guests are kept read-only for a defined retention period set by the organization's own policy. The source is decommissioned only after the rollback window closes and backups of the retired environment are confirmed to be restorable. The step closes when the inventory shows every guest on the target platform and the decommissioning record is filed.
Questions buyers ask before choosing Proxmox VE or OpenStack
How much does a Proxmox VE subscription cost?
Proxmox VE subscriptions are priced per CPU socket per year, and the software itself can run without one. The published tiers are Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros, according to the Proxmox VE pricing page. All tiers include the same software features. They differ in support entitlements (from no support tickets at Community to unlimited tickets with a 2-hour response at Premium) and in access to the enterprise repository, which the Proxmox documentation recommends for production. Your yearly total rises with every socket in every node, so count sockets across the whole cluster before you compare it with a flat or per-host model. Confirm current prices and any tax or reseller terms directly with Proxmox, since they can change.
What do the Proxmox VE subscription tiers actually include?
Every tier includes the same Proxmox VE features, so the choice is about support and repository access. Community has no support tickets. Basic includes 3 tickets with a 1 business day response, Standard includes 10 tickets with a 4-hour response, and Premium includes unlimited tickets with a 2-hour response, according to the pricing page. Teams that run production clusters usually care most about the enterprise repository and the response window, while teams that only need packaged updates and occasional help may be satisfied with a lower tier. Ask Proxmox to confirm what is covered for Ceph packages, escalation paths and hours before you sign.
How much staff time does OpenStack need to run?
OpenStack's effort depends on how many services you operate, how many nodes and tenants you serve, and how often you upgrade. It is a set of projects covering compute, storage, networking, identity and orchestration, so you carry the operational load of each one. The OpenStack project publishes a six-month release cadence with SLURP releases for skip-level upgrades, which means upgrades are a recurring project rather than an occasional patch. Plan for ongoing staff time for deployment tooling such as Kolla-Ansible or OpenStack-Ansible, monitoring, backups, identity federation and upgrades. No single staffing figure is supplied for this page, so ask your candidate partners for a written breakdown of roles and hours tied to your node count and service list.
Can a small team run OpenStack without outside help?
A small team can run OpenStack only if it already has strong Linux, networking and storage skills and accepts that upgrades and troubleshooting will take a large share of its time. Proxmox VE is designed as one integrated stack with a web UI, so a small team can often manage it with less specialized knowledge. OpenStack spreads responsibility across several services and deployment tools, and stable branches are maintained for roughly 18 months, so you must plan upgrades to stay supported. If your team has no one who has operated these services in production, budget for outside help in the first build and the first upgrade. A fixed-scope engagement with written deliverables is one way to get that help, and DeployOpen plans, implements, upgrades and supports self-hosted platforms in your own infrastructure.
How long does a migration from VMware to Proxmox VE or OpenStack take?
Migration duration is driven by the number of VMs, their size and dependencies, the storage and network design you choose, and how much downtime each application tolerates. Proxmox VE is a single platform that you can install, cluster and begin migrating to in stages, while OpenStack requires you to design and deploy its services before the first workload moves. Proxmox provides a migration guide, and OpenStack publishes a VMware migration guide, but neither gives a fixed duration for your estate. Ask any partner for a timeline tied to your inventory, rollback plan and cutover windows, and check it against a written scope before work starts.
Should we hire a consultant or partner for Proxmox VE or OpenStack?
Hire outside help when your team lacks hands-on experience with the chosen platform, when you need a defined deliverable before a deadline, or when compliance evidence must be produced alongside the build. For Proxmox VE, a partner typically helps with cluster design, high availability requirements such as three or more nodes with shared storage and watchdog fencing, backup and testing. For OpenStack, a partner usually adds more value because of the number of services and the upgrade cadence. Before you engage anyone, ask for a written scope with deliverables, timelines, handover documentation and support terms. DeployOpen works on fixed-scope engagements and offers ongoing support as a retainer. It does not issue audit reports or certifications, so compliance evidence still comes from independent auditors.
What cluster size makes OpenStack worth considering over Proxmox VE?
The right answer depends on whether you need multi-tenant self-service APIs and a modular private cloud, not on node count alone. Proxmox VE high availability needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing. Proxmox clusters use a multi-master design where every node can perform management tasks, which suits a single operator team managing one estate. OpenStack becomes relevant when you must expose compute, storage and networking to many internal tenants through common APIs and identity federation via Keystone. Confirm your tenancy model, API consumers and growth plan with both vendors' documentation before you decide.
Can we stay on a Proxmox VE version without losing security updates?
Proxmox VE releases are supported at least as long as the matching Debian release receives Debian security support, which the Proxmox FAQ describes as roughly three years. Proxmox VE 8 on Debian 12 reached end of life in August 2026, so any cluster still on it needs a planned upgrade. Proxmox VE 9.2 was released on May 21, 2026, on Debian 13.5. OpenStack has its own clock: stable branches are maintained for approximately 18 months, and only SLURP releases may enter an unmaintained phase before end of life. Whichever platform you pick, put the upgrade dates on your calendar at the start and ask any partner to include upgrades in the written scope.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Proxmox VE vs OpenStack, we start by testing the workload, team and operating requirements against both options, then build and document only the platform you choose.
How we scope
- We confirm cluster size, workload count, tenancy model and self-service needs before recommending a platform.
- We document the team skills needed to run each option, including OpenStack service operations if that path is considered.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we build
- We plan the hardware, network, shared storage and high availability layout inside your own infrastructure.
- We configure identity integration, such as SSO or federation, and the access model your administrators will use.
- We test failover, backup and restore paths before any production workload moves onto the platform.
How we hand over
- We deliver runbooks, architecture records and configuration documentation written for your own operations staff.
- We walk your administrators through day-two tasks such as patching, upgrades and capacity changes.
- We document the evidence your compliance assessors may request, while audit reports remain the auditor's responsibility.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades, which you should confirm against each vendor's current release and support windows.
- Any change to scope after handover is agreed in writing, with its effort and timing set before the work begins.
