How to Migrate VMware to CloudStack with Sendense

Published Quadris customer project. Results vary with estate size, connectivity, workload dependencies and cutover requirements.

Configure Replication in Five Guided Screens

There is no separate migration toolchain to assemble. The choices that define the source, destination, transport, workload group and recovery placement live together in one Sendense replication pattern.

What You Need Before You Start

Most of the infrastructure detail is discovered and presented by Sendense. Before creating the pattern, confirm these four inputs:

• A connected VMware source site with the workloads visible in Sendense.
• A connected CloudStack destination with the intended zone, controller template, networks, compute sizing and replica disk offering available.
• A pilot workload and acceptance owner so boot, service and application checks have a clear pass decision.
• A cutover window for the final synchronization, source shutdown and production validation.

Step 1: Name the Pattern and Choose the Recovery Site

In Sendense, open Replication Patterns, select Create Pattern, give the pattern a name and choose the CloudStack recovery site. This site controls the destination infrastructure choices; the VMware source site and workloads are selected later in the Virtual Machines screen. Leave the pattern enabled for scheduled replication.

A pattern can represent a pilot, an application group, a migration wave or a complete site. Naming it around the business service or wave makes synchronization status and cutover decisions easier to coordinate.

Step 2: Choose the Synchronization Schedule

Select how often Sendense should update the target. Presets range from frequent synchronization for change-heavy workloads to longer intervals for less active systems, with one hour as the default. You can also choose how replication data is routed:

• Automatic uses a direct site-to-site path when it is reachable and otherwise routes through the Sendense hub.
• Via SHA keeps traffic on the encrypted appliance connections through the hub.
• Direct P2P uses the direct path when your network design provides one.

The interval is the target RPO for the pattern, not a promise that ignores bandwidth or workload conditions. Sendense displays the last successful synchronization and current readiness so operators can work from the actual state.

Step 3: Map the CloudStack Destination

Select the CloudStack zone and controller template, then choose the replication network, the default recovery network and the required replica disk offering. Select a service offering or set the controller compute sizing where needed. Sendense loads these as choices from the connected CloudStack environment, so operators select real destination resources instead of transcribing identifiers into a separate runbook.

Sendense uses target-side Controllers to prepare and maintain the replicas. One Controller is provisioned on demand for each selected VM after the pattern is created; the operator defines placement once in the pattern rather than building a target by hand for every synchronization.

Step 4: Select the VMware Workloads

Filter the discovered estate by VMware platform and source site, search by name, folder or resource pool, and add the required workloads to the pattern. You can select several VMs together and override the default recovery network for an individual VM when an application group spans more than one target network.

This is where a migration becomes an orchestrated workload group rather than a list of unrelated disk copies. Keep dependent VMs together, then use pattern-level synchronization and controlled parallelism during failover.

Step 5: Review and Create

The final screen brings the pattern name, site, schedule, routing, destination placement and selected VMs into one review. Each section has an edit action, so you can correct a choice without rebuilding the pattern. When everything is ready, select Create Pattern.

What Sendense Does After You Select Create

1. Establishes the full baseline

Sendense provisions the destination resources and performs the initial full synchronization for each selected VM. The VMware workload can continue running while this baseline is established.

2. Keeps the CloudStack replica current

Later full or incremental synchronization cycles update the same prepared target rather than rebuilding the migration workflow from the beginning. VMware CBT provides incremental updates where supported. This separates the time needed to move the estate from the much shorter production cutover window.

3. Shows readiness in one place

Operators can see synchronization state, last successful sync, target readiness and any workload that needs attention. A pattern-wide sync can update the selected group, while concurrency controls keep large waves orderly.

Test Before the Production Cutover

Use Test Failover to start a prepared CloudStack target without committing production to it. An optional test-network override can keep validation isolated. Check the guest boot, attached disks, network behavior, services, dependencies and user paths, then roll the test back so replication can continue.

Sendense prepares the target and exposes the recovery workflow; the application owner still makes the acceptance decision. Record that decision before the migration window rather than discovering the test plan during cutover.

Run the Final Synchronization and Control the Cutover

When the workload group is accepted and the change window opens, use a planned failover. Sendense powers down the reachable VMware source, completes a final synchronization and starts the prepared CloudStack workload. Eligible VMs can be processed with controlled parallelism.

The result waits for an operator decision:

• Commit accepts the CloudStack workload as production and closes the normal rollback path.
• Rollback reverses the uncommitted failover and returns the target to replication mode, powering the source back on where supported.

That explicit decision keeps migration authority with the change owner. Sendense automates the sequence without turning acceptance into an automatic assumption.

Keep Protecting the Workloads After They Land

Migration is not the end of the operating model. After commit, apply the required Sendense protection or new replication policy to the promoted CloudStack VM. Backup retention, recovery objectives and any onward replication remain visible on the same Sendense platform used for the move.

Sendense works with supported CloudStack environments and is not tied to a recent platform feature. That matters for providers and customers running established CloudStack releases as well as new deployments. Confirm the exact source and destination versions during the migration assessment.

A Published Complete-Estate Migration

Quadris used Sendense to begin replicating into its Apache CloudStack-based Quadris Cloud in under one hour. A complete customer VMware estate was migrated in 14 days, and the relationship continued as ongoing Backup as a Service on the same platform.

Quadris is a published example of the Sendense VMware-to-CloudStack workflow, not the limit of where it has been used. Read the full Quadris VMware-to-CloudStack customer story. Project duration varies with estate size, connectivity, application dependencies and cutover requirements.

See the Workflow Before You Plan a Pilot

Watch a VMware workload replicate and fail over to CloudStack, or review the product concepts behind replication patterns and controlled failover. Then use your own source, destination and workload group to scope a pilot.