CloudRebuild restores a workload backed up in one cloud into a different cloud — Azure to AWS, GCP to OCI, or any supported pair. Translation happens through a canonical resource envelope, and every restore is preceded by a typed compatibility report the operator reviews before anything executes.
How cross-cloud restore works
1. Capture
Every resource is stored in a canonical envelope as {common.*, provider.azure.*}. Provider-specific data lives alongside normalised fields — size class, region, encryption state, public exposure. That envelope is the input to translation.
2. Translate
A pairwise translator for the (source, target) combination reads the common fields plus the source provider’s attributes, then applies curated mapping tables for instance sizing, machine images and regions. The output is target-shaped configuration. No live API calls are made during translation, so translation is deterministic and works even when the source cloud is unreachable.
3. Compatibility report
Before execution, CloudRebuild produces a typed report with findings at three levels:
- Per-resource — size equivalence, image mapping, known gaps.
- Graph — dependency edges with no equivalent on the target.
- Policy — retention differences between source and target.
Each finding carries a severity: clean, warning, degraded or failed. The operator sees all of it before approving the restore. Nothing executes on a surprise.
Pairwise translation, not hub-and-spoke
Each provider pair has its own translator package with its own mapping tables, rather than routing everything through a shared intermediate format. That has three consequences worth knowing:
- Extensibility. Adding a provider means adding new pair packages. Existing pairs stay untouched, so there is no translation regression risk when a fifth cloud is added.
- Versioned mapping tables. Tables are pair-local and versioned. A table refresh bumps the per-pair version visible in the audit trail, so you can always tell which tables produced a given compatibility report.
- Adapter agnosticism. Target adapters receive target-shaped configuration whether the restore is same-cloud or cross-cloud. There is no special-cased execution path for cross-cloud.
Supported pairs
| Source ↓ / Target → | Azure | AWS | GCP | OCI |
|---|---|---|---|---|
| Azure | — | ✓ | ✓ | ✓ |
| AWS | ✓ | — | ✓ | ✓ |
| GCP | ✓ | ✓ | — | ✓ |
| OCI | ✓ | ✓ | ✓ | — |
Coverage note. Cross-cloud restore covers IaaS — compute, storage and networking — across every supported pair. PaaS services, cross-cloud KMS, custom image transfer and object-store data movement carry provider-specific limits. Those limits are surfaced explicitly in your compatibility report before any restore is approved.
Why this matters
Cloud-native backup keeps recovery points inside the cloud that produced them. That is acceptable until the requirement is to recover somewhere else — a region-wide outage, an expiring provider contract, a migration, or a regulator asking whether you could actually leave. A backup you cannot restore elsewhere is a copy, not an exit.
Common questions
Is cross-cloud restore the same feature as migration?
Mechanically, yes. The same translation path that recovers an Azure workload into AWS during a disaster is what moves it there deliberately. Teams use it for planned migration and for cloning production into a different cloud for development and testing.
What happens if a resource has no equivalent on the target?
It appears in the compatibility report as a finding with a severity, before execution. Restores are not attempted optimistically and abandoned halfway.
Does translation need the source cloud to be online?
No. Translation reads the stored envelope, not the live environment, so it works when the source cloud is unavailable — which is precisely when disaster recovery is needed.
Request a demo and we will run a compatibility report against a workload you actually care about.