Enter every workload as it exists today, regardless of what will happen to it during the engagement. This includes workloads already protected by Veeam, and VMs that will be migrated to a different hypervisor — add those in their current source form (e.g. as VMware VMs, not as the target platform). The tool uses this as the baseline to calculate effort across the whole project.
If a workload type is only partially covered — some VMs already have a Veeam job, others don't — choose the approach that matches what PS will actually do:
Two chips — one with a job (protected), one without. Use this when the unprotected VMs need different protection configuration from the existing job (different schedule, retention, or protection type), or when PS will build a brand-new job for them.
One chip, total qty, job covering the subset — use this when the additional VMs need to be added to the same existing job with no policy changes. In Step 2, tick Scope Expansion on that job row and set the target count. The estimate will reflect the lower effort of extending an existing job rather than creating a new one.
ⓘ Use the quantity stepper on each chip to match the real environment. Sites that are future-state only (added from Step 2) do not appear here and do not require workloads.
Define the engagement model (Resident Enterprise Architect or Standard Professional Services) and configure what the future state looks like. Two sections that often cause confusion:
Add a VBR server for each backup server that will be deployed or configured during the engagement, then drag workloads from the tray onto the correct VBR lane to assign them. New VBR servers default to Virtual + Linux VSA — adjust the deployment type and platform in the settings that appear when you add the server, then click anywhere outside to collapse. If the VBR will be deployed to a location not in Step 1 (a future-state site, e.g. a new cloud region), use + New site in the site picker to create it — it won't affect Step 1 or block validation, and you can rename it directly on the lane card.
This section becomes available when hypervisor workloads are present in Step 1. Use it to define where those workloads are migrating to (e.g. VMware → Hyper-V). The effort for the migration is calculated from what you entered in Step 1 combined with the target you set here.
In the Workload Services matrix, job rows under an existing VBR or VB365 server show a Scope Expansion column when the job covers fewer workloads than the total pool defined in Step 1. Tick the checkbox to flag that PS will add workloads to that job, then adjust the target count in the field that appears. The estimate adds effort for auditing, re-scoping, and validating the updated job — lower than a full new-deployment because the job, policy, and infrastructure already exist.
Enter the access password to view the effort breakdown by phase. The estimate is read-only — all changes are made in Steps 1 and 2.