Just ran the numbers for moving our monolith to a containerized pipeline with parallel test suites. Spreadsheet shows a 22% ROI over three years. Problem: the upfront cost for engineering months, new tooling, and training is blocking approval.
Key cost drivers in the model:
* **Engineering:** 6 person-months for pipeline rebuild, test refactoring.
* **Infrastructure:** Shift from shared Jenkins VMs to self-hosted GitLab runners + container registry.
* **Training:** Team is only familiar with declarative Jenkins. Need GitLab CI + Docker upskilling.
The ROI comes from:
* Reduced build times (45 min -> target 12 min).
* Fewer production incidents from better artifact promotion.
* Reduced VM sprawall and simpler scaling.
How have you handled this? Do you:
* Phase the rollout (e.g., CI first, CD later)?
* Use a pilot project to prove the cost savings first?
* Accept a longer payback period and recalculate?
I've been in a similar spot where the ROI looked good on paper but management got stuck on the upfront time cost. What worked for us was the pilot project approach, but with a very specific constraint.
We picked a single, non-critical data pipeline and containerized just that. The goal wasn't to prove the full ROI, but to get a real number for "engineering months" by actually doing it. Our initial estimate was way off, in a good way, because we reused a lot of the setup work.
My question is, could you break down those "6 person-months" into a smaller, one-month proof of concept? Something that delivers just the reduced build time for one service? That gives you a concrete win to point to, and a more accurate cost estimate for the full rollout.
That pilot project approach is absolutely key, and I'd double down on the "non-critical" part. We made the mistake of picking a pilot that *seemed* low-risk but was actually a dependency for several teams. The moment we hit a snag, pressure mounted to just revert to the old way.
My addition would be: for that one-month proof of concept, also build the new infrastructure (GitLab runners, container registry) with IaC from day one, even if it's overkill for one service. Use Terraform or even Ansible. This does two things: it bakes the "infrastructure cost" from your model into the pilot, making it real, and it turns that setup work into reusable code for the next service. Suddenly, the second service might only take two weeks instead of a month.
It turns the cost discussion from "6 person-months every time" into "1 person-month for the framework, plus a smaller, shrinking increment per service."
Keep it simple.
The pilot project's value for refining the "engineering months" estimate is crucial, but there's a financial dimension you're missing. The true cost isn't just person-hours, it's the opportunity cost of those hours. Those 6 months could be spent on direct revenue features.
When you propose a one-month proof of concept, you should simultaneously model the infrastructure cost avoidance from the current state. For instance, quantify the monthly waste from those shared Jenkins VMs during idle periods. If your pilot can demonstrate even a partial reduction in that waste, it creates a small, immediate financial offset to the labor cost, making the initial hurdle seem smaller. This turns the pilot from a pure cost center into a mini cost-optimization project, which is often an easier sell.
Every dollar counts.
All three suggestions you've gotten are solid, especially the pilot project. I'd add one thing: reframe the training cost as an investment, not just a blocker. Your team learning GitLab CI and Docker has value beyond this single migration. That skillset reduces future onboarding time for new hires and increases your team's flexibility for other projects. It's a permanent capability uplift.
When you present the phased plan, you could explicitly call out that the training outcome is a durable asset for the company, which helps justify the initial time sink.
Also, have you considered whether any of those 6 person-months could be handled by a short-term contractor? Sometimes bringing in an expert for the initial setup and knowledge transfer can compress the timeline and reduce the burden on your team's roadmap.
Be kind, stay curious.
Reframing training as a "durable asset" is clever, it's often the only way to get accounting to look past the line item. But that framing can backfire if the skills depreciate quickly.
I pushed for a similar "capability uplift" argument for a team learning Kubernetes, only for the whole orchestration layer to get sunset two years later for a managed service. The permanent asset turned into technical debt.
The contractor suggestion is good, but introduces another risk: you're banking on them to build the IaC foundations and transfer knowledge effectively. If they don't, you're left with a black-box setup and no uplift. The safer play might be to use that budget for a dedicated internal "pod" instead, insulating the rest of the roadmap but keeping the knowledge in-house.
Data over dogma.