Update Geo engagement model for Dedicated Migrations (4cd06230) · Commits · GitLab.com / Content Sites / handbook

content/handbook/engineering/infrastructure-platforms/gitlab-dedicated/dedicated-migrations.md

+18 −6

Changes for content/handbook/engineering/infrastructure-platforms/gitlab-dedicated/dedicated-migrations.md: 18 added lines, 6 removed lines.
Original line number	Diff line number	Diff line
		@@ -21,6 +21,7 @@ Partner with the field, customers, and engineering to deliver seamless, fast, an

		\| Name \| Role \|
		\|---------------\|--------------------------------------\|
		\| Douglas Alexandre \| Staff Backend Engineer \|
		\| Eren Akca \| Staff Migration Engineer \|
		\| Petar Prokić \| Staff Migration Engineer \|
		\| Jessykah Bird \| Senior Migration Engineer \|
		@@ -79,17 +80,28 @@ During the Geo migration portion of a Dedicated engagement, the team has the fol

		#### Geo Engagement Model For Dedicated Migrations

		##### Pre-production Cutover and Requests Outside the 2-Week Production Support Window
		##### Support During a Cutover

		For support during any period outside the production cutover window, please file an RFH (see below). This include pre-production cutover. There will not be an assigned Geo engineer for pre-production. Customer call requests are handled adhoc on a case-by-case basis, requiring approval from Engineering Manager Lucie Zhao based on team availability.
		Dedicated Migrations owns first-line troubleshooting during an execution. When Geo expertise is needed, try these in order:

		##### Production Cutover and Production Support Window
		1. The Geo engineer currently on the [support rotation](https://gitlab.com/groups/gitlab-org/geo-team/-/work_items/3#customersupport-rotation).
		2. If that engineer is unavailable, including outside their working hours, one of the Geo for Self-Managed domain experts below.

		A Geo DRI is assigned for a 2-week window around each production 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.
		No Geo engineer is pre-assigned to a cutover.

		###### Migration Weekend Responsibilities
		##### Geo for Self-Managed Domain Experts

		These engineers previously worked on Geo and can help when the support rotation DRI is unavailable. This is a backup contact list, not an on-call schedule. Nobody on it is guaranteed to respond immediately or after hours, and they can say no if something else has priority. Their manager is listed for context if you need to escalate or can't reach them directly.

		\| Engineer \| Manager \|
		\|---\|---\|
		\| [Brian Legault](https://gitlab.com/brianlegault) \| {{< manager-by-report-name "Brian Legault" >}} \|
		\| [Douglas Alexandre](https://gitlab.com/dbalexandre) \| {{< manager-by-report-name "Douglas Barbosa Alexandre" >}} \|
		\| [Michael Kozono](https://gitlab.com/mkozono) \| {{< manager-by-report-name "Michael Kozono" >}} \|
		\| [Natanael Silva](https://gitlab.com/nsilva5) \| {{< manager-by-report-name "Natanael Silva" >}} \|
		\| [Victor Prêté](https://gitlab.com/victorprete) \| {{< manager-by-report-name "Victor Prêté" >}} \|

		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.
		They are not part of the current Geo rotation. Log the problem, investigation, and outcome on the Dedicated Migrations work item or Geo support request issue, not Slack, so there's a durable record either way.

		##### RFH Process