Platform Transition
Plan protection and recovery across current and future platforms while workloads move in controlled stages.
Review workload mobilityFor Infrastructure Teams
Protect today's infrastructure without locking tomorrow's recovery to it.
Protect mixed or changing VM estates with backup, recovery, replication and migration paths that remain useful as platforms, storage and recovery destinations change.
Sendense runs within the architecture you operate, keeping repository, recovery and transition decisions under your control.
What are you changing?
Start with the infrastructure decision or recovery risk that brought you here.
Showing Disaster Recovery
Backup Modernisation
Replace fragmented or incumbent protection architecture with a model aligned to the estate, repositories and recovery paths you operate.
Review backup and recovery
Disaster Recovery
Design replication, recovery testing and controlled failover around the applications and dependencies that matter.
Review disaster recovery
Recovery Validation
Add integrity, mount and boot-validation evidence to supported recovery workflows.
Review recovery validation
VMware Exit
Move workloads from VMware to supported destinations with continuous sync, test cutover, rollback and commit.
Review VMware exit
What do you need to evaluate?
Work through the estate, architecture, recovery, security and leadership questions that shape an Infrastructure Team evaluation.
Start with the estate you actually operate.
This is a planning checklist, not an automated or exhaustive compatibility checker. Compatibility is path-specific. Confirm the platforms, hypervisors, storage paths and recovery destinations in scope before treating a workflow as supported.
| Dimension | Qualification question |
|---|---|
| source platform | Which platforms and versions are in the current estate? |
| hypervisor and version | Which hypervisor and version does each protected workload use? |
| primary storage path | Which primary storage path does each workload use, especially on CloudStack? |
| repository | Where will recovery points be held, and who operates that repository? |
| protected workload type | Are the workloads VMs on a supported platform, or a supported physical Windows path? |
| recovery destination | Is recovery back to the same platform, another site, or a different supported destination? |
| backup / DR / migration requirement | Is the first proof backup, replication/DR, recovery validation or a controlled migration? |
| network and connectivity | Which control and data paths are available between the appliance, nodes and the estate? |
| operational ownership | Who will own protection jobs, recovery tests and day-to-day operations after evaluation? |
Design protection for the architecture you are moving towards.
Map the current source estate against the future platform direction, then place backup, repositories, recovery targets and migration paths on that design. Backup, replication/DR, migration and recovery validation are related workflows with different product surfaces. Do not treat one workflow as covering every use case.
Current source estate
Record the platforms, hypervisors and storage paths that already hold production workloads.
Future platform direction
Name the destinations protection and recovery must still work on after a platform change.
Backup and repository placement
Decide where recovery points are stored and who operates that repository.
Recovery targets
Separate same-platform restore from recovery onto another supported destination.
Replication paths
Replication and DR use their own patterns, targets and test or failover jobs.
Migration paths
Workload mobility and VMware-exit paths move protected VMs between supported platforms.
Control and data paths
Keep appliance, node and platform connectivity explicit. Credentials are forwarded to a node only for the duration of a request.
Network dependencies
The node must reach the source platform on the network for platform work to succeed.
Storage dependencies
CloudStack support is path-specific. Confirm the primary-storage path before treating a workload as protected.
Monitoring and operational ownership
Decide who inspects jobs, recovery evidence and day-to-day protection after the evaluation.
Backup
Protection patterns write recovery points into the repository you operate.
Replication / DR
Replication patterns, test recovery and controlled failover are a separate operating path.
Migration
Workload mobility and documented VMware-exit paths move VMs between supported destinations.
Recovery validation
Integrity, mount and boot evidence can be collected on supported recovery workflows. That evidence is not complete recovery proof.
Build recovery around application dependencies, not a universal number.
Recovery requirements differ by workload. RPO and RTO are design inputs for the applications and dependencies you name, not a published Sendense-wide figure.
Requirements differ by workload
Each application set can need a different recovery order, destination and evidence standard.
RPO and RTO are design inputs
Use the recovery point and time objectives the organisation needs. This route does not publish one RPO, RTO or failover time.
Sequence and dependencies
Plan recovery order around the services that must return first, not around a single platform-wide promise.
Test recovery in the operating model
Test recovery belongs in the operating model so failover is exercised before an incident.
Inspect evidence before wider rollout
Read the recovery, test or validation evidence the chosen workflow can produce before expanding the estate.
Related but different workflows
Replication, backup and migration share the platform but remain different jobs with different success criteria.
Review the controls around credentials, repositories and recovery.
Review the documented credential, access, repository, retention, audit and recovery-evidence controls. This page does not claim certification or independent assurance.
Credential handling
Platform, storage, identity and notification credentials are stored in the appliance credential vault, encrypted at rest, and never displayed back after saving.
Users, roles and sign-in
SHA accounts, roles and permissions remain an appliance concern. Users sign in with an email address and password. The documented GUI sign-in path does not add a second factor.
Site and platform permissions
Every vault credential has a scope that decides which node uses it. Platform credentials are forwarded to that node only for the duration of a request and are not stored there.
Repository and retention controls
Recovery points are held in the repository you operate. Retention and immutability controls exist on the product and must be scoped to the estate.
Deletion controls
Deletion and cleanup of recovery points are explicit product operations, not an implied background wipe of every copy.
Audit records
Credential-vault actions are audited. Failover and cutover jobs write a journal that operators can inspect for those workflows.
Recovery validation evidence
Integrity, mount and boot evidence can be collected on supported recovery workflows. Validation evidence shows a recovery point can be used. It is not complete recovery proof and no independent assessment is published here.
Network dependencies
The node must reach the source platform on the network. Scope and connectivity are part of the security and operating design, not a hidden assumption.
Supplier and security documentation
Inspect the published security architecture and product documentation. No certification or independent assurance claim is made on this route.
Make protection support the infrastructure strategy.
Treat backup, recovery and migration as part of the platform decision, not as a tool to attach after the estate has already moved.
Outage and recovery risk
Name the applications that cannot wait for an untested restore, and the evidence an evaluation must produce before those systems are trusted to the new design.
Strategic platform direction
Protection has to remain useful on the platforms the organisation will operate next, not only on the hypervisor in place today.
Supplier concentration
Decide whether recovery, repositories and transition tooling should stay under the same operator that runs the estate.
Operational workload
Account for who will run protection jobs, inspect recovery evidence and own incidents after go-live.
Implementation ownership
An evaluation proves a representative path. Wider rollout still needs named owners for deployment, connectivity and handoff.
Support and escalation
Confirm the support boundary for the estate before treating a successful evaluation as a production operating model.
Licensing route
Infrastructure licensing is the public commercial route for organisations that licence Sendense to protect their own estate. Granular list prices are not published as the purchasing journey.
Evidence required for procurement
Use architecture, compatibility, security documentation and named customer stories. This route publishes no commercial return figures.
Prove the design with representative workloads.
An evaluation is a planned proof of a named path. It is not a completion-time promise and it does not guarantee that every environment or enterprise requirement is covered.
Stage 1
Inventory the source environment and storage paths
Record platforms, hypervisors, storage paths and the operators who will run the proof.
Stage 2
Select representative workloads and dependencies
Choose workloads that exercise the intended storage path, recovery target and application dependencies.
Stage 3
Define backup, recovery, DR or migration success criteria
Agree the exact workflow under test before the run. Do not collapse backup, DR and migration into one success line.
Stage 4
Confirm topology, repository and connectivity
Confirm appliance placement, repository ownership and the control and data paths the chosen workflow needs.
Stage 5
Run the supported workflow
Run the backup, replication, validation or migration path that the estate and product surfaces actually support.
Stage 6
Inspect recovery, operational and validation evidence
Read the jobs, recovery points and validation evidence the chosen path can produce.
Stage 7
Review ownership, support and licensing before wider rollout
Scope Infrastructure licensing after the estate, operating model and proof are understood.
Success criteria
- environment compatibility
- deployment ownership
- connectivity
- protection or initial sync
- incremental operation where supported
- recovery or test workflow
- recovery evidence
- operator handoff
- support boundary
- commercial fit
Essentials is an evaluation route for trying Sendense in a real environment. It is not a guarantee that every environment or enterprise requirement is covered, and it is not the default CSP, migration or enterprise purchasing route.
Inspect the architecture before committing to it.
Inspect the architecture, compatibility, security, recovery and documentation before committing to a wider rollout. Quadris is a named VMware-to-CloudStack migration project. It is not universal proof of infrastructure transition outcomes.
Bring the current estate and the architecture you need next.
We will map the platforms, storage paths, repositories, recovery targets and operating responsibilities into an evaluation plan.
Infrastructure Team FAQs
Which organisations is this route for?
This route is for infrastructure teams that licence and operate Sendense to protect their own VM estates. Cloud Service Provider and MSP reseller models are separate commercial routes.
Which environment details should we bring to an architecture session?
Bring the source platforms and versions, hypervisors, primary storage paths, repository ownership, intended recovery destinations, whether the proof is backup, DR, validation or migration, network paths, and who will own operations after the evaluation.
Can Sendense protect a mixed or changing estate?
Sendense protects VMware, Nutanix AHV, CloudStack, OSSEA, Azure and supported physical Windows environments through documented platform integrations. Support is path-specific. Confirm the hypervisor, storage path and recovery destination before treating a workload as in scope.
How are backup, replication, recovery and migration different?
Backup writes recovery points into the repository you operate. Replication and DR use separate patterns, test recovery and failover jobs. Recovery validation adds integrity, mount and boot evidence on supported workflows. Migration and VMware-exit paths move protected VMs between supported destinations. One workflow does not stand in for the others.
How should we evaluate RPO and RTO?
Treat RPO and RTO as design inputs for named applications and dependencies. This route does not publish a universal recovery-point, recovery-time or failover-time figure.
What does an initial evaluation need to prove?
It needs to prove environment compatibility, deployment ownership, connectivity, protection or initial sync, incremental operation where supported, the chosen recovery or test workflow, recoverable evidence, operator handoff, the support boundary and commercial fit. It does not promise a completion time.
How does Essentials fit an Infrastructure Team evaluation?
Essentials is an evaluation route for trying Sendense in a real environment. It is not a guarantee that every environment or enterprise requirement is covered, and it is not the default CSP, migration or enterprise purchasing route.