Skip to content
Notifications
Clear all

Hot take: Most CI/CD migration guides skip the 'people and process' pain.

2 Posts
2 Users
0 Reactions
4 Views
(@martech_maverick_42)
Trusted Member
Joined: 2 months ago
Posts: 35
Topic starter   [#3677]

Everyone's obsessed with converting YAML from Jenkins to GitLab or wrangling GitHub Actions syntax. The docs are full of it. But let's be honest: that's the *easy* part.

The real migration hell is untangling the tribal knowledge, the "this is just how we do it" processes, and the sheer inertia of a team used to one way of working. You're not moving pipelines; you're moving minds.

My last audit found a client with **seven** different ways to trigger a staging deployment, all buried in legacy Jenkins jobs. The technical migration took two weeks. Getting everyone to agree on *one* standardized process in the new system? Three months of meetings, pushback, and "but my special snowflake case."

* **The "It's Not Broken" Brigade:** The senior engineer who built the old system will (rightly) point out its stability. Your newfangled cloud-native thing is an unknown risk.
* **Secret Hoarding:** Credentials living in a personal LastPass, env vars hardcoded in a random script on someone's desktop. The new platform's secret manager is useless if you don't *find* the secrets first.
* **Permission Pandemonium:** The old admin panel was a wild west. Now you have to actually define roles in the new system, and people hate losing their god-like (and unnecessary) access.

So, when you're planning the migration timeline, double whatever the technical estimate is. That extra time is for the human factor: the training, the documentation no one read the first time, and convincing people that change isn't a personal attack.

What was your biggest non-technical hurdle? Was it the security team, the ops team, or just general organizational apathy?



   
Quote
(@eval_engineer_101)
Estimable Member
Joined: 1 week ago
Posts: 87
 

You're absolutely right about the tribal knowledge being the real blocker. I've been researching a move from Jenkins to a SaaS CI, and every vendor's ROI calculator only talks about infrastructure cost and YAML lines saved.

What I'm trying to figure out is how you even measure the "process inertia" pain upfront. How did you convince stakeholders to budget for those three months of meetings? Did you frame it as a security/compliance win from untangling the permission and secret sprawl, or was it more about future velocity?

Because from here, that soft cost is invisible until you're already drowning in it.



   
ReplyQuote