DevOps platforms bill per user and per pipeline-minute, and top features are gated behind premium tiers, costs climb with team size. Self-hosted, open toolchains (Gitea/Forgejo, Drone, Woodpecker, Argo CD) remove seat licensing. The catch is that pipelines are platform-specific, so translation is the real work. Bamboo’s Server/Data Center end-of-life makes this especially timely, since it turns an optional cost decision into a forced re-platform window with a hard deadline.
What actually drives the cost
The three cost shapes differ, and knowing which one you have tells you where the savings come from. GitLab Premium and Ultimate bill per seat with annual commitments and CI-minute overages, so cost tracks headcount. CircleCI bills on usage and credits, so cost tracks pipeline volume and can surprise finance when builds grow faster than the team. Bamboo licenses per agent and is being wound down, so the pressure is a deadline rather than a bill. Jenkins is the odd one out: it is free, and the cost is maintenance, plugin sprawl, version conflicts, and a steady stream of security advisories. Naming your cost shape keeps the calculator honest.
Build the conversion backlog
Catalog repositories, pipeline definitions, runners, secrets, and artifacts; map integrations (SCM, container registries, deploy targets); and document permissions and environments. This inventory is also your conversion backlog: each pipeline definition is a unit of translation work, and the ones with complex conditions, matrix builds, or bespoke plugin use are where the effort concentrates.
Migrate repos, then pipelines
Most targets can pull-mirror repositories directly from the source (including issues/PRs via API). The bigger lift is translating pipelines: .gitlab-ci.yml / Azure Pipelines YAML / Bamboo plans become Gitea Actions, Drone, or Woodpecker definitions. Re-create runners/agents, migrate secrets, and re-point webhooks and service connections.
The mental model that unifies these targets is the same: capability comes from container images, not from installed plugins or imported orbs. A step names an image that already carries the tool it needs, whether that tool used to be a Jenkins plugin, a CircleCI orb, or a Bamboo task. Internalizing that shift is what makes the conversions feel mechanical rather than open-ended, and it is why pushing real branching logic into scripts, rather than into YAML, keeps the new pipelines readable.
Which toolchain fits your workflow
Match the target to what you lean on. If you mostly need Git plus review plus CI, Gitea or Forgejo with Actions-format pipelines is ample. If you are already container-native and want pipelines versioned in the repo, Drone or its community fork Woodpecker fit well, and both flatten a plan or Jenkinsfile into simple steps. Continuous delivery to Kubernetes points toward Argo CD. What none of these carry over for free is a premium tier’s security and compliance suite, so plan deliberate replacements rather than assuming parity.
Cutover team-by-team
Mirror repos and migrate issues/artifacts, translate and dry-run pipelines (build/test/deploy), then switch teams over project-by-project. Keep the source platform active until pipelines are green; re-point webhooks/runners back on failure.
Proving a project builds end-to-end
Pipeline dry-runs covering build, test, and deploy; secret and artifact resolution; webhook/integration tests; and a deploy + rollback verification. The acceptance bar is “a representative project builds, tests, and deploys end-to-end on the new platform.”
Keeping releases flowing during the switch
Pilot one representative project first to validate the full pipeline shape, and keep both platforms running during transition so a broken pipeline never blocks releases.
Use the TCO calculator to model a per-seat comparison.