When you need it
Some systems still run in your own data centre, everything in the cloud sits in one region, and nobody has tested a full restore of your backups. A move is coming, but the dependencies between your systems have never been mapped.
What sets the quote
- One target cloud per engagement: AWS, Microsoft Azure or Google Cloud. The source can be on-premises (VMware vSphere, Hyper-V or physical servers), another region or another cloud.
- Sized from your workloads, data volume, cut-over windows and RPO and RTO targets. The counts come from a Migration check, or for cloud sources from a free read-only inventory query you run (AWS Resource Explorer, Azure Resource Graph or Google Cloud Asset Inventory).
- Resilience only, about 2 weeks: a DR pattern, restore tests and a runbook for up to 5 critical workloads using backup and restore or pilot light, with no move.
- Region move or move from on-premises, 4 to 6 weeks: up to 10 workloads (or 30 servers) and 5 TB of data, with up to 3 cut-over windows.
- Larger move, up to 8 weeks: up to 20 workloads and 20 TB of data, or a warm standby or multi-site DR pattern.
- Moves between clouds, and larger estates, are quoted after sizing.
What changes
- The move happens in planned steps, with a way back at each one.
- Each critical workload has agreed RPO and RTO targets and a DR pattern that meets them.
- Restore tests show that your critical workloads come back, and how long that takes.
- Your team has a runbook that says who does what when a region or a critical system fails.
What you get
- Inventory of workloads, data and dependencies, ranked by how critical they are
- RPO and RTO targets for each critical workload, and the DR pattern that meets them
- Migration plan with the order of moves, cut-over steps and rollback points
- Target landing zone, region or DR environment built as code, including the hybrid link (VPN, Direct Connect, ExpressRoute or Cloud Interconnect)
- Server and database replication with the cloud's own tools (AWS Application Migration Service and AWS DMS, Azure Migrate and Azure Database Migration Service, or Migrate to Virtual Machines and Database Migration Service), then cut-over in the windows you agree
- Restore tests with AWS Backup, Azure Backup or Google Cloud Backup and DR, with measured recovery times
- Disaster recovery runbook for your team
- Support during cut-over and a short window after it
For Rayna Tours we restored production on a DR stack, then moved the AWS platform to a new region.
Not included
- Re-architecting applications; workloads move as they are, or with small changes agreed up front
- Running costs of the target region and the DR environment
- Business continuity planning beyond IT systems
What we need from you
- AWS: a time-limited AdministratorAccess permission set in the source and target accounts, or your own deployment role.
- Azure: Contributor on the source and target subscriptions, plus Backup Contributor for the restore tests.
- Google Cloud: Compute Admin, Cloud SQL Admin and Storage Admin on the projects involved, or the matching roles for the services you run.
- A business owner to agree recovery targets and cut-over windows, and application owners who test and sign off each workload after cut-over.
- On-premises moves: read access to vCenter or Hyper-V, firewall rules for the replication agents, and the details of the hybrid link.
How it works
Free 30-minute call, then a Migration check or the sizing query, and a written fixed quote.
Map workloads, data and dependencies, and agree RPO and RTO targets with you.
Build the target as code and rehearse the move with non-production workloads.
Move production in planned steps, in cut-over windows you agree.
Test restores of critical workloads and update the runbook with the results.
At a glance
- Duration
- 2–8 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related work
Rayna Tours
Moving production out of an impaired cloud region
When the AWS region running a travel booking platform was disrupted, production ran on a recovery stack within about a day, and the whole platform moved to a new region within about a month.
- ~1 day
- to run production on a recovery stack
- ~36 h
- to rebuild the shared services as code
Related services
Cloud foundation check
In 1–2 weeks, we review your AWS, Azure or Google Cloud foundation against the CIS benchmark and tie every finding to evidence, the affected resources and a fix.
Zero Trust network review
A one-week review of how traffic enters, leaves and crosses your AWS, Azure or Google Cloud networks, with evidence for every finding, a target Zero Trust design and a prioritised roadmap.
Migration check
In 1–2 weeks, we assess what you run on-premises or in another cloud, with a migration approach per application, a wave plan and a cost estimate for AWS, Azure or Google Cloud.