Rebuilding Software Delivery on GitLab Under a Fixed Government Deadline

Background

In mid-2023, the federal client required the project to move onto its internally controlled environment. The change affected the cloud environment as well as the development toolchain, including a move away from the existing Jenkins- and Bitbucket-based delivery workflow.

For roughly six months, the development manager and another DevOps engineer focused on the new AWS environment and the GitLab migration. During that period, my responsibility was keeping the existing CI/CD platform running so developers and QA could keep delivering software.

Challenge

Late in the year, the deadline became immediate: developers needed to be working through the federal client's environment by year end. I was tasked with getting approximately ten interconnected services building and deploying through GitLab.

I had never used GitLab before. Several target environments were still incomplete, and the services had dependencies that meant they couldn't simply be migrated in any order — the sequence itself was part of the problem to solve.

Approach

I opened a shared working session and brought together a cross-functional group of roughly eight developers and QA team members. Rather than trying to become the expert on every application, we worked through the services in dependency order.

As each service hit a build or deployment problem, I brought in whoever knew that service best. Their application knowledge guided the diagnosis while I focused on translating the existing delivery behavior into GitLab pipelines. When the group hit something nobody in the room could solve immediately, we identified who could and pulled them into the session.

Result

Within about a week, we had end-to-end GitLab build and deployment capability working across the roughly ten-service platform — we preserved continuity of software delivery through the cutover, not a pause and restart. That let the project complete the migration and retire the legacy AWS environment and the tooling that had gone with it.

Lessons

This reinforced something I've seen repeatedly in platform engineering: successful tooling migrations aren't primarily tooling projects. They're coordination and delivery projects. The fastest path wasn't for one person to learn every service; it was sequencing the work correctly and making sure the right expertise was in the room when each problem showed up.

It also reinforced the value of adaptability. I went into this without prior GitLab experience, but years of operating the existing delivery platform gave me the context to learn the new tool quickly and stay focused on preserving the behavior the engineering team depended on.