Case Studies / DevOps Transformation
CI/CD Migration • DevOps Transformation
GitLab Self-Hosted Modernization
Containerizing & upgrading a legacy GitLab instance to 18.9.1 — nine version hops, zero data loss, and a clean, reproducible platform the client can now upgrade in minutes.
Bare-metal GitLab, three major versions behind
Our client operated a legacy GitLab EE instance (v16.11.10) installed directly on a bare-metal host. As the team scaled, maintaining an uncontainerised GitLab deployment was creating real friction — manual upgrades, inconsistent environments, slow disaster recovery, and tightly coupled SSL and database configuration were slowing the engineering team down.
Key pain points included:
- GitLab tightly coupled to an out-of-date host OS no longer receiving security updates
- Any configuration change risked destabilising adjacent services, with no safe way to test changes before production
- The database ran externally on an older PostgreSQL version on Amazon RDS, an additional compatibility constraint blocking the upgrade path
- Three major GitLab versions of upgrade debt, with nine mandatory background-migration checkpoints to clear
- Manual, untested backup and restore procedures with no off-host backup destination
Containerize first, then upgrade nine hops safely
Before touching the upgrade path, we redesigned the deployment architecture, then executed the version upgrade as a disciplined, validated sequence.
Containerisation Design
Wrote a Docker Compose configuration to externalise all stateful concerns — configuration, logs, data, and SSL certificates — into host volume mounts, making the GitLab version changeable with a single image-tag update.
Pre-Migration Database Remediation
Audited and corrected database object ownership with a comprehensive SQL remediation script, then implemented a PostgreSQL event trigger to automatically correct ownership on newly created objects during future migrations.
Nine-Hop Upgrade Execution
Executed each of the nine required upgrade hops with a consistent protocol: full backup, image-tag update, restart with monitored logs, zero-background-migration verification, health checks, and functional verification of login, repository access, and CI runner connectivity.
Registry & Storage Modernization
Introduced Amazon S3 as the storage backend for container images during the v2 metadata migration, avoiding object duplication in the process.
A structured, audit-driven migration
Containerisation Design
Designed and validated the Docker Compose deployment architecture before touching the upgrade path.
Pre-Migration Database Remediation
Corrected all database object ownership issues and verified zero violations before the first upgrade hop.
Nine-Hop Upgrade Execution
Executed all nine version hops from GitLab 16.11.10 to 18.9.1, each with a full backup, health check, and functional verification.
From hours of risk to minutes of routine
The nine-hop upgrade surfaced and resolved every piece of latent upgrade debt, leaving a clean, well-documented foundation:
Operational Velocity
- Future upgrades now require a single image-tag change and a container restart
- New test or disaster-recovery environments spin up from the same config in minutes
- Eliminated all latent database ownership and registry metadata issues
Resilience & Security
- Rollback is now deterministic, with recovery time down from hours to under 30 minutes
- Backups are automated and shipped directly to S3
- Externalised secrets, TLS-verified LDAP, and properly scoped database permissions
The client is now on the current GitLab EE release with a clear, documented procedure for staying current. What previously required host-level coordination and significant downtime is now a routine, low-risk operation.
Ready to create your success story?
Let's discuss how we can help you achieve similar results for your organization.