CI/CD migration estimator
./migrate --from $A --to $B
Switching CI/CD platforms is rarely a weekend project. This calculator estimates engineer-hours, calendar time, cost, and risk for the most common migration paths, based on observed averages from team retrospectives.
~/cicdcalculator/migrate --estimate
live
$ result.json
{
"from": "Jenkins",
"to": "GitHub Actions",
"per_pipeline_hours": 6,
"pipeline_hours": 72,
"setup_hours": 60,
"total_hours": 132,
"timeline_weeks": 3,
"risk": "high",
"cost_usd": 13,200
}
Estimate uses observed averages from public engineering blog posts and team retrospectives. Real numbers vary by pipeline complexity, monorepo vs polyrepo structure, and whether you rebuild pipelines from scratch versus translating yaml.
Common migration paths
| From | To | Typical cost | Calendar weeks | Notes |
|---|---|---|---|---|
| Jenkins | GitHub Actions | $8-25K | 8-12 | Most common migration. Plan for plugin-by-plugin replacement, secrets rotation, and a parallel-run period. |
| Jenkins | GitLab CI | $10-30K | 10-14 | Often paired with a move to GitLab source control. Heavy if your Jenkins has lots of shared libraries. |
| GitLab CI | GitHub Actions | $5-15K | 4-8 | YAML-to-YAML, similar concepts. Watch for GitLab-specific features (DAG, dynamic envs). |
| CircleCI | GitHub Actions | $4-12K | 3-6 | Most teams' first CI move. orb-to-action mapping needs care; resource_class becomes runner labels. |
| Bitbucket | GitHub Actions | $6-15K | 5-9 | Often coupled with a code-host move. Budget time for pipeline rewrites and team training. |
| Anywhere | Buildkite | $10-30K | 6-12 | Adds the cost of standing up agent infrastructure. Pays back at scale. |
How to plan the migration
- 01. Inventory. Count your pipelines, list custom plugins or actions, document secrets, identify the half-dozen jobs that absolutely cannot break.
- 02. Pick a pilot. Choose a low-risk pipeline (a small service, a docs site) and migrate it end-to-end. Document everything you learn.
- 03. Migrate in shadow mode. Run both systems in parallel for 2-4 weeks. The old platform remains the gate; the new one is observed.
- 04. Rotate every secret. Don't copy-paste. Every secret gets a fresh value in the new platform's secret store.
- 05. Cut over by team. One team at a time. Each team flips their merge gate to the new platform once they're confident.
- 06. Decommission carefully. Keep the old platform running read-only for at least 30 days for archive access and rollback. Then turn it off.
Related
Frequently Asked Questions
# click any question to expand
How long does a CI/CD migration take?>
For a mid-size team migrating 10-20 pipelines from Jenkins to a hosted platform, plan 6-12 weeks of part-time work for two engineers. Cloud-to-cloud migrations (GitLab to GitHub Actions, for example) usually take 3-6 weeks because the YAML structures are similar. Migrations away from Jenkins always run longer due to plugin sprawl and the variety of custom Groovy logic that accumulates.
Should I rewrite pipelines or auto-translate them?>
Auto-translation tools (GitLab's importer, GitHub Actions Importer, atomicgo's pipeline-converter) handle the common case but produce messy yaml that's hard to maintain. For long-lived pipelines we recommend treating migration as a chance to simplify: rewrite from scratch using current best practices, dropping the accumulated workarounds. The extra time pays back in maintainability.
What's the riskiest part of CI/CD migration?>
Secrets and credentials. Every CI/CD platform has its own secrets store, and accidentally committing a secret while moving between systems is a real risk. Plan a separate secrets-rotation step where every secret is rotated and re-issued in the new system, never copy-pasted. Also watch for environment-specific URLs and config drift between staging and production pipelines.
Can I run two CI/CD systems in parallel during migration?>
Yes and you should. Most teams run the new platform in shadow mode for 2-4 weeks: builds happen on both, but the old system remains the source of truth for merge gates. Once the new system has matched the old for a couple of weeks without surprises, flip the gate. This staged cutover prevents PR queues from grinding to a halt during the move.
When is migration not worth it?>
When your current platform works, your team is happy, and the only motivation is cost. The savings need to justify 3-12 weeks of engineering time plus production risk. A useful rule: only migrate if the projected annual savings exceed 2x the migration cost. Otherwise spend the same engineering time on optimisation inside your current platform.
Should I migrate to a self-hosted Jenkins from a cloud CI?>
Rarely. Most teams migrate the other way (off Jenkins, onto a hosted platform). The case for moving to Jenkins is compliance (data sovereignty, audited build environments) or extreme scale. If neither applies, the operator burden of Jenkins outweighs any per-minute savings versus a hosted platform.