Migrate from Hyper-V to XCP-ng: what the move involves
Moving a Hyper-V estate to XCP-ng is a per-VM conversion and rebuild project, not a single export. Each virtual machine needs its disks converted, its Hyper-V integration components removed, and its configuration recreated on the XCP-ng side, so the work scales with the number of workloads and how hard each one is to move. It is usually led by the platform or infrastructure team, which owns the host build, storage layout and networking, with an implementation partner brought in for the hard cases such as clustered workloads, databases with tight outage windows and Windows servers with unusual boot configurations.
The effort and risk concentrate in three places: disk conversion, guest driver and tool changes, and cutover sequencing. Disk conversion needs free space on the staging storage, and the naming and format rules for the converted disks decide whether the XCP-ng storage repository stays healthy, so check both before the first VM moves. Guest tools must be removed and replaced after the move, and each VM should be tested for boot, network and storage behavior before the source copy is retired. Ask any partner to show a written runbook per workload class, a rollback path for each VM and a test plan that a named owner signs off.
Hyper-V and XCP-ng can run side by side during the move. Keep the Hyper-V hosts online until every dependent service has been verified on XCP-ng, and move workloads in waves so that each wave has a clear rollback window. Xen Orchestra's V2V tool can warm-migrate some VMs from ESXi, but it does not cover Hyper-V sources, so confirm with Vates and your own tests which conversion path applies to each VM before you commit a schedule. Documented XCP-ng import paths for Hyper-V are described in the XCP-ng migration documentation, and that is the natural next read before you scope the work.
Which Hyper-V capabilities map to XCP-ng and which need rework
This table maps common Hyper-V capabilities to their closest XCP-ng and Xen Orchestra equivalents and marks each row as clean, needs rework or gap. Read the status as a planning signal: rework rows need design or conversion work before cutover, and gap rows need a decision on whether the feature is still required. Confirm every specific behavior against Vates documentation and a lab test before you commit.
| Hyper-V capability | XCP-ng and Xen Orchestra position | Status |
|---|---|---|
| VM export and import | Hyper-V exports must be converted and re-imported into XCP-ng. Xen Orchestra V2V is documented for ESXi sources, so confirm the Hyper-V path with Vates docs. | Needs rework |
| VHDX disks | VHDX files need conversion to a format XCP-ng can attach. Plan dynamic VHD output and check the disk naming rules before import. | Needs rework |
| Generation 2 VMs | Firmware and boot settings do not carry over automatically. Confirm UEFI and boot behavior for each guest in a test VM before cutover. | Needs rework |
| Checkpoints | Merge or remove checkpoints before conversion so the exported disk chain is a single consistent image. Verify each chain in a lab. | Needs rework |
| Live migration within a pool | XCP-ng pools support live migration of VMs between hosts that share storage. Confirm the storage and network prerequisites in the Vates documentation. | Clean |
| Failover clustering | Hyper-V failover clusters do not map one to one. Pool high availability and restart policies must be designed and tested as a new setup. | Needs rework |
| Replication | Hyper-V Replica settings do not transfer. Backup and replication jobs in Xen Orchestra must be defined and restore tested from scratch. | Needs rework |
| Guest integration services | Hyper-V integration services are removed during migration. Xen guest tools must be installed afterward, and Windows drivers verified for each guest. | Needs rework |
| Virtual switches | Hyper-V virtual switches are rebuilt as XCP-ng networks and VLAN bindings. Document each mapping and test traffic on every migrated VM. | Needs rework |
Why VHDX conversion and VHD naming rules matter for XCP-ng
Hyper-V disks are usually VHDX files, and the migration plan has to account for converting them before they reach XCP-ng. XCP-ng imports disks in the VHD format, so the conversion to dynamic VHD is a required step rather than an optional cleanup. Decide early whether each VM will be converted on a staging host with enough free space or on a Windows workstation that has the disk tools available. Confirm the exact supported disk formats, the conversion options and any size limits for your XCP-ng release in the XCP-ng migration documentation before you script the process for a whole estate.
Checkpoints are the step most likely to produce a disk chain that imports badly. A VM that still has Hyper-V checkpoints carries a parent and child disk structure, and converting that chain as-is can leave dependencies the target storage repository does not expect. Merge or remove checkpoints on the source VM first, then export and convert a single, flattened disk per virtual disk. Test one VM from start to finish, including boot and a file-level check, before running the same steps on the rest of the batch.
Disk space is a planning item that is easy to underestimate. During conversion you need room for the source VHDX, the converted output and any temporary files, so size the staging area against your largest VM, not the average one. Also reserve space on the target storage repository for the imported disks. Naming matters as well: the storage repository should hold files whose names follow the VHD naming rules, because files with unexpected names can be missed or flagged as unhealthy. Use simple, unique names without spaces or special characters, and check the rules in the XCP-ng documentation before renaming anything. After import, install the XCP-ng guest tools in each Windows and Linux guest so that the migrated VMs report their state and I/O correctly.
What data and integrations move, and what you rebuild
A Hyper-V to XCP-ng move carries VM disks and some configuration across, but backup jobs, monitoring hooks, automation and Windows licensing do not follow the VMs. Review each area below before you schedule cutover, so the rebuild list is agreed with the owners of each system.
VM disks and configuration
Disks are the part that moves. Export each VM from Hyper-V, then convert VHDX disks to a format XCP-ng can import, following the documented Hyper-V import path in the XCP-ng migration guide. Configuration such as vCPU count, memory, boot mode and disk order is not carried over automatically in every case, so record it from the Hyper-V VM settings before you export. Confirm each imported VM boots and gets its expected disks before you retire the source.
Checkpoints
Hyper-V checkpoints are differencing disk chains, and they must be merged before conversion or the imported disk may hold stale state. Decide which checkpoints, if any, must be kept as history and export a clean state for the cutover copy. Keep the source VMs and their checkpoints intact until the migrated copies pass testing, so a failed conversion can be repeated from the original files.
Virtual networks and VLANs
Hyper-V virtual switches do not map one to one onto XCP-ng networks. Inventory every virtual switch, its external binding, and the VLAN tags applied to each VM adapter. Recreate the matching networks in XCP-ng and Xen Orchestra, then attach each migrated VM to the correct network. Verify VLAN tagging end to end with a test VM before moving production traffic, because a wrong tag can look like an application fault.
Backup jobs and replication targets
Backup jobs, retention rules and replication targets configured in Hyper-V or a third-party backup product do not transfer into Xen Orchestra. Treat every backup and replication job as a new build: define the backup repository, schedule, retention and restore tests in Xen Orchestra, and confirm the job runs against each migrated VM. Keep the old Hyper-V backup sets readable until a restore from the new platform has been proven.
Windows guest tools and licensing
Remove Hyper-V integration services from each Windows guest before or shortly after conversion, then install the XCP-ng guest tools so drivers and shutdown handling work correctly. Windows Server licenses belong to the guest OS and the host cores, so the hypervisor change does not change them. Confirm your licensing position with Microsoft or your reseller before the move.
Monitoring, automation and identity
Monitoring agents, PowerShell scripts, SCVMM dependencies and identity bindings are outside the hypervisor move. Inventory which scripts call Hyper-V cmdlets, which monitors poll the Hyper-V host, and which services depend on Active Directory or other identity sources. Rewrite the hypervisor-facing automation against the XCP-ng or Xen Orchestra API, and keep identity changes as a separate project with their own owners.
How to sequence a Hyper-V to XCP-ng cutover
This sequence moves Hyper-V workloads to XCP-ng in controlled stages, so each workload is proven on the new platform before Hyper-V is switched off. Each step ends with a named record that the next step depends on.
Inventory VMs, disks, checkpoints and dependencies
The infrastructure lead and application owners list every VM on each Hyper-V host, including its guest OS, generation, virtual disks, attached checkpoints, network adapters, backup jobs and dependencies on other servers, such as domain controllers, databases and licensed software tied to hardware identifiers. Record which VMs are clustered or replicated and which are Windows guests needing driver changes. The output is an inventory sheet with one row per VM and an owner, a criticality rating and a target cutover window. The step is done when every owner has signed off their rows and no VM is missing from the list.
Pilot one or two non-critical VMs
Choose one or two low-risk VMs with a known owner and run them through the full path: merge or remove checkpoints, convert the VHDX disks to dynamic VHD where needed, import them with Xen Orchestra or the XCP-ng import tooling, remove Hyper-V integration components and install XCP-ng guest tools. Confirm that the VHD file names follow the naming rules that keep the storage repository healthy, and check the free space on the storage repository before each conversion. Record each command, error and workaround in a tested runbook. The step is complete when the pilot VMs boot, network and disks behave as before, and the owner confirms the application works.
Run a parallel period with Hyper-V in production
Keep Hyper-V serving production while migrated copies of selected workloads run on XCP-ng in a test network. Use this period to validate backups, monitoring, time sync, licensing checks and performance under realistic load, and to rehearse the cutover steps against the runbook. Track every deviation in an issue log and resolve it before moving production traffic. Ask your XCP-ng support provider, if you have one, to confirm the support scope for the features you plan to use. The output is a validated test report and a go or no-go decision for each workload group.
Cut over workload by workload with rollback points
Move production workloads in the order set by the inventory, starting with those that have the fewest dependencies and ending with clustered or database systems that need coordinated downtime. Before each move, take a verified backup of the Hyper-V VM and keep the source VM powered off but intact, so you can return to it. Freeze changes, run the migration, switch DNS or load balancer entries as planned and have the owner test. The output is a cutover checklist per workload, with the backup reference, the rollback decision point and the owner's sign-off recorded before the next move.
Decommission Hyper-V hosts after verified backups
Only after every workload has run stably on XCP-ng for an agreed period and its backups have been restored successfully at least once, power down the Hyper-V hosts and remove them from the network. Revoke Hyper-V management accounts and update the asset register, backup policies and monitoring targets. Confirm with your licensing and procurement teams which Windows Server and System Center entitlements are no longer in use, and document how they are retired. The output is a decommission record listing hosts, data disposition, restore test results, account revocations and the date each host was removed from service.
How the move differs by estate size and starting point
A small estate with standalone Hyper-V hosts has no shared storage or live migration to preserve, so each VM moves as a self-contained export. The work is mostly sequential: export a VM, convert its disks, import it into an XCP-ng host, then verify it before the next one. Because each VM is independent, you can schedule cutovers one at a time and keep the Hyper-V original as a rollback point until the imported copy has run cleanly.
- Export first: Export each VM with its configuration and disks, and merge checkpoints before conversion so the disk chain is a single file.
- One host at a time: Free one host, convert and import its VMs, then reuse that host for the next batch.
- Keep the source: Leave the Hyper-V VM powered off but intact until the XCP-ng copy passes your application checks.
- Plan network mapping per VM: Standalone hosts often have ad hoc virtual switches, so record each VM's network before import.
- Ask Vates about V2V scope: Confirm whether Xen Orchestra's V2V path applies to your source, since its documented source is VMware, not Hyper-V.
Check that each VM has a documented rollback step and a named owner before scheduling its cutover window.
A clustered Hyper-V estate usually runs live migration and shared storage, so the move has to respect dependencies between hosts. You cannot simply drain a host and convert everything on it at once without planning where the workloads will run during the transition. The usual approach is to build the XCP-ng pool first, move workloads in groups that match their availability needs, and retire Hyper-V hosts only after the last dependent service has left.
- Build the target pool first: Stand up the XCP-ng pool and its shared storage before moving any clustered workload.
- Group by dependency: Move tiers together, such as a database and the application servers that depend on it, to limit cross-platform traffic.
- Accept planned downtime for disk conversion: Export and conversion are offline steps for most VMs, so each cluster workload needs its own window.
- Keep quorum in mind: Shrinking the Hyper-V cluster while it still serves workloads can affect failover behavior, so confirm the plan with your cluster owner.
- Confirm cluster storage access: Cluster Shared Volumes must be read out before the Hyper-V cluster is decommissioned.
Ask your Vates partner or DeployOpen for the written cutover sequence before any clustered workload moves.
When most guests run Windows, the guest tool work dominates the post-import effort. Hyper-V integration services and their drivers are tied to the Hyper-V hardware model, and they must be removed or disabled before the disk moves cleanly to Xen. After import, the XCP-ng guest tools need to be installed so the VM has proper network, disk and shutdown behavior, and each Windows VM typically needs a reboot cycle to settle the new drivers.
- Remove Hyper-V tools first: Uninstall Hyper-V integration services from each guest before conversion, and record which guests had them.
- Check boot mode: Confirm whether each guest uses BIOS or UEFI and that the imported VM matches it.
- Plan a driver reboot: Budget a restart per guest for driver changes and test the first boot from console access.
- Install XCP-ng guest tools afterward: Install the guest tools on each VM before handing it back to its owner.
- Confirm activation: Check Windows licensing and activation status after the hardware identity changes.
Confirm the guest tool steps with your Windows administrators on a test VM before scheduling production windows.
A Linux-heavy estate usually has the smallest guest tool burden, since most distributions include the paravirtual drivers the platform needs. The effort shifts to inventory, disk formats and boot configuration, and to services that depend on fixed MAC addresses, device names or cloud-init settings. Sequencing can often follow application groups rather than Windows tool steps, which makes it easier to batch cutovers by team.
- Check kernel and initramfs: Confirm the guest boots with the drivers in its kernel, and rebuild the initramfs if a driver is missing.
- Review network names: Predictable interface names can change, so update network configuration and firewall rules.
- Update fstab entries: Replace device-specific references with UUIDs or labels so mounts survive the move.
- Batch by application owner: Group VMs by team so each owner signs off on one cutover window.
- Install guest tools where supported: Add the XCP-ng guest tools for clean shutdown and management where your distribution supports them.
Check each distribution's support status for XCP-ng with the vendor documentation before you plan the batch.
What drives cost and duration in a Hyper-V migration
This table lists the factors that change how long a Hyper-V to XCP-ng move takes and what it costs, with a way to reduce each one. The platform itself carries no license fee, so the main costs are staff time, conversion and testing, and any optional Vates support subscription, which is priced separately and is not part of the hypervisor download. Use the table to scope your own estate before asking for a written quote.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Number and size of VMs | Each disk must be exported, converted and copied, so total data volume and VM count set most of the transfer and test time. | Inventory VMs by disk size and role, and move the largest or least-used workloads in later waves. |
| Checkpoints per VM | Hyper-V checkpoints create chains of disks that must be merged before conversion, adding steps and disk space needs per VM. | Remove stale checkpoints on the source and merge chains before export, then verify each disk opens. |
| Windows guest count and tool work | Windows VMs need Hyper-V integration services removed and XCP-ng guest tools installed, and each one needs a reboot and a check of drivers and network. | Group Windows guests by build, script the tool removal, and test one image in a pilot before repeating the steps. |
| Network and VLAN complexity | Virtual switches, VLAN tags and IP settings must map onto XCP-ng networks, and mistakes can isolate workloads after cutover. | Document every virtual switch and VLAN before the move, create matching networks in XCP-ng first, and test connectivity per workload. |
| Backup and replication redesign | Hyper-V backup jobs and replicas do not carry over, so backup coverage must be rebuilt and proven before the old jobs are retired. | Confirm the backup tool and restore tests in XCP-ng on a sample VM before decommissioning Hyper-V backup jobs. |
| Staff skills | Teams used to Hyper-V Manager, PowerShell and Windows Admin Center need time to learn Xen Orchestra, XAPI and Linux-based hosts, and that learning adds to labor cost. | Plan training and shadow work early, and assign a named owner for hosts, storage and backups. |
| Downtime tolerance | Warm migration with Xen Orchestra V2V shortens the final outage, but applications with strict windows still need rehearsed cutovers and rollback plans. | Agree maximum outage per workload with the business owner, rehearse cutover on a copy, and keep the source VM until acceptance. |
| Quote items to request | Scope drives cost. Vague quotes hide conversion, testing and rollback work. | Ask for a written list of VMs, disk sizes, checkpoint counts, network changes, backup redesign, training, testing and whether a Vates support subscription is included or optional. |
Questions buyers ask before moving Hyper-V to XCP-ng
How much does moving Hyper-V VMs to XCP-ng cost?
The hypervisor itself carries no license fee, so the cost sits in labor, hardware, support and downtime. Vates describes XCP-ng and Xen Orchestra as open-source projects with no limits and no license fees, according to the Vates pricing and support page. The cost lines to separate in a quote are:
- Implementation labor for inventory, disk conversion, testing and cutover, which is one-time.
- Storage and hosts sized for the new environment, plus temporary space for conversion, which is mostly one-time.
- Optional commercial support, which recurs. Vates lists Essential at $2,000 per year for up to 3 hosts and Pro at $1,000 per host per year with a 3-host minimum.
Ask for exact figures in a written scope that states the support tier and host count separately.
How long does a Hyper-V to XCP-ng migration take?
The timeline is set by the workload more than by the hypervisor. The main drivers are the number of VMs, total disk size, how many VMs are clustered or must stay online, how much free space conversion needs, and how many guest tool installs and application tests each VM requires. Converting VHDX disks to dynamic VHD takes longer as disks grow, and conversion needs room for both source and output files, so storage capacity often becomes the constraint. Business-critical servers are usually scheduled into change windows. A pilot batch of non-critical servers typically exposes naming, disk and driver issues before production waves begin. No fixed duration applies to every estate, so ask for a schedule in the written scope that lists VM inventory, migration waves and acceptance tests.
Can our team migrate Hyper-V VMs to XCP-ng without outside help?
Yes, a team with Linux and virtualization experience can do it, since XCP-ng is GPL-2.0 licensed and its migration documentation covers imports from Hyper-V. The work still needs the same discipline as any hypervisor change: a full VM inventory with dependencies, a tested conversion of one non-critical VM, a rollback plan that keeps the Hyper-V source intact until acceptance, verified backups, and a post-cutover checklist for guest tools. Teams new to Xen often underestimate storage repository design and VLAN networking. Outside help is usually bought for scope and accountability. DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, under a fixed scope agreed in writing before work starts.
What does the migration require from our infrastructure and staff?
The work draws on four groups of skills and resources:
- Linux administration for the XCP-ng hosts, plus networking skills for VLANs and bonding.
- Storage design for repositories, and enough spare capacity to run VMs while others move.
- Windows administration for removing Hyper-V tools and installing guest tools after the move.
- Operations discipline: named owners per workload, change windows, and a backup target that has been restored in test before cutover.
Management runs through Xen Orchestra, so staff also need to be comfortable with its interface and API. Confirm the guest tool and driver steps for each Windows version in your estate before the first production wave.
Can Xen Orchestra V2V replace manual conversion from Hyper-V?
No, not for Hyper-V sources. Xen Orchestra's V2V tool, called VMware to Vates, is built for VMware. It warm-migrates VMs from ESXi 7 and later by replicating data while the source runs and then syncing changed blocks after shutdown. It reads VMFS, NFS or vSAN datastores, not VHDX files. Hyper-V moves follow the import path that XCP-ng documents, which covers converting VHDX disks to dynamic VHD, the storage repository naming rules, removing Hyper-V tools, and installing guest tools after boot. If your estate also includes VMware, V2V is relevant for those VMs. Confirm with Vates whether any Hyper-V equivalent exists before you plan cutover windows.
How do Vates support plans compare with keeping Hyper-V support?
They cover different things, so compare what each contract includes. Vates describes commercial support subscriptions as adding SLAs to the open-source projects. Its plans include Essential at $2,000 per year for up to 3 hosts, Essential+ at $4,000 per year for up to 3 hosts, Pro at $1,000 per host per year with a 3-host minimum, and Enterprise at $1,800 per host per year with a 4-host minimum and 24/7 support, according to its pricing page. Hyper-V support depends on the Windows Server licenses and Microsoft agreement you hold, which your licensing advisor or Microsoft account team should confirm. Compare annual cost at your host count, the response terms in each SLA, and the Windows Server licenses still needed for Windows guests after the move.
What usually goes wrong and how to prevent it
Most failed Hyper-V to XCP-ng moves are not caused by the hypervisor itself. They come from disk chains, file names, capacity, guest drivers, networking and untested recovery paths that were never checked before the source hosts were switched off. Each card below names one of these failure points and the check that prevents it.
Unmerged checkpoints break disk chains
A VM exported with checkpoints carries a chain of differencing disks, and a missing or reordered parent breaks the import. Before exporting, merge or delete every checkpoint so each VM ends with a single base disk. Then confirm the disk count in the Hyper-V VM settings matches what you expect to import. Do this on a copy of the VM first, so the production chain is never altered.
VHD names that break the repository
XCP-ng storage repositories expect disk files to follow a naming pattern they can index, and files with unexpected names or leftover Hyper-V extensions can be skipped or flagged as unhealthy. Rename converted files to plain VHD names with no spaces or special characters before placing them in the storage repository. Rescan the repository after each copy and confirm every disk appears with the expected size.
Insufficient disk space during conversion
Converting VHDX to dynamic VHD needs room for the source disk, the converted output and the copy into the target repository, so a single VM can need more free space than its final footprint. Calculate the space for the largest VM plus its converted copy before starting, and keep a margin on the staging volume. Ask your storage team to confirm free capacity on both the Hyper-V host and the XCP-ng repository.
Windows guests missing tools after import
Windows guests moved from Hyper-V still carry Hyper-V integration services and may lack the paravirtual drivers XCP-ng expects. Remove the Hyper-V integration components and install the XCP-ng guest tools before the first production boot, so storage and network devices come up cleanly. Test one Windows server end to end, including reboot and network reachability, before moving the rest of the batch.
Network mismatches after cutover
Virtual switch names on Hyper-V do not map to XCP-ng networks automatically, so a VM can boot with no connectivity or land on the wrong VLAN. Build the XCP-ng network objects and VLAN tags first, then record the IP, gateway and DNS settings for each VM. Verify each VM can reach its dependencies from the new network before the old VM is powered down.
Backups not tested before decommission
Teams often decommission Hyper-V hosts once imported VMs boot, and discover later that the backup chain cannot restore. Restore at least one VM from the new backup job to a separate network and confirm it boots and passes an application check. Keep the Hyper-V source and its last good backup until that restore has been proven and signed off by the workload owner.
Primary sources for the XCP-ng migration
Start with the XCP-ng migration documentation before you touch a production VM, because it is the vendor-maintained reference for the import paths that apply to Hyper-V. It documents imports from Hyper-V, KVM and VirtualBox alongside the XenServer and Citrix Hypervisor upgrade paths, so you can confirm which route matches your source hosts and guest operating systems. Read it alongside your own inventory of Hyper-V configuration versions, disk formats and checkpoints, and check each item against the page before you schedule a change window. The Migrate to XCP-ng guide is the natural first read.
The XCP-ng documentation hub holds the install guides, release notes and administration references you will need after the import, including the guest tools and storage repository material that the conversion steps depend on. Check the release notes for the support window of the branch you plan to deploy. The current long-term support branch, 8.3 LTS, was released on October 7, 2024 and is supported until November 30, 2028, while 8.2 LTS support ended September 16, 2025. Plan on the newer branch so the migration does not begin on a release that is already leaving support. For support plan details, read the Vates pricing and support page. The hypervisor and Xen Orchestra are described there as open source with no license fees, and commercial subscriptions add SLAs. Ask Vates or your implementation partner which support tier covers the hosts, whether the price is per host, and whether the quote includes migration assistance. Confirm current prices directly with Vates, since the pricing page is the authoritative source for them.
How DeployOpen scopes, runs and supports your Hyper-V migration
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Hyper-V to XCP-ng, we agree the written scope first, then convert and test each workload in your environment and hand over the platform with its documentation.
How we scope
- We inventory Hyper-V hosts, VM generations, VHDX disks, checkpoints and the Windows and Linux guests that must move.
- We agree in writing which VMs move, in what order, and which conversion path each one uses.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any work starts.
How we build
- We install and configure the XCP-ng hosts, pools, networks and storage repositories in your own accounts or data centers.
- We convert disks from VHDX to dynamic VHD, checking VHD naming rules and free disk space before each conversion.
- We install XCP-ng guest tools on migrated VMs and test boot, networking and application behavior before cutover.
How we hand over
- We deliver runbooks for each conversion step, storage repository layout, network mapping and rollback steps.
- We document the migrated VM inventory, the guest tools state per VM and the backup configuration in Xen Orchestra.
- We walk your operations team through day-two tasks so they can run the platform after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can plan XCP-ng patch and upgrade windows, including the 8.3 LTS support timeline, into your change calendar.
- Confirm with us during scoping which support level, response times and SLAs your team needs, since these are set in the written scope.
