Veloce
Migration. Under control.
Veloce is an agentless, any-to-any migration orchestration platform. It moves virtual machines and containerised applications between hypervisors and clusters — and, just as importantly, it governs that movement: who approved it, what was checked beforehand, who was told, and what happens if it goes wrong.
Most migration tools move a workload. Veloce runs the programme around it.
The copy is the easy part — vendor tools already move disks well. The hard part is sequencing hundreds of workloads, proving readiness, keeping owners informed, and being able to reverse a bad cutover at 2am.
- Approach
- Agentless — nothing installed inside guest workloads
- Scope
- Virtual machines and Kubernetes applications
- Engines
- Nutanix Move, Red Hat MTV, SUSE Harvester, Velero — pluggable
- Unit of work
- The wave: a governed group of workloads moving together
- Lifecycle
- Compose → Associate → Seed → Cutover → Validate → Archive
- Governance
- Approvals, separation of duties, hash-chained audit, ITSM integration
- Deployment
- Self-contained appliance; runs fully air-gapped
Large migrations fail for organisational reasons far more often than technical ones.
The disk copy usually works. What breaks is everything around it.
- What goes wrong
Unknown dependencies
A workload is moved and something nobody documented stops working — a database it called, a licence server, an Active Directory domain controller.
Agentless dependency discovery — including dependencies on things that are not migrating. - What goes wrong
Wrong sequencing
An application server is migrated before the database it depends on.
Waves with explicit sequence, and cross-wave dependency flagging. - What goes wrong
Nobody was told
The application owner discovers the migration when their users call.
Recipient-aware notifications with real delivery receipts. - What goes wrong
Readiness was assumed
A VM had a mounted ISO, a snapshot, or Change Block Tracking disabled — and the replication failed hours in.
Automated assessment with one-click remediation runbooks. - What goes wrong
No way back
The cutover went badly and there is no rehearsed, governed rollback.
First-class rollback, exercised as a normal operation. - What goes wrong
No evidence
An auditor asks who approved a change and there is no reliable answer.
Tamper-evident, hash-chained audit log with independent verification.
Six stages, and a wave cannot skip the gates between them.
A wave is a group of workloads that move together, with a shared plan, owner and schedule. It is the central object in Veloce — everything else attaches to it. Seeding is non-disruptive; only cutover involves downtime, and it is gated by approval.
Compose
Select workloads and set wave parameters — decide what moves together.
Associate
Bind source, target, engine, credentials and runbooks — wire up the how.
Seed
Replicate data to the target while the source stays live. Copy, with no outage.
Cutover
Power off source, bring the workload up on the target. The switch.
Validate
Run checks and capture sign-off. Prove it works.
Archive
Apply the retention policy to the source. Tidy up, reversibly.
Compose
Select workloads and set wave parameters — decide what moves together.
Associate
Bind source, target, engine, credentials and runbooks — wire up the how.
Seed
Replicate data to the target while the source stays live. Copy, with no outage.
Cutover
Power off source, bring the workload up on the target. The switch.
Validate
Run checks and capture sign-off. Prove it works.
Archive
Apply the retention policy to the source. Tidy up, reversibly.
Six things that decide whether a migration lands.
Discover before you move
A live inventory across heterogeneous environments.
- Workload configuration and utilization
- Workloads grouped into business applications
- Owners, environments, business criticality
- Direction-aware dependency edges, with provenance and decaying confidence
Find risks before cutover
Assess readiness before a workload enters a wave.
- Findings graded blocker, warning or informational
- Most findings carry a remediation runbook that fixes them in place
- Bulk remediation — fix one finding across many workloads at once
- Automatic re-assessment, so you watch a workload move to supported
Plan application-aware waves
Move connected business services, not isolated VMs.
- Group workloads by application, business unit, risk or maintenance window
- Keep dependent workloads together; flag cross-wave dependencies
- External dependencies kept — DNS, AD, NTP and SaaS do not move with the wave
- Each wave carries its own owner, stakeholders, source, target and engine
Automate beyond conversion
Runbooks automate far more than the migration itself.
- Agentless platform operations, and in-guest scripts via guest operations
- Stage-bound — pre-seed, pre-cutover, post-migration validation
- Target-aware — a Kubernetes runbook is never offered to a VM wave
- Blocking gates — a failed pre-seed runbook stops the wave
- Per-VM evidence, with the exact error and exit code
Control execution
One Run Center for every wave and engine action.
- Per-workload progress with a streaming, filterable event log
- Restart-safe — long operations survive a platform restart
- Approval gates, maintenance windows and change freezes
- Rollback is first-class: source reinstated, target cleaned up, per workload
Right-size on evidence
Migration is the one moment when resizing a workload is nearly free.
- P95 governs shrinking, P99 governs growth — asymmetric on purpose
- Memory treated more conservatively than CPU
- Thin data reports “insufficient data” rather than guessing
- Every recommendation carries its sample count and confidence
- Applied when the target is built — the source is never touched
Veloce orchestrates your converters. It does not replace them.
Different platform pairs need different migration technology. Veloce treats each as a plug-in and picks the right one automatically — selecting a target implies its engine, which removes a whole class of misconfiguration.
- Waves
- Assessment
- Approvals
- Notification
- Audit
- Rollback
One plug-in contract — seed, poll progress, cut over, abort, tear down. Organisations learn one process, not four.
- Nutanix AHVNutanix MoveExternal appliance
- SUSE Harvestervm-import-controllerOn the target cluster
- OpenShift VirtualizationRed Hat MTVOn the target cluster
- Kubernetes · OpenShift · NKPVeleroOn the target cluster
Source, target, and the engine each target implies.
Almost nobody is moving from exactly one platform to exactly one other. Support is deliberately asymmetric, so it is stated as a matrix rather than a wall of logos.
| Platform | Source | Target | Engine | Notes |
|---|---|---|---|---|
| VMware vCenter | — | Primary VM source; full agentless operations | ||
| Nutanix AHV | Nutanix Move | External appliance | ||
| SUSE Harvester | vm-import-controller | Native; runs on the target cluster | ||
| OpenShift Virtualization | Red Hat MTV (Forklift) | Runs on the target cluster | ||
| OpenShift (RHOCP) | Velero | Container applications | ||
| Kubernetes (upstream) | Velero | Container applications | ||
| Nutanix Kubernetes Platform | Velero | Container applications |
Nothing is installed inside the workloads it migrates.
Veloce asks the platform that hosts them — the hypervisor or the cluster — to do the work on its behalf.
- Platform operations run through the management API — vCenter, Prism, the Kubernetes API
- In-guest actions use the hypervisor’s guest operations channel; no network path to the workload is required
- Dependency discovery reads the socket table over an authenticated session, then disconnects
- No agent to deploy, patch, secure or remove — and nothing left behind on a migrated workload
A cutover physically cannot proceed without passing the gates.
Approvals, separation of duties, change records, maintenance windows and the audit chain are part of the execution path, not a layer on top of it. The person who executes a cutover cannot be the person who approved it — checked server-side, so the API refuses the action.
| Role | Intended for | Can do |
|---|---|---|
| Viewer | Stakeholders | Read everything |
| Auditor | Compliance | Read everything, including audit |
| Operator | Migration engineers | Run seeds, cutovers and runbooks |
| Approver | Change advisory | Approve or reject gates |
| Architect | Migration architects | Design waves, connections, runbooks |
| Tenant Admin | Business-unit admins | Administer within one tenant |
| Admin | Platform owners | Full control, including users and retention |
Every wave, one governed source of truth.
- Wave 01 — Finance ERP14 workloadsArchivecomplete
- Wave 02 — Core banking22 workloadsValidatecomplete
- Wave 03 — Customer portal9 workloadsCutoverawaiting approval
- Wave 04 — Data platform31 workloadsSeedrunning
- Wave 05 — Internal tools17 workloadsAssociatepending
- Wave 06 — Analytics namespaces6 workloadsComposepending
Wave names and counts are illustrative. The six stages, the approval gate at cutover and the separation-of-duties rule are the product’s actual behaviour.
The channels your teams already watch — with real receipts.
Every lifecycle event notifies the owner and named stakeholders of that wave, not a global broadcast. Delivery state is persisted rather than fire-and-forget, so the platform can answer why somebody did not get a message — and retry everything that failed once a relay is fixed.
- In-app
- Microsoft Teams
- ServiceNow
Evidence over assertion.
Reversibility as a property.
The platform does not claim things it has not checked. The audit chain is verified on demand and reported with a record count. A right-sizing recommendation shows its sample count and withholds itself when the data is thin. A connection’s health is shown with its age, because a green badge from three weeks ago is a cached verdict, not a current one.
- Audit chain verified, not asserted
- Right-sizing shows its sample count
- Notifications show per-recipient receipts
- Connection health shown with its age
- Seeding never touches the source
- Rollback is exercised, not documented
- Sizing stays changeable until the target is built
- Archive is retention-based, not destruction
Validated against a mixed estate, not a simulation.
- 139
- discovered workloads
- 11
- platform connections
- 38
- runbooks
- 8,000+
- audit events
97 virtual machines · 42 Kubernetes namespaces
vCenter, AHV, Harvester, OpenShift, NKP
Bound to pre-seed, pre-cutover and validation stages
Chain independently verified across full history
- End-to-end virtual machine migrations executed, including cutover, validation and rollback
- End-to-end Kubernetes application migration between clusters — with the application confirmed back online on the source after rollback
- Notification delivery proven across in-app, email and Microsoft Teams, with real receipts
- ServiceNow change request and incident creation exercised as part of a live wave
- Audit chain independently verified across the full event history
Figures describe avancerPI’s reference environment — a live mixed estate spanning VMware vCenter, Nutanix AHV, SUSE Harvester, OpenShift and Nutanix Kubernetes Platform — at the time the briefing was written. They are not customer results.
Built for the teams accountable for the cutover.
Migration engineers
One process to learn, whatever the source and target platforms are.
Migration program managers
Wave sequencing that reflects real dependencies, not guesswork.
Application owners
To hear about the migration before their users do — and to see the receipt.
Change advisory & risk
Approval gates, separation of duties, and a change freeze that actually blocks.
Auditors & compliance
A hash chain they can independently verify, with a record count and head hash.
Security teams
An air-gapped appliance, no agents in the guest, and every secret read audited.
Veloce Replication Agent
In engineering and testing; not generally available. A guest-resident, userspace-only replication engine that would give Veloce its own data plane — no kernel driver, no VDDK dependency, allocated and changed-block copy, resumable encrypted streaming, and interchangeable source readers and target writers behind a stable plug-in interface. It is a deliberate exception to the agentless architecture described above, and would be opt-in per estate. Architecture, functionality and availability may change; it is not production-ready or contractually committed.
Take control of your next migration.
Bring us your estate and your next migration wave — we'll show you what Veloce actually surfaces.