Add dedicated migrations team

---

title: Dedicated Migration Team

---

## The Team

The Dedicate migration team is a team focussed on performing migrations into GitLab Dedicated. This is achieved using either [Geo](https://docs.gitlab.com/administration/geo/) or [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate).

### Team members

| Name | Role |

|---   | -----|

|Muhamed Huseinbašić|  Senior Site Reliability Engineer |

|Dave Dittman|         Site Reliability Engineer        |

|Sophia Langer|        Project Manager |

|Eddie Yoffe|          Program Manager |

|Oliver Seldman|       Program Manager |

|Eren Akca|            Senior Technical Architect |

|Saurav Issar|         Senior Technical Architect |

|Petar Prokić|         Senior Engineer|

|Jessykah Bird |       Engineer |

|Jordan Ng |           Engineer |

|Alex Rosencrans|      Engineer |

|Scott Murray|         Engineer |

|Douglas Alexandre|    Staff Engineer|

|Sampath Ranasinghe|   Senior Product Manager|

|Akanksha Joshi|      Senior Technical Program Manager|

## Mission

Successfully manage incoming migrations through FY26Q2 and FY26Q3 and establish a repeatable process for both Geo and Congregate migrations with a SSOT.

## Resources

- [GitLab group](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group)

- [GitLab project](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group/dedicated-migrations)

- [Migrating Customers to Dedicated internal documentation](https://internal.gitlab.com/handbook/engineering/dedicated/migrating-customers-to-dedicated/)

- [Cutover Cancellation Impact](https://drive.google.com/drive/folders/12GInLFxnT5BPbPJh1JsemUE089-Ctj0e)

## Process

See: [Dedicated Migration Team Process](migration-team-process/)

---

title: Dedicated Migration Team

description: Team focused on smoothing the path of Geo migrations to Dedicated; tooling, process, and engineering

---

[[_TOC_]]

## Team Mission

Partner with the field, customers, and engineering to deliver seamless, fast, and reliable migrations. The team executes and improves processes to eliminate uncertainty and ensures readiness for cutover in Geo-based Dedicated migrations.

### Priorities

* Deliver and refine toolkits that include the documentation, templates, talk-tracks, and tooling to smoother Geo Dedicated migrations for ourselves and our customers

* Work with our engineering peers on features that enable self-serve customer migrations

* Deliver in-flight Geo migration engagements

* Enable our PS peers to deliver Geo migration engagements to scale up and out

* Delivery tooling and process to enable faster scoping and sizing for the field in the pre-sales process

### Team members

| Name          | Role                                 |

|---------------|--------------------------------------|

| Eren Akca     | Staff Migration Engineer             |

| Petar Prokić  | Staff Migration Engineer             |

| Jessykah Bird | Senior Migration Engineer            |

| Glen Miller   | Senior Manager, Software Engineering |

### Roles & Responsibilities

The team:

During the Geo migration portion of a Dedicated engagement, the team has the following responsibilities:

* Works directly with the field and customers to produce automated solutions for technical discovery, validation of data, and capacity planning of their target instance  

* Owns communications, providing internal and external alignment of plans, status, and timings  

* Owns Project Management alignment with the customer Project Planning Office for clear synchronization of activities, comms, timelines, and responsibilities  

* Enables confident production switchovers with minimal risk and maximum speed  

### Operating Principles

#### Customer-Centric Excellence

* **Clear Expectations First**: Every engagement begins with explicit alignment on migration cadence, platform capabilities, and service model boundaries  

* **Consultative Partnership**: We act as trusted advisors, not order-takers, providing honest guidance even when difficult  

* **Transparent Communication**: Regular, structured updates with no surprises \- customers always know where they stand

#### Technical Rigor

* **Discovery Before Design**: Comprehensive technical and business discovery drives all solution approaches  

* **Validation at Every Step**: Multi-layered validation ensures accuracy before any production changes  

* **Automation Where Possible**: Standardized, repeatable processes reduce risk and improve consistency

#### Structured Delivery

* **Milestone-Driven Progress**: Clear checkpoints with customer sign-off prevent scope creep and misalignment  

* **Risk-First Planning**: Identify and mitigate risks early rather than hope for the best  

* **Documentation as Code**: Every process, decision, and artifact is documented for repeatability and knowledge transfer

#### Continuous Improvement

* **Learning Organization**: Every project contributes to improved processes, tools, and methodologies  

* **Cross-Functional Collaboration**: Regular feedback loops with Engineering, Product, and Customer Success teams  

* **Scalable Solutions**: Build capabilities that enable future self-service and automation

#### Internal Alignment

* **One Team Approach**: Clear role definitions with flexible collaboration across disciplines  

* **Shared Accountability**: Success is measured at the team level, not individual contribution  

* **Proactive Communication**: Internal stakeholders are informed and aligned before customer commitments

#### Success Metrics

* To be aligned with larger team metrics in progress

## Process

### Engaging with Others

#### Geo Engagement Model For Dedicated Migrations

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

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. 

##### Production Cutover and Production Support Window

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.

###### 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.

##### RFH Process

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

| Priority | Description |

|----------|-------------|

| 1        | Immediate blocker to data sync or pre-production cutover. Cannot proceed without a fix |

| 2        | Needs to be solved before the end of the pre-production cutover phase, but not a blocker to start |

| 3        | Needs to be solved before production cutover. Can be handled within the production cutover support window |

#### SRE Engagement Model for Dedicated Migrations

##### Pre-production Cutover

A rotating team of SREs is assigned to the pre-production cutover. This is generally the same team that will support the production cutover. Pre-production cutover is often a more measured process that often runs for multiple days. It is where we map out any potential issues with the production cutover. Teams are not required to be on a call bridge. Execution, communication, and hand-overs can be coordinated in #g_dedicated-migrations channel and in the issues for the engagements in the [Dedicated Migrations](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group/dedicated-migrations) project

##### Production Cutover and Production Support Window

A team of SREs is assigned for a 2-week window around each migration: 1 week before, the migration weekend, and 1 week after. This is generally the same team that supported the pre-production cutover. The assigned SREs are to treat all migrations issues as Priority 1 during pre/post weeks. Communication can occur in the #g_dedicated-migrations channel and in the issues for the engagements in the [Dedicated Migrations](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group/dedicated-migrations) project

###### Migration Weekend Responsibilities

The assigned SREs are fully committed to migration issues via Slack during pre/post weeks and will alternate duties during cutover weekends based on their location/timezone. The SRE team will be responsible for executing scripts outside the permission framework of the Dedicated Migrations team, and assisting in troubleshooting of infrastructure (networking, nodes, configuration) concerns.

**Note** 

Many customers need to perform "catch-up" GitLab upgrades in the post-support window. The Dedicated Migrations team should be responsible for coordinating with the customer, scheduling, and executing on these upgrades, with support from the SRE team.

##### Outside the 2-Week Window

Support is primarily asynchronous via Request for Help (RFH) tickets. Per `@fviegas` all Dedicated Migrations RFH are considered priority 1. Synchronous customer calls are handled adhoc on a case-by-case basis, requiring approval from one of Steve Denham/Oriol Lluch Parellada based on team availability.

##### RFH Process

For sync issues outside the dedicated window, teams submit a [Dedicated Support Request](https://gitlab.com/gitlab-com/request-for-help/-/work_items/new?description_template=SupportRequestTemplate-GitLabDedicated) indicating the tenant and request.

#### Scheduling

##### SRE and Geo Coverage

The engineering managers will coordinate finding the proper resources for cutover windows. When PMs have locked-in dates and times for cutovers, and need coverage confirmation, they can reach out to @glen_miller to coordinate with the other EMs. The EMs will use a single epic to track the coverage for each cutover slot.

* [FY27](https://gitlab.com/groups/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group/-/work_items/179)

##### Cutover Slots

Geo migration cutover slots are currently a limited resource. Available slots can be referenced [here](https://docs.google.com/spreadsheets/d/1KRDNw2mXOSAc4DE1hceAWZTRqDGkoV-t5yNymKyXSIo/edit?gid=2116571451#gid=2116571451). Establishing these slots should be part of the pre-sales process. Work with your Dedicated PMs and EMs to reserve a slot.

###### Scheduling Cutover Slots

When scheduling cutover slots, the following guidelines apply:

* Cutover slots are scheduled on a first-come, first-served basis

* Slots are typically available on weekends to minimize customer impact

* Slots should be set at time of deal close. If not, they should be confirmed no later than 14 weeks before the slot date.

* Slots are confirmed only after SRE and Geo coverage is confirmed by the respective EMs

### Dedicated Migration Team Time Off

The Dedicated Migration team follows [GitLab's paid time off policy](/handbook/people-group/time-off-and-absence/).

We balance that with the need to deliver support to our customers every day.

This page is intended to provide an understanding of what we need to do to achieve that balance, making it possible for all to take time off as needed and desired, while we as a team continue to deliver for our customers.

#### One-time setup actions

##### Dedicated Migration Team calendar

1. Be sure you have access to the

[**Dedicated Migrations Team Calendar**](https://calendar.google.com/calendar/embed?src=c_fb53e24f590edfb8f313253126123e48d57254dd73266fae6547a2a4890b0c82%40group.calendar.google.com&ctz=America%2FVancouver)

team calendar.

   1. If you don't have it, verify whether you are part of the Dedicated Migrations Team (`dedicated-migrations-team@`) if you are not, ask to be added via an Access Request.

1. Set up the Google Calendar integration with Time Off by Deel, so that you do not need to populate your personal and "Dedicated Migrations Team" calendars manually.

   1. In Slack, click the `+` sign next to 'Apps' at the bottom of the left sidebar

   1. Search for 'Time Off by Deel' and click 'View'

   1. Under 'Home', click on 'Your Events' to show a dropdown

   1. Click on 'Calendar Sync' under the Settings break

   1. Click on 'Connect your Calendar' and complete the actions to sync your calendar to Time Off by Deel

      * You will see a 'Success! Your calendar has been connected.' message and

        your calendar listed under 'Your synced calendar' in Time Off by Deel on Slack

   1. After your personal calendar is linked, click 'Add calendar' under

   'Additional calendars to include?'. The 'Dedicated Migrations Team Calendar' calendar ID is

   `c_fb53e24f590edfb8f313253126123e48d57254dd73266fae6547a2a4890b0c82@group.calendar.google.com`

#### Choosing and recording time off

Please take time off whenever you need it.

A little thoughtfulness on everybody's part will go a long way toward making it

possible for everyone to take their desired days off. As you look to plan your

time off, please:

* Ensure you know the [company wide paid time off guidelines](/handbook/people-group/time-off-and-absence/time-away-philosophy/)

* Check the calendar and coordinate with the team to ensure we have sufficient cover for days with low availability.

* schedule your time off as far in advance as you can

* Don't lock yourself into nonrefundable travel itineraries before you've taken steps such as the above to be sure you can get the planned days off

* If possible, plan your time off to avoid disruptions

#### Communicate through a coverage issue

Please put together a [coverage issue](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group/pto-coverage/-/issues/new?description_template=pto_coverage) for any PTO longer than 5 days. Some Divisions may have other guidance (for example [Engineering PTO Coverage](/handbook/engineering/#taking-time-off)). Please follow your Division procedures if there is any conflict, and circulate with the team.

#### After PTO

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

## Resources

* [GitLab group](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group)

* [GitLab project](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group/dedicated-migrations)

* [Migrating Customers to Dedicated internal documentation](https://internal.gitlab.com/handbook/engineering/dedicated/migrating-customers-to-dedicated/)

* [Cutover Cancellation Impact](https://drive.google.com/drive/folders/12GInLFxnT5BPbPJh1JsemUE089-Ctj0e)

---

title: Migration Acceleration Team

---

## Team Mission

Partner with customers and engineering to deliver seamless, fast, and reliable migrations. The team executes and improves processes to eliminate uncertainty and ensures readiness for cutover in Geo-based Dedicated migrations.

### Priorities

* Deliver a Delivery Kit that includes the documentation, templates, talk-tracks and tooling to enable customers to self-serve Geo Dedicated migrations

* Own the piloting and execution of this Delivery Kit on upcoming Geo migrations

* Continue to refine the process

* Integrate with the OneSuccess initiative

* Continue lights-on operations for currently owned projects

## Team Members

| Name           | Role                       |

| -------------- | -------------------------- |

| Glen Miller    | Engineering Manager        |

| Jessykah Bird  | Senior Engineer            |

| Eren Akca      | Senior Technical Architect |

| Rachel Stahlke | Program Manager            |

| Oliver Seldman | Program Manager            |

| Sophia Langer  | Project Manager            |

| Petar Prokic   | Senior Engineer            |

## Roles & Responsibilities

The team:

* Works with PreSales, Sales, CSM and Support to ensure customer interface and expectations are aligned  

* Works directly with customers to produce automated solutions for technical discovery, validation of data, and capacity planning of their target instance  

* Provides consultancy to help customer align with upgrades and procedures needed for a smooth migration  

* Owns communications during migration, providing internal and external alignment of plans, status, and timings  

* Owns Project Management alignment with the customer Project Planning Office for clear synchronization of activities, comms, timelines, and responsibilities  

* Enables confident production switchovers with minimal risk and maximum speed  

* Inputs requirements for Environment Automation and Switchboard to enable self-service capabilities and backend automation of instance operation and configuration  

* Builds and maintains tools to streamline customer data gathering; instance data sizes, network topology, synchronization status

## Operating Principles

### Customer-Centric Excellence

* **Clear Expectations First**: Every engagement begins with explicit alignment on migration cadence, platform capabilities, and service model boundaries  

* **Consultative Partnership**: We act as trusted advisors, not order-takers, providing honest guidance even when difficult  

* **Transparent Communication**: Regular, structured updates with no surprises \- customers always know where they stand

### Technical Rigor

* **Discovery Before Design**: Comprehensive technical and business discovery drives all solution approaches  

* **Validation at Every Step**: Multi-layered validation ensures accuracy before any production changes  

* **Automation Where Possible**: Standardized, repeatable processes reduce risk and improve consistency

### Structured Delivery

* **Milestone-Driven Progress**: Clear checkpoints with customer sign-off prevent scope creep and misalignment  

* **Risk-First Planning**: Identify and mitigate risks early rather than hope for the best  

* **Documentation as Code**: Every process, decision, and artifact is documented for repeatability and knowledge transfer

### Continuous Improvement

* **Learning Organization**: Every project contributes to improved processes, tools, and methodologies  

* **Cross-Functional Collaboration**: Regular feedback loops with Engineering, Product, and Customer Success teams  

* **Scalable Solutions**: Build capabilities that enable future self-service and automation

### Internal Alignment

* **One Team Approach**: Clear role definitions with flexible collaboration across disciplines  

* **Shared Accountability**: Success is measured at the team level, not individual contribution  

* **Proactive Communication**: Internal stakeholders are informed and aligned before customer commitments

### Success Metrics

* To be aligned with larger team metrics in progress

---

title: Dedicated Migration Team - Process

---

### Dedicated Migration Team Time Off

The Dedicated Migration team follows [GitLab's paid time off policy](/handbook/people-group/time-off-and-absence/).

We balance that with the need to deliver support to our customers every day.

This page is intended to provide an understanding of what we need to do to achieve that balance, making it possible for all to take time off as needed and desired, while we as a team continue to deliver for our customers.

### One-time setup actions

#### Dedicated Migration Team calendar

1. Be sure you have access to the

[**Dedicated Migrations Team Calendar**](https://calendar.google.com/calendar/embed?src=c_fb53e24f590edfb8f313253126123e48d57254dd73266fae6547a2a4890b0c82%40group.calendar.google.com&ctz=America%2FVancouver)

team calendar.

   1. If you don't have it, verify whether you are part of the Dedicated Migrations Team (`dedicated-migrations-team@`) if you are not, ask to be added via an Access Request.

1. Set up the Google Calendar integration with Time Off by Deel, so that you do not need to populate your personal and "Dedicated Migrations Team" calendars manually.

   1. In Slack, click the `+` sign next to 'Apps' at the bottom of the left sidebar

   1. Search for 'Time Off by Deel' and click 'View'

   1. Under 'Home', click on 'Your Events' to show a dropdown

   1. Click on 'Calendar Sync' under the Settings break

   1. Click on 'Connect your Calendar' and complete the actions to sync your calendar to Time Off by Deel

      - You will see a 'Success! Your calendar has been connected.' message and

        your calendar listed under 'Your synced calendar' in Time Off by Deel on Slack

   1. After your personal calendar is linked, click 'Add calendar' under

   'Additional calendars to include?'. The 'Dedicated Migrations Team Calendar' calendar ID is

   `c_fb53e24f590edfb8f313253126123e48d57254dd73266fae6547a2a4890b0c82@group.calendar.google.com`

## Choosing and recording time off

Please take time off whenever you need it.

A little thoughtfulness on everybody's part will go a long way toward making it

possible for everyone to take their desired days off. As you look to plan your

time off, please:

- ensure you know the [company wide paid time off guidelines](/handbook/people-group/time-off-and-absence/time-away-philosophy/)

- check the calendar and coordinate with the team to ensure we have sufficient cover for days with low availability.

- schedule your time off as far in advance as you can

- don't lock yourself into nonrefundable travel itineraries before you've taken steps such as the above to be sure you can get the planned days off

- if possible, plan your time off to avoid disruptions

### Communicate through a coverage issue

Please put together a [coverage issue](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group/pto-coverage/-/issues/new?description_template=pto_coverage) for any PTO longer than 5 days. Some Divisions may have other guidance (for example [Engineering PTO Coverage](/handbook/engineering/#taking-time-off)). Please follow your Division procedures if there is any conflict, and circulate with the team.

### 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 2-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 2-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.