After five years of running TeamCity for our primary CI/CD platform, I've hit a point of critical assessment. The initial setup was pragmatic for its time—on-premise, deep integration with our then-monolithic .NET core applications, and a perceived sense of control. However, the operational overhead and evolving ecosystem are forcing a hard look at alternatives. This isn't a theoretical "cloud is better" post; it's a breakdown of tangible friction points and a request for migration war stories from those who've made the jump.
Our current pain is measurable and impacts velocity:
* **Agent Management Hell:** Maintaining a fleet of static, on-premise build agents for multiple Windows and Linux project types. The manual provisioning, scaling, and patching cycle is a constant tax. We've scripted some of it with Ansible, but it's a band-aid.
* **Pipeline as Code Deficiency:** While TeamCity supports Kotlin DSL, it's a second-class citizen compared to the native UI config. Versioning is clunky, and the mental context switch between the UI and the DSL for troubleshooting is a productivity drain. Our pipeline logic is trapped.
* **Observability & Debugging:** The logging and traceability for complex, multi-stage pipelines are subpar. Pinpointing why a specific step failed in a matrix build often involves digging through verbose agent logs manually. Our SREs complain about the lack of clean, aggregatable metrics on pipeline health.
* **Container & Kubernetes Native Workflows:** Pushing images and deploying to our K8s clusters feels bolted-on. We have a series of brittle PowerShell scripts calling `kubectl` that are becoming a security and maintenance concern.
I'm evaluating a move to a cloud-native platform (likely GitLab CI or GitHub Actions, given our source hosting) but the migration cost is non-trivial. My specific questions for those who've done this:
1. **Pipeline Translation:** How did you handle the conversion of hundreds of build configurations? Did you use a translator tool, or was it a manual rewrite? What was the biggest syntax/logic gap you encountered?
* Example: TeamCity's snapshot dependencies and artifact dependencies are a specific paradigm. How did you map this to another system's artifact/upstream job model?
2. **Secrets Migration:** TeamCity has its own credential system. Migrating these securely, without manual re-entry, is a major concern. Did you integrate with a vault (HashiCorp, Azure Key Vault) first, or did you use the target platform's secret store as the migration target?
3. **Timeline & Team Enablement:** Realistically, how long did a phased migration for, say, 200+ build configurations take? How did you train developers used to the TeamCity UI to work with pure `gitlab-ci.yml` or GitHub Workflows?
I'm not looking for vendor pitches. I want the unvarnished truth on the transition pain, the post-migration benefits you actually realized (or didn't), and any critical pitfalls we should architect around from day one.
-- as