Showcase: My dashboard comparing build times before/after migration for 20 services.

Alright, let's settle this. Everyone's got opinions on CI/CD migrations, usually about "developer experience" or "ecosystem synergy" or whatever buzzword is floating around this week. I don't trust feelings. I trust milliseconds and dollars.

So when the directive came down from on high to move our 20-odd service pipelines from TeamCity to GitHub Actions, my team groaned. Another "modernization" project. I decided if we were going to waste engineering cycles on this, we were at least going to measure *everything*. Built a simple dashboard to track the only metrics that matter: build duration, queue time, and compute cost per pipeline, before and after the cutover.

The setup was straightforward, if tedious. A scrappy Postgres table to store timestamped pipeline run data, scraped from both platforms' APIs. A couple of views to normalize the data. Grafana on top. The real pain wasn't the dashboard—it was the translation.

Here's a taste of what "pipeline translation" actually meant. Taking a declarative, mature TeamCity configuration and turning it into a YAML soup of `actions/checkout@v4` and third-party actions that might break tomorrow.

**TeamCity (The sane way):**
```kotlin
steps {
script {
name = "Build and Test"
scriptContent = """
docker build -t myapp:${build.number} .
docker run --rm myapp:${build.number} pytest /app/tests
""".trimIndent()
}
dockerCommand {
name = "Push"
commandType = push {
namesAndTags = "myregistry.com/myapp:${build.number}"
}
}
}
```

**GitHub Actions (The YAML carnival):**
```yaml
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build and Test
run: |
docker build -t myapp:${{ github.run_number }} .
docker run --rm myapp:${{ github.run_number }} pytest /app/tests
- name: Push to Registry
uses: docker/build-push-action@v5
with:
push: true
tags: myregistry.com/myapp:${{ github.run_number }}
```

Looks simpler? Wait until you need to manage shared secrets across 20 repos, or implement a coherent rollback strategy, or debug why your job is stuck in queue for 10 minutes because the `ubuntu-latest` runner is oversubscribed.

The results after a month of running both systems in parallel? Inconclusive, which is its own kind of result. For 14 of the 20 services, the average build time was within +/- 5%. Three got slower (mostly due to colder caches and longer queue times on the GitHub runners). Three got faster (lightweight Node.js services that benefited from the simpler setup). The real cost delta was in the ops overhead—managing our own TeamCity agents versus paying for GitHub's minutes.

The moral of the story isn't that one platform is better. It's that a migration like this is rarely about performance. It's about consolidating the vendor list, or following the herd, or making a manager's slide deck look good. If you're going to do it, at least measure the actual impact. Otherwise, you're just trading one set of quirks for another, newer, shinier set.

Dashboard snippet for the curious: simple table with service name, 7-day avg build time (old), 7-day avg build time (new), delta, and delta percentage. The most dramatic change was a 12% increase for our monolithic API service. Took us a week to tune the caching strategy to get it back to baseline.

-- old salt