It's completely normal. You're measuring against an impossible baseline - the "stable" Jenkins system that had years of accumulated tribal knowledge baked in.
The key is to stop the direct comparison. Track total cost per successful deployment instead, including both the old platform's licensing/ops overhead and your current debugging hours. When we did this, GitLab was cheaper by week six, even with the stabilization tax.
Your timeline sounds on track. Ours took about ten weeks to plateau. The turning point was documenting each new failure mode immediately instead of trying to make GitLab behave like Jenkins.
Measure twice, spend once
Normal. That's the tax you pay for ditching a mature system.
You're comparing hours debugging GitLab to zero. Compare them to the hours you *weren't* spending debugging Jenkins, because you were spending them on admin, maintenance, and waiting for slow executors instead. That's the real baseline.
It plateaued for us around three months when we stopped trying to make it behave like Jenkins and just built new runbooks for its own stupidities. Document each fix immediately, or you'll just relearn it next month.
-- old school
That "stop comparing to zero" point is so helpful, thank you. I think I'm stuck in that exact mental trap. I keep thinking about the quiet weeks on the old system, but you're right, that time wasn't free - it was just spent on different, slower headaches.
But how do you actually track that? My leadership sees a logged debugging hour as a cost, but a missed admin task on the old system was invisible. Did you have to retroactively log "avoided" work to make the comparison fair?
Yes, it's normal. You're in the first month of paying the stabilization tax.
We tracked it. Our team spent 30% of dev time on pipeline issues for weeks 2-5 after GitLab migration. It dropped below 5% by week 10.
Justify it by showing total cost per deployment now vs last quarter on Jenkins. Include your old admin overhead and licensing. The number usually flips in 6-8 weeks even with debugging hours. That's your justification. The timeline isn't stretching, you're just measuring against the wrong baseline.
Data over opinions
Tracking "old admin overhead" is the real trick. We used a baseline average of Jira tickets tagged "Jenkins/admin" from the previous six months to quantify that invisible cost. It was the only way to stop finance from treating every debugging hour as a net new expense.
But be careful with that > 6-8 week flip. It only holds if your team isn't also trying to change the workflow while they migrate. If you're moving to cloud runners and containerized builds at the same time, the stabilization tax gets a lot steeper.
Data over dogma.
Welcome to the stabilization tax. You're not comparing to zero, you're comparing to the invisible time you used to spend baby-sitting Jenkins executors and untangling groovy scripts. The cache key syntax and base library mismatches are just the new shape of the tax form.
You asked how long. For us, it was about three months before the daily fires stopped. The critical shift wasn't technical, it was mental: we stopped trying to make GitLab CI mirror Jenkins behavior and started building internal runbooks for GitLab's own specific brand of failure. Document every single fix in a shared doc the moment you make it, or you'll waste a week re-solving the same artifact path problem next quarter.
To justify it, pull the last six months of Jenkins-related admin tickets and average that time. Add it to your old licensing/runner cost. That's your real baseline. Your current "debugging hours" plus the new platform cost is probably already lower. Show your manager that total cost per deployment calculation; the ROI isn't stretching, you were just measuring from the wrong starting line.