Disaster recovery as a service (DRaaS) gives you a provider's recovery infrastructure and tools to run workloads after a failure. The work included varies. Your team may still have to declare the incident, restore dependencies, change traffic routing and prove that the application works.
Evaluate the service with one application and a written acceptance test. A successful VM boot is only one step in that test. The useful result is a working application with an acceptable recovery time and verified data.
Define the service you are buying
DRaaS does not specify one replication method. Veeam Cloud Connect Replication, for example, provides offsite VM replicas on a service provider's infrastructure. Its documentation distinguishes snapshot-based replication from optional continuous data protection. It also assigns replication and failover operations to the tenant. A provider may sell additional management, but establish that scope before buying.
AWS Elastic Disaster Recovery replicates supported source servers into a staging area in your AWS account. Recovery launches instances from that data. AWS requires a replication agent on each source server; its staging area also uses replication servers. A service being cloud-based tells you little about which agents or appliances it needs.
Ask the provider to describe the exact protection path for your workload. Record the replication method, recovery-point retention, target platform and components your staff must maintain. Keep managed databases, object stores and other services outside the replicated VM on the inventory until each has a verified recovery path.
Recovery targets alone do not select a product. Use the business requirements in the RTO and RPO worksheet, then test whether the proposed service can meet them for the whole application. A short RTO does not automatically require a product sold as DRaaS.
Put the handoffs in writing
Request a responsibility record for the evaluation. Name the team doing each task, the person allowed to approve it and the evidence needed to proceed. Fill gaps before the drill; do not leave a task assigned to "customer/provider."
The table below is a worksheet for that conversation, not a description of any vendor's included service.
| Task | Record before testing |
|---|---|
| Declare recovery | Who can approve it, and how to reach their backup |
| Prepare the target | Who owns quotas, capacity, licenses and network setup |
| Select data | Who chooses the recovery point and checks its contents |
| Stop old writes | Who isolates the old writer before the new one accepts writes |
| Open traffic | Who changes routing and checks access from user networks |
| Accept recovery | Which app owner verifies work and records remaining faults |
| Return service | Who copies new data back and restores protection afterward |
For each service commitment, ask what starts the clock and what stops it. Provider response, infrastructure availability and application recovery measure different events. Record dependencies and exclusions, including access to your own staff. Keep the application's elapsed recovery time alongside any provider-specific measurement.
Test access to the recovery console without relying on the failed site's identity server or VPN. Check that the recovery team can retrieve its runbook and credentials through the approved emergency access process. A plan that requires an unavailable administrator cannot reach its first operational step.
Check support and dependencies before copying data
Start with the vendor's matrix for the exact source and destination. Microsoft's VMware and physical-server support matrix separates operating-system, disk and network restrictions. Record the running OS and kernel, boot mode, disk layout and protection software version. Check the intended return path too; support for replication to a target does not establish support for every failback arrangement.
Then trace one business operation through its dependencies. For an order system, that could include sign-in, database writes, uploaded files, background jobs and an external payment service. This is an illustrative example; use your application's own operation and success criteria.
For each dependency, record whether the drill will restore it, reach a surviving service or use a test substitute. Verify certificates, secrets and destination allowlists. Include the load balancer and DNS records in the recovery plan. AWS's DRS network preparation guide treats the staging area and operational recovery subnets separately. Receiving replication traffic does not establish that users can reach the recovered application.
Azure recovery plans can group machines, sequence their startup and insert scripts or manual actions. Use application readiness checks between dependent steps. A database process starting does not prove that the application can authenticate or read the required data.
Run an isolated acceptance test
Agree on the scope, operators and stop conditions with the provider. Start with a scheduled drill. An unannounced exercise introduces staffing and coordination risks that a first technical evaluation does not need.
Choose a separate test network and verify its routes before starting replicas. Block production writes and replace outbound email, payment calls and webhooks with test destinations. If a replica can reach a live dependency, document why that access is safe. Stop the drill if the test escapes that boundary.
Microsoft's test-failover guidance recommends an isolated network and warns about duplicate machine identities when testing in the production recovery network. It also explains that cleanup discards changes made to the test VMs. Save test evidence before cleanup.
Run the application checks in the table below. These are proposed acceptance criteria, not measured results or vendor guarantees. Add your target values and expected records before the exercise.
| Check | Evidence to save |
|---|---|
| Recovery access | Operator can start the plan without the simulated failed dependency |
| Data recovery | Chosen point, recovered records, missing writes and consistency checks |
| User operation | Test sign-in and a complete read/write operation through the intended route |
| Capacity | Error rate, latency and job backlog at the agreed test load |
| Isolation | Evidence that test systems cannot write to production or send live messages |
| Cleanup | Test resources removed and ongoing protection still healthy |
Measure from the agreed simulated disruption to the point where the required operation works. Keep timestamps for detection, approval and the recovery steps so a slow handoff remains visible. An isolated drill that omits public traffic cutover should record that omission; it has not measured the full user recovery path.
Check data contents as well as the recovery-point timestamp. Confirm that related records agree and identify acknowledged writes that are missing. Azure exposes different recovery-point choices, including processed and application-consistent points. Choosing a point involves freshness and consistency requirements; a "latest" label alone does not prove the application's data-loss target was met.
Record a failed criterion as a failure, with an owner and a retest. Use the recovery game-day guide to turn the accepted procedure into a repeatable exercise after the evaluation.
Keep a path back to clean data
A site outage and corrupted data need different recovery decisions. Replication can carry unwanted changes to the destination. The AWS recovery strategy guide calls out corruption and malicious deletion as reasons to retain recovery history alongside replication.
Ask how long older points remain available, who can delete them and how you recover if production credentials are compromised. Require a restore demonstration using an older point. Inspect the restored application before reconnecting it to live systems.
If a provider offers immutable storage, get the mechanism and permission model. S3 Object Lock, for example, protects object versions from overwrite or deletion under configured retention rules. It does not inspect the application for corruption or prove that a stored recovery point will boot. Keep those as separate tests.
Price the return trip and rehearse it
Ask for costs in three operating states: normal replication, a drill, and an extended recovery. Include storage history, active compute, network transfer, licenses and operator time. The AWS DRS pricing page separates the service charge from the storage and compute consumed during replication and recovery. A monthly service fee alone is an incomplete estimate.
Require the provider to explain capacity allocation during a wider outage, including any reservation options and limits. A launch configuration and an approved quota are useful prerequisites; the evaluation should also demonstrate the capacity your application needs.
Once the recovery site accepts new writes, it holds data that the old site may lack. Failback must carry those changes back before traffic returns. Microsoft's modernized Site Recovery workflow separates reprotection, failback and re-enabling protection after the return.
Test that return path with disposable data. Confirm the destination is ready, synchronize the new writes and enforce a single active writer during cutover. Afterward, verify application work and check that replication and backups protect the active site again. Keep the final acceptance record with the runbook: supported workload versions, measured results, unresolved gaps and the date each gap will be retested.