Vantage Outfitters: Choosing a DR Strategy Before Peak Trading
Vantage Outfitters is an online retailer with €180 million in annual sales, 70% of which occur between October and December. Its stack runs on 40 VMware virtual machines in an owned data centre, with nightly backups to tape and a contract for a cold site 300 km away that has not been used in five years. Checkout handles about 1,200 orders per hour at peak. The board has approved €450,000 over two years for DR improvement. The CISO has proposed either (a) a pilot-light environment in a public cloud region or (b) a warm standby in a second colocation facility with storage replication. Legal requires customer payment data to remain in-country; the payment provider is already cloud-based.
The current plan claims a four-hour RTO for checkout, but a full restore from tape takes 26 hours. The head of engineering argues that 'the cloud is cheaper and faster'; the infrastructure manager warns that re-platforming 40 VMs will take longer than the project window. Peak trading starts in five months.
1. Evaluate the pilot-light and warm-standby options against RTO, RPO, cost, compliance and skills. What tiering would you recommend?
Read the worked answer
Neither option should be applied uniformly to all 40 virtual machines. The first step is tiering by business impact. Checkout, payment authorisation and order confirmation are tier 1. Catalogue browsing and customer account functions are tier 2. Reporting, staging and internal tools are tier 3.
- Pilot light in public cloud: low ongoing run cost because only core services and data are always on. It can meet a four-hour RTO only if images, infrastructure-as-code, data replication and automated failover are built and tested. Re-platforming 40 VMs in five months is unrealistic and would consume the budget. Payment data residency is a constraint unless the provider offers an in-country region and the legal analysis confirms it.
- Warm standby in a second colocation facility: compatible with the existing VMware estate, so no re-platforming. Storage replication can achieve a short RPO, and pre-built hosts can credibly meet four hours. It has higher run cost and requires duplicate hardware, network and operational skills, but it fits the project window and the compliance constraint more predictably.
Recommendation: warm standby for the 8-12 tier-1 VMs, with storage replication and automated runbooks; pilot light or backup-and-restore for tier 2; tape or archive restore for tier 3. A cold site plus 26-hour tape restore cannot meet the claimed four-hour RTO and should not be presented as the DR solution.
2. Propose a five-month implementation and testing sequence that reduces peak-season risk rather than adding to it.
Read the worked answer
The sequence must respect the peak freeze and avoid a large re-platforming project.
- Month 1: confirm BIA and tiering, define RTO/RPO, select the colocation site, place procurement orders and confirm legal approval for data location. Procure replication and network links early because lead times are the main schedule risk.
- Month 2: build the standby network, storage and hosts; establish replication for tier-1 data; document runbooks and decision authority for invoking DR.
- Month 3: replicate tier-1 systems and perform a non-production failover test. Validate DNS switching, payment-provider connectivity and data consistency. Measure actual RTO and RPO rather than assuming them.
- Month 4: conduct an off-peak production failover of checkout and order capture, with a defined rollback and stop criteria. Fix defects, train on-call staff and update the plan.
- Month 5: enter a change freeze before peak, complete a readiness review, confirm contact lists and escalation, and schedule a post-peak retest.
Throughout, communicate that the objective is a tested tier-1 recovery capability, not a complete transformation. Engineering's cloud proposal may remain a strategic option, but it should not be forced into a five-month window with a peak-season deadline.
3. The head of engineering argues that the cloud is cheaper and faster. How would you make and document the decision?
Read the worked answer
I would replace the general claim with a like-for-like, risk-adjusted comparison over at least three years.
The comparison should include:
- Build and migration labour, including re-platforming, testing and dual running.
- Recurring infrastructure, storage, replication, network and egress charges.
- DR testing costs, including staff time and any temporary duplicate environments.
- Compliance and legal review for payment data residency.
- Skills and operating-model change, including new automation and cloud incident response.
- Expected recovery performance against the four-hour RTO and the required RPO.
- Exit and lock-in risk, including data retrieval and contract terms.
A weighted decision matrix should be agreed before scoring, with criteria covering recovery capability, time to implement, total cost, compliance, operational risk and strategic fit. The output should record the chosen option, the rejected option, the assumptions and the residual risk. If the cloud cannot be implemented and tested before peak, the decision record should say so explicitly rather than implying that cloud is inherently slower. This gives the board an auditable decision and prevents the debate from being reopened after the next incident.