I find myself in a recurring and deeply frustrating architectural pattern, not within our systems, but within my development team's culture. We are maintaining a legacy CI/CD pipeline constructed around a set of homegrown bash scripts and a single, overburdened Jenkins instance. The pipeline is demonstrably broken: it has non-deterministic failures, lacks any meaningful test or deployment stages, and requires manual intervention for approximately 30% of our merges. My proposal to migrate to a modern, declarative pipeline solution (e.g., GitLab CI/CD, GitHub Actions, or even a properly configured Jenkinsfile setup) is met with uniform resistance.
The arguments against change follow a predictable sequence:
1. **"It works."** The definition of "works" is stretched to mean "sometimes completes after two attempts and a manual restart of the worker node."
2. **"We don't have time to learn a new tool."** This is stated while the team collectively spends hours each week deciphering cryptic script errors and coordinating manual deployment windows.
3. **"Our custom scripts are more flexible."** This ignores the technical debt and the fact that this "flexibility" directly translates to unreliability and a bus factor of one.
From an integration and migration standpoint, this is a textbook case of accruing operational drag. The existing tool isn't just a suboptimal choice; it's a critical point of failure that actively slows development velocity and increases risk. I have conducted a thorough analysis and prepared a phased migration plan that would allow us to parallel run the old and new systems, mitigating risk.
* **Phase 1:** Containerize the build environment to ensure consistency.
* **Phase 2:** Implement a basic declarative pipeline for a single, non-critical service.
* **Phase 3:** Gradually shift services, validating each step.
* **Phase 4:** Decommission the legacy scripts.
The technical path is clear to me. The obstacle is entirely human and organizational. Have others successfully navigated this type of institutional inertia? Specifically, what strategies proved effective for demonstrating the tangible, immediate cost of the status quo in a way that moves the conversation from emotional preference to objective evaluation of system quality attributes like reliability, maintainability, and efficiency? I am particularly interested in approaches that reframe the migration not as "learning a new tool" but as "reducing the cognitive load and toil associated with a defective process."
Ugh, the "it works" argument drives me nuts, especially when you've already quantified the failure rate. 30% manual intervention is a huge, measurable cost.
I've had success by quietly building a parallel, simple pipeline for just one small project. When the old system inevitably fails again, you can say, "Actually, for project X we've been using this other method. It handled the last merge automatically. Here's the link." Showing is always stronger than telling.
data over opinions
That's the only tactic that's ever broken through for me, too. The quiet parallel build.
But you need to pick a project where the original poster is the sole or primary committer. If you try to sneak it onto a shared service without buy-in, they'll call it shadow IT and shut it down. Make it so low-friction for that one person that using it is just easier than fighting the old system.
Beep boop. Show me the data.