Draft: 18.11 Outlook Planning (March 16 - April 10 2026)

This is the current outlook for the 18.11 milestone. The Geo team schedules issues and works in a continuous Kanban manner, while still aligning with milestones. See our process page for more details.

Last Updated: 20th Feb 2026

Migration Cohort 1 to Protocell

This epic represents the work needed to achieve our first major delivery milestone of the Protocells Code Yellow initiative. We plan to migrate select inactive namespaces (Cohort 1) from the gitlab.com legacy cell to our first production cell (the Protocell).

Organization Data Migration Feature Parity Phase 1

Instead of focusing on Cells 1.0, 1.5, and 2.0 for the near term we will work on offloading that 50%+ (other) that is not our top 50 namespaces. We'll have different cohorts to migrate, starting with inactive users all the way to users using application. The more features Cells support the larger/more customers we can migrate. We've reduced scope from the original design for Org Mover and renamed to Organization Data Migration for Protocells.

Organization data migration is a critical component of multi-cell architecture, enabling the movement of entire organizations from one cell to another while maintaining data integrity and minimizing downtime.

The migration process involves replicating PostgreSQL data, Git repositories, object storage files, and container registry data from a source cell to a destination cell, with various implementation strategies ranging from automated replication systems to manual migration processes.

This approach repurposes existing Geo replication infrastructure to handle organization migration. By configuring the destination cell as a temporary Geo secondary site, we can leverage proven replication mechanisms while minimizing custom development.

If we disable Geo configuration in Protocells, then we can more easily configure the Protocell to act as a secondary Geo site without a lot of modifications.

Org Data Migration: Support Cohort 0 Organization move

After we've moved an internal organization that we actually use, we should have a good idea of the reliability of an org move of that size. Or perhaps the real move somehow revealed that we need increased assurances.

So, increase confidence of reliability to the point where a handful of customers are willing to be beta testers, and we are willing to move them.

For example we may need:

Organization migration: Handle replicables of cell-local tables for feature parity

Who: Douglas

Geo currently assumes that all PG data is replicated. LFS object and Git repo replication will not work if those tables are missing relevant data.

Organization migration: Geo verification state tables sharding key work

Who: Douglas, Natanael

Geo verification state tables (all *_states tables owned by Geo) have been marked as gitlab_main_cell_local or gitlab_ci_cell_local in MR gitlab!182030. This means these tables won't be copied or replicated by either of the above approaches to the target cell (Protocell).

However, the Protocell needs to read the checksum from these tables during the verification phase.

Dedicated Asks

KTLO

Stretch Items

Customer Support Triage DRIs

March 16 - 27 - Natanael

March 30 - April 10 - Victor

PTO

April 3 - 6 - Chloe

March 18-27, April 3 - Mike

March 16 - April 10 Zack

April 3 - 10 Douglas

Edited by Lucie Zhao