Replacing Azure Local with an open-source alternative: what Proxmox VE and Ceph provide
If your renewal for Azure Local arrives as a per-physical-core monthly charge plus a separate Windows Server guest subscription, and you need your workloads to stay in your own data center, Proxmox VE with Ceph is the main open-source option for a hyperconverged replacement. Harvester and XCP-ng are narrower alternatives: Harvester fits teams already comfortable with Kubernetes and KubeVirt, and XCP-ng with Xen Orchestra fits teams that want a simpler virtualization-only cluster. Before you compare, confirm current Azure Local licensing terms directly with Microsoft, because this page does not carry licensing figures and the per-core rates and guest subscription rules can change.
Azure Local is not only a hypervisor and storage stack. Its Azure-side services, such as Azure Arc management and Azure Monitor, must be replaced separately. Proxmox VE provides its own web interface, clustering, high availability and backup integration, and Ceph supplies the distributed storage layer, but neither reproduces Azure policy, Azure RBAC or Azure-hosted monitoring. List every Azure dependency your cluster uses today, including update management, billing and log retention, and assign an owner and a self-hosted replacement for each one. Ceph's Object Gateway can cover S3-compatible storage needs, and the Ceph Dashboard supports SAML 2.0 single sign-on, which helps with identity integration.
Plan the Ceph side as a separate sizing exercise. Proxmox VE high availability needs at least three cluster nodes, shared storage for guests and watchdog-based fencing, and Ceph's hardware recommendations call for a dedicated drive per OSD, enterprise-class SSDs for metadata and bonded network links across two switches. Size memory for peak load and benchmark your hardware before purchase. Ask any implementation partner, including DeployOpen, for a written scope covering node count, Ceph replication versus erasure coding, network design and the Azure service replacements, because these decisions drive most of the operating effort.
Which Azure Local capabilities map to open-source components
This table maps the main capabilities of an Azure Local cluster to Proxmox VE, Ceph, Proxmox Backup Server, Harvester and Xen Orchestra, with a coverage note on each row. Read the coverage column first, because the gaps are where migration planning and operating effort usually land, and confirm every Azure capability against the current Azure Local documentation before you decide.
| Capability | Open-source component | Coverage note |
|---|---|---|
| VM hosting on Windows and Linux guests | Proxmox VE (KVM) or Harvester (KubeVirt) | Full coverage for standard VM hosting. Windows guests need VirtIO drivers. Guest licensing for Windows stays with you either way. |
| Clustering and high availability | Proxmox VE cluster with HA manager | Needs at least three nodes, shared storage and watchdog fencing. Confirm the failover behavior you need against your own test results. |
| Hyperconverged storage | Ceph (RBD) inside Proxmox VE, or Longhorn in Harvester | Ceph covers replicated and erasure-coded pools. Sizing, network design and skills are your responsibility, not a built-in service. |
| Live migration | Proxmox VE live migration; Harvester live migration | Available in both. Test with your storage layout and network, since migration speed depends on those choices. |
| Software-defined networking | Proxmox VE SDN and Linux bridges | Covers VLANs and basic virtual networks. Azure Virtual Network features such as Azure-native routing and policy have no direct equivalent. |
| Backup | Proxmox Backup Server | Covers VM and container backup and restore. Azure Backup integration and centrally managed cloud vaults need a separate design. |
| Web management console | Proxmox VE web interface; Xen Orchestra for XCP-ng | Covers cluster operations. A hybrid control plane spanning Azure and on-premises resources is not provided, so confirm this gap with your Azure Arc requirements. |
| Identity and single sign-on | Ceph Dashboard SAML 2.0 or OAuth2; Proxmox VE user management | Dashboard SSO is documented for Ceph. Confirm how Proxmox VE logins integrate with your existing directory before committing. |
| Object storage | Ceph RADOS Gateway (S3 and Swift APIs) | Covers S3-compatible access with IAM-style APIs. Azure Blob Storage features, such as tiers and identity integration, need individual confirmation. |
| Azure Policy and Azure Site Recovery equivalents | No direct open-source equivalent in this stack | Gap. Policy enforcement and orchestrated disaster recovery must be designed with separate tools and runbooks. Confirm the Azure features in use with current Azure Local documentation. |
Which open-source option fits an Azure Local estate
Azure Local is a hyperconverged platform with billing tied to physical cores and a separate Windows guest subscription. The options below each cover part of that picture, from a single hyperconverged cluster to larger private cloud orchestration. Every option leaves Windows guest licensing as a separate question to settle before any migration.
Proxmox VE with Ceph
The closest hyperconverged match to Azure Local, combining KVM virtual machines, LXC containers and a multi-master cluster in one web interface. Ceph RBD can serve as shared VM storage, but high availability needs at least three nodes, shared storage for guests and watchdog-based fencing so a failed node is reset before its guests restart elsewhere. Check that your hardware and network design meet these requirements before you size the cluster.
Harvester on Kubernetes
A hyperconverged platform built on Kubernetes, KubeVirt and Longhorn storage, maintained by SUSE under the Apache-2.0 license. It suits teams that already operate Kubernetes and want VMs managed alongside containers. Confirm your team can run Kubernetes operations, and check the vm-import-controller add-on for the VMware and OpenStack source systems you plan to migrate from.
XCP-ng with Xen Orchestra
XCP-ng pools provide live migration and a mature management layer through Xen Orchestra, which also covers backup scheduling and replication. It does not include a built-in Ceph layer, so shared storage must come from an external SAN, NFS or another storage design. Ask Vates about support plans and confirm that the storage you choose meets your availability targets before committing.
OpenNebula
An Apache-2.0 private cloud orchestrator for teams running several clusters that need unified provisioning, quotas and user management. Its Enterprise Edition adds SLA-based support, LTS releases and maintenance packs through an annual subscription. The trade-off is a larger operational model than a single hyperconverged cluster, so weigh the training and process effort against the Azure Local portal you are replacing.
Apache CloudStack
An Apache-2.0 infrastructure-as-a-service platform that orchestrates KVM, XenServer, VMware vSphere, Hyper-V and other hypervisors under one management layer. It fits organizations that run mixed hypervisors or plan a phased move, but it is the heaviest option to operate for a single small cluster. Test the hypervisor and storage combinations you need in a lab before committing to a design.
How a Proxmox VE and Ceph cluster is designed for production
Production design starts with node count and failure handling. Proxmox VE high availability needs at least three cluster nodes for reliable quorum, shared storage that guests can reach from any node, and redundant hardware. It also needs watchdog-based fencing, so a node that has failed is reset before its guests are restarted elsewhere. Without fencing, a guest could run on two hosts at once and corrupt its disks. Plan the watchdog configuration and test it on purpose by isolating a node, because a cluster that has never failed over in a test has not been proven. For a team replacing Azure Local, the three-node minimum is the baseline, and the design should be sized so that the surviving nodes can carry the workloads of a failed node at peak load.
Ceph sets most of the storage hardware decisions. The Ceph hardware recommendations advise a dedicated drive per OSD, and for HDD-based OSDs they advise moving the WAL and DB onto shared SSDs. Use enterprise-class SSDs for metadata, and bond network links across two switches so one switch failure does not isolate a node. Size memory for peak use rather than calm periods, since recovery and rebalancing after a failure add load. Ceph's own guidance is to benchmark before buying, because no two clusters are alike. Ask your hardware vendor for a test run with your own VM mix, and measure latency and recovery time, not only raw throughput.
Release planning matters as much as hardware. At the time of writing, the actively maintained Ceph release lines are Tentacle (20.2.x) and Squid (19.2.x). The Ceph releases page estimates Squid's end of life as October 31, 2026, so a cluster deployed on Squid today needs an upgrade path to a later release line before that date. Confirm the current end-of-life dates on the Ceph releases page before you fix a schedule, and plan the Proxmox VE and Ceph upgrade windows together, since both move on their own cadence.
What Azure services do not carry over to a self-hosted cluster
Azure Local ties several operations to Azure control plane services. When the Proxmox VE and Ceph cluster runs in your own data center, each of those services needs a replacement or a deliberate decision to drop it. Confirm every dependency in your own Azure Local deployment before you plan the migration.
Azure Arc and portal management
Azure Local uses Azure Arc and the Azure portal for cluster inventory, VM lifecycle and role-based access. In Proxmox VE, the cluster is managed through its own web interface, with users, groups and permissions defined locally. Teams must decide how administrators sign in, which roles map to existing groups, and how cluster changes are logged. Check which Arc-enabled resources, policies and portal workflows your operations team uses daily, and confirm each one has an owner after cutover.
Azure Monitor and Log Analytics
Azure Monitor collects host metrics, guest telemetry and alerts from Azure Local into Log Analytics workspaces. Once the cluster leaves Azure, those signals stop arriving unless you forward them. Rebuild collection with Prometheus and Grafana for metrics, and with OpenTelemetry collectors for traces and logs, then recreate each alert rule. Confirm which dashboards, alert routes and retention settings your on-call team depends on, because none of them move automatically.
Azure Backup and Site Recovery
Azure Backup and Azure Site Recovery protect VMs and replicate them to Azure or a secondary site. Proxmox VE does not provide these services. Plan backups with Proxmox Backup Server, and plan replication or disaster recovery to a second cluster separately. Confirm recovery point objectives and recovery time objectives in writing, test a full restore of a clustered workload, and verify that backup jobs cover every VM disk before you retire the Azure-side jobs.
Azure Policy and Microsoft Defender
Azure Policy enforces configuration baselines on Azure Local, and Microsoft Defender reports security posture and threats. Neither reads Proxmox VE hosts by default. Define baselines as code, scan hosts and guests with an open-source tool such as Wazuh or OpenSCAP, and send findings to your existing ticketing process. Confirm which policy assignments and Defender recommendations are compliance evidence, since those records must be rebuilt in your own system.
Azure Update Manager
Azure Update Manager schedules patching for Azure Local hosts and reports compliance from Azure. A Proxmox VE cluster is patched with the standard Debian and Proxmox package tools, so maintenance windows, rolling host reboots and Ceph health checks must be scheduled by your own team. Confirm how your current process handles cluster quorum and live migration during patch windows, and document who approves each rollout.
Running the new cluster alongside the rest of the Microsoft estate
If Windows Server guests and Active Directory stay in place, the hypervisor change affects one layer of the estate. Domain controllers, DNS, DHCP, file services and the backup agents that protect them still depend on the network paths and identity services they used on Azure Local, so map those dependencies before the first VM moves. Proxmox VE does not host the directory for you. Domain controllers either run as guests on the new cluster or stay on existing hardware, and clients keep authenticating to them.
- Identity: Place at least one domain controller where every site can reach it during cutover, and confirm that time synchronization from the domain hierarchy still works after the hosts change.
- DNS and DHCP: Keep authoritative zones and DHCP scopes on the Windows side until each segment moves, and record which VLANs the Proxmox bridges must trunk.
- Backup: Confirm with your backup vendor whether the current agent and catalog remain supported once guests leave Azure-managed infrastructure. Azure-hosted backup dependencies need a named replacement.
- Ceph Dashboard single sign-on: The Ceph Dashboard supports SAML 2.0, and OAuth2 when cephadm runs the Management Gateway and OAuth2 Proxy services. This covers the Ceph storage console only, not Proxmox VE logins. Confirm the steps for your Ceph release in the Ceph Dashboard documentation.
- Microsoft licensing: Windows Server guests remain licensed under your Microsoft agreement after the hypervisor changes. Ask your Microsoft licensing advisor which guests qualify for the rights in your agreement and whether the Windows Server licenses still cover the cores in the new hosts.
Before the first domain controller moves, check which of these services Azure Local currently provides and confirm a replacement for each one.
When most workloads are Linux, the move can be planned as a full platform change. The remaining work is to replace the Microsoft-hosted services that the cluster used without noticing, mainly directory binding, name resolution, monitoring and backup. Linux guests usually authenticate through an LDAP or Kerberos-based directory, so the new cluster needs a clear decision on which directory serves it and which accounts administer the hosts.
- Identity: Choose the directory that serves Linux logins and Proxmox VE administration, and confirm which user realms the Proxmox VE user management model should map to. Record the service accounts that the old platform used.
- DNS: Move internal zones to the new DNS servers, update host records and reverse zones, and test resolution from each VLAN before cutting over.
- Backup: Proxmox Backup Server is one option for protecting Proxmox VE guests. Confirm the retention, encryption and restore tests your compliance scope expects, and keep a restore test on the schedule.
- Ceph Dashboard single sign-on: Use SAML 2.0 if your identity provider already issues SAML assertions. Use OAuth2 only if you deploy the Management Gateway and OAuth2 Proxy services with cephadm, because the Dashboard depends on them for that path.
- Windows guests: Any remaining Windows VMs, such as a few file servers or line-of-business applications, still need Windows Server licenses and, where applicable, client access licenses. Confirm these before the cluster is sized.
Close the project by listing every service that lived on Microsoft infrastructure and confirming that each one now has an owner and a tested replacement.
During a hybrid period, Azure Local and Proxmox VE both run production workloads. The main risks are duplicate administration, split DNS answers and double payment for host capacity. Both platforms should authenticate against the same directory so that administrators do not hold separate local accounts on each side. Decide early which platform owns each workload group and which network segments each cluster can reach.
- Identity: Keep one authoritative directory for both clusters. Avoid local administrator accounts on Proxmox VE that exist only for the migration, and remove them when the move ends.
- DNS: Avoid two authoritative answers for the same zone. Use delegation or separate subdomains for workloads that move in stages, and test resolution from both sides.
- Azure-connected services: Azure Local features that depend on Azure monitoring, management or backup will stop or change when workloads move. Confirm what Azure still sees during the overlap and what the wind-down terms in your contract require.
- Ceph Dashboard single sign-on: Configure the Ceph Dashboard SSO once, through SAML 2.0 or OAuth2 with the Management Gateway, and assign roles from the same groups used for Proxmox VE. This keeps the storage console and the cluster under one access model.
- Microsoft licensing: Azure Local is billed per physical core per month, so host cores on both platforms may be paid for during overlap. Windows guest licenses follow the guest, so count each Windows VM once on whichever platform runs it. Ask your Microsoft and Azure account teams how billing ends for each node.
Before the parallel run starts, write down the cutover date for each workload group and the date Azure Local stops being billed for each node.
How to migrate Azure Local workloads to Proxmox VE and Ceph
This sequence moves workloads from Azure Local to a self-hosted Proxmox VE and Ceph cluster in an order that protects production, keeps a rollback path open, and ends with decommissioning only after the exit date is confirmed. The Azure Local export path is not covered by a supplied source, so each step asks you to confirm the method for your own disk and configuration formats.
Inventory VMs, guests, disks and dependencies
Your team builds a complete list of every VM on the Azure Local cluster, including the guest OS and version, disk count and format, virtual network and storage paths, attached devices, and which VMs depend on each other (for example, a database that an application server calls). Tag each VM as critical or non-critical and note any that rely on clustering or Windows-specific features such as Failover Clustering or Azure-connected services. Confirm with Microsoft documentation and your own environment which disk and configuration formats your Azure Local VMs use before choosing an export method. The step is done when the inventory is signed off by the workload owners and every VM has a target migration wave.
Size and build the new hardware and Ceph layout
Your infrastructure team sizes the Proxmox VE nodes and a Ceph cluster against the inventory's total CPU, memory and storage needs, plus headroom for failure and for the migration window when old and new capacity run together. Follow the Ceph hardware recommendations: a dedicated drive per OSD, WAL and DB on shared SSDs for HDD-based OSDs, enterprise-class SSDs for metadata, bonded network links across two switches, and memory sized for peak use. Benchmark a pilot before purchase because no two clusters are alike. The step is done when the hardware bill of materials matches a documented Ceph layout and a benchmark run confirms the storage meets the inventory's I/O profile.
Form the Proxmox VE cluster with fencing and networking
Your platform engineers install Proxmox VE on each node, join them into a cluster, and configure separate networks for management, cluster traffic, storage replication and guest traffic. Proxmox VE 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. Deploy Ceph with cephadm on the storage nodes, then add it to Proxmox VE as RBD storage. Test a node failure in a non-production environment and confirm that fencing resets the node and that HA restarts a test guest on another node. The step is done when the failover test passes and the results are documented.
Validate backup and restore with Proxmox Backup Server
Your backup team deploys Proxmox Backup Server, connects it to the new cluster, and schedules backups of representative test VMs covering Windows and Linux guests. Run a full restore to an isolated network, boot the restored VM, and check application data and login. Repeat the test for a clustered or database workload if one exists in the inventory. Record restore times and any guest issues, and confirm that Azure Local backup copies remain available until the migration is complete. The step is done when a restore has been verified for each guest type and the recovery procedure is written down.
Move non-critical workloads first
Your migration team moves the non-critical VMs from the inventory, starting with the lowest-risk workloads. Export each VM from Azure Local using the method you confirmed in the inventory step, then import the disks into Proxmox VE with the import methods described in the sibling Hyper-V migration guides, such as qm disk import for disk images and manual reconfiguration of the VM definition. Install VirtIO drivers on Windows guests before the first boot, then check network, boot mode and storage paths. Keep the source VM powered off but intact until the workload owner signs off. The step is done when each non-critical VM runs on Proxmox VE, passes its functional checks, and has a successful backup.
Move clustered workloads in dependency order with rollback
Your team moves the critical and clustered workloads in the order the dependency map sets, databases and identity services before the applications that call them. For each wave, write a rollback plan that names the source VM to power on, the DNS or load balancer change to reverse, and the data sync point to return to. Freeze writes, take a final export and a Proxmox Backup Server snapshot, cut over, and run the agreed validation tests before the next wave starts. Clustered Windows workloads that depended on Azure Local cluster features need a redesign on Proxmox VE and Ceph, which you should confirm with the application vendors. The step is done when each wave passes validation and workload owners accept the cutover in writing.
Decommission Azure Local after the confirmed exit date
Once every workload has run on Proxmox VE for an agreed stability period and the rollback window has closed, your team removes remaining VMs and data from Azure Local, documents the final state, and archives configuration and audit records that your compliance obligations require. Confirm the exit date, notice periods and any Azure billing terms in writing with Microsoft or your reseller before cancelling Azure Local, Windows Server guest subscriptions or related services. Check whether data retention rules require keeping copies of Azure Local logs or backups. The step is done when the cancellation confirmation and the decommission record are filed, and no Azure Local subscription bills after the confirmed exit date.
How the cost of Azure Local compares with a self-hosted Proxmox VE and Ceph cluster
Azure Local is billed per physical core per month, and the Windows Server guest subscription for each VM is a separate line item, so the recurring Azure bill grows with the core count of every host in the cluster, not with the number of workloads. Azure-side service charges, such as those for the management and monitoring services your team enables, can be additional and should be listed separately. Ask Microsoft or your reseller to quote the current core counting rules for your hardware, whether hyperthreading or unused cores are counted, which Azure services are required versus optional, and how Windows Server guest licensing is applied to each VM. Confirm these terms in writing, because they change and the answers determine most of the Azure side of the comparison.
On the Proxmox VE side, the hypervisor software is free and open-source, and subscriptions are priced per occupied CPU socket per year: 120 euros for Community, 370 euros for Basic, 550 euros for Standard and 1,100 euros for Premium, according to the Proxmox VE pricing page. Every tier includes the same features, and the tiers differ in support entitlements and enterprise repository access, so you can run without a subscription, although production use is better served by one. Ceph is licensed under LGPL and has no paid edition from the project, which means the storage software has no license fee. The recurring costs that remain are hardware refresh, drives, networking, staff time and support. Ceph's hardware recommendations call for a dedicated drive per OSD, enterprise-class SSDs for metadata, and bonded links across two switches, and those choices raise hardware cost more than any software line.
One-time costs include architecture and sizing, the migration of VMs and any Windows guest driver work, testing of failover and backup restores, and runbook creation. Recurring costs include hardware maintenance, drive replacement, power, staff and support. Costs go up when hosts or sockets are added, when Ceph is sized for peak memory use, and when a higher support tier is needed for production. They go down when fewer sockets carry the same workload and when the team already has Linux and Ceph skills. When requesting a quote from DeployOpen, ask for a fixed-scope written proposal that lists design, implementation, migration, testing, documentation and any ongoing support as separate deliverables with agreed timelines. DeployOpen does not publish a price list, so the proposal should show what each item covers before you compare it with the Azure and Proxmox figures.
Questions buyers ask before replacing Azure Local
How long does a migration off Azure Local usually take?
No single duration fits every estate, so the schedule depends on what has to move and how much downtime each workload can tolerate. The main drivers are the number of VMs, the total size of their disks, how many workloads must stay available during cutover, and how much of the hardware, network and storage design must be built before any VM is copied. Proxmox VE high availability needs at least three cluster nodes, shared storage, redundant hardware and watchdog-based fencing, so cluster and Ceph design often sets the critical path. Ask for a written plan that lists migration waves, a cutover window and a rollback point for each workload, and confirm the import method for each guest with the Proxmox migration guide.
How much work will our internal team need to put in?
Internal effort is driven mostly by how much of the environment is documented, how quickly owners can approve changes, and how many application teams must test their workloads after the move. Your team will need to supply an inventory of VMs, dependencies, backup requirements and network rules, plus named people for change approval, testing and sign-off. Expect time spent on maintenance windows, rollback testing and operational handover, which recur as the platform changes after go-live. Ask any implementation partner for a written list of the internal roles and hours it assumes, and compare that list with the people you can release from day-to-day work.
Can our team run a Proxmox VE and Ceph migration without outside help?
Some teams can, particularly those with experience in Linux administration, storage and network design, and virtualization operations. The question is less about whether the software can be installed and more about whether your team can design the cluster, size Ceph, prove backups work and handle failures under pressure. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Ask your team to list which parts of the design and runbooks it could own today, and where it would need help.
What skills do Proxmox VE and Ceph require from our staff?
Operators need Linux administration, Proxmox cluster and high availability management, Ceph storage operations, and network design that includes bonded links. Ceph is deployed with cephadm, which runs the cluster as containers, so staff should understand container-based service management and how to read cluster health. The hardware guidance recommends a dedicated drive per OSD, moving WAL and DB to shared SSDs on HDD-based OSDs, and enterprise-class SSDs for metadata. Confirm which Ceph line you will run, since the releases page lists Tentacle (20.2.x) and Squid (19.2.x), with Squid's estimated end of life on October 31, 2026. Proxmox's pricing page also shows response times by subscription tier, which affects how much internal skill you need during incidents.
Does moving off Azure Local change our Windows Server guest licensing?
Windows guest licensing is governed by Microsoft's licensing terms and your existing agreements, so the answer depends on how each guest is licensed today. Moving the hypervisor does not, on its own, remove the need for Windows Server or other Microsoft licenses that run inside your virtual machines. Proxmox VE subscriptions are priced per occupied physical CPU socket per year, and the pricing page lists Community, Basic, Standard and Premium tiers, all with the same features and different support. That pricing covers the hypervisor host, not the Windows guests. Confirm each guest's license basis, including any Software Assurance or subscription coverage, with Microsoft or your licensing advisor before you change the plan.
What happens to Azure-managed features after we leave Azure Local?
Azure services that sit around Azure Local, such as cloud-based monitoring, backup, policy, update management and site recovery, do not move with the workloads. Each dependency needs an owner and a decision: replace it with a self-hosted tool, keep it in Azure for a defined period, or retire it. For example, S3-style object storage can be served by Ceph RADOS Gateway, which supports S3-compatible and Swift-compatible APIs, and VM backup can be handled by Proxmox Backup Server. Build a dependency list from your actual configurations, then test each replacement against recovery objectives before cutover. Ask any partner to show how each Azure dependency is mapped, tested and documented.
What does a fixed-scope DeployOpen engagement cover for this migration?
A fixed-scope engagement covers the work listed in a written statement of scope, with deliverables and timelines agreed before work begins. For a platform migration, that typically includes planning and design, implementation of the self-hosted platform, integration with your identity and monitoring, hardening, backup configuration, migration support and documentation. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for a deliverables list, the acceptance criteria for each one, and what is excluded, including any Azure services you keep.
How DeployOpen scopes, delivers and supports an Azure Local replacement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so an Azure Local replacement runs in your data centers or cloud accounts under your control. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory of Azure Local clusters, host hardware, network fabric and the Azure services in use
- Written list of workloads to move, including Windows guests and their Windows Server licensing position
- Agreed decisions on Proxmox VE subscription tier, Ceph layout and which Azure services are replaced or retired
How we build
- Cluster build with Proxmox VE, Ceph storage and the high availability and fencing design you approve
- Testing of node failure, live migration, backup restore and Ceph recovery before any production workload moves
- Integration with your identity provider, monitoring, backup targets and network segmentation as agreed in scope
How we hand over
- Documentation of the as-built cluster, runbooks for routine operations and recovery procedures
- Migration plan per workload, with cutover order, rollback steps and evidence of each test performed
- Knowledge transfer sessions for your platform and security staff, with access handed over to your team
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Upgrade planning for Proxmox VE and Ceph releases, scoped and documented against your environment
- Clear contact path and responsibility split agreed in writing, so your team knows who acts on each issue
