Commit cd8486ea authored by Akanksha Joshi's avatar Akanksha Joshi
Browse files

Updated the page with details on the Geo engagment model for migrations.

parent e328102d
Loading
Loading
Loading
Loading
+17 −0
Original line number Diff line number Diff line
@@ -50,3 +50,20 @@ Please put together a [coverage issue](https://gitlab.com/gitlab-com/gl-infra/gi
### After PTO

See [returning from pto](/handbook/people-group/time-off-and-absence/time-away-philosophy/#transitioning-back-mindfully).

### Geo Engagement Model For Dedicated Migrations

**Core Support Structure:**
Starting Q4 FY26 (2025-11-01), a Geo DRI is assigned for a 3-week window around each migration: 1 week before, the migration weekend, and 1 week after. The DRI is fully committed to migration issues via Slack during pre/post weeks and available via PagerDuty during business hours (9am-5pm in their timezone) on the migration weekend itself. If no issues arise, the DRI can resume normal Geo duties.

**Migration Weekend Responsibilities:**

The Geo team must have someone prepared and aware of the cutover, coordinate timing with the Project Manager, and be ready to troubleshoot any issues that arise during the customer instance cutover following full data sync.

#### Outside the 3-Week Window

Support is primarily asynchronous via Request for Help (RFH) tickets. Synchronous customer calls are handled adhoc on a case-by-case basis, requiring approval from Engineering Manager Lucie Zhao based on team availability.

#### RFH Process

For sync issues outside the dedicated window, teams submit a [Geo Support Request](https://gitlab.com/gitlab-com/request-for-help/-/issues/new?issuable_template=SupportRequestTemplate-Geo) indicating priority (P1-P4), sync start time, and cutover deadline. These are triaged by the weekly customer support DRI. Geo engineers need access to Opensearch, Grafana, and ideally break glass access to support effectively.