17. Launch a regional data-residency commitment

The brief

Lead a regional launch for a SaaS product that currently runs in one geography. An enterprise customer asks for customer content to remain in the new region. Treat this as a product commitment to validate with the responsible legal/security teams, not a statement that a particular law has been satisfied.

• Product data, search indexes, backups, analytics, support exports and incident tooling are owned by different teams.
• A launch customer expects availability in 16 weeks; existing accounts must explicitly choose whether to migrate.
• Some external observability and support vendors cannot yet guarantee regional processing.

Constraints

Target launch window≤ 16 weeks

Declare the target launch timeline; if scope cannot safely fit, propose an explicit reduced-scope or delayed decision.

Complete data inventory

Include replicas, backups, logs, support access and derived data in the residency scope or document explicit exclusions for approval.

Customer migration safety

Migration must preserve access and provide verifiable completion and rollback boundaries.

Vendor exceptions

An unresolved vendor exception cannot silently become a fulfilled customer promise.

What to cover

1. 01

   Commitment and scope

   Translate the request into a data-class/location/access matrix with unresolved questions and decision owners.

2. 02

   Delivery plan

   Map team and vendor dependencies, a critical path, staffing assumptions and milestone evidence.

3. 03

   Migration and launch gates

   Define a pilot, data verification, support readiness, rollback boundaries and customer communication.

4. 04

   Decision memo

   Compare a limited launch, a delay and a vendor replacement; recommend one with measurable triggers for revisiting it.

Worked designs

No worked design has been published for this brief yet. You can start an attempt and share your approach in the discussion.

Review rubric

AI feedback uses these criteria. Scores are practice feedback.