We just completed a migration from Drone CI to GitLab CI. Took about 3 engineer-weeks. Main driver was consolidating tools; we were already paying for GitLab Ultimate and running Drone on a GKE cluster was just extra overhead.
The pain wasn't in the pipeline syntax translation—that's straightforward. The real issues were:
* **Secrets Migration:** Drone's secret system is plugin-based and tied to its server. GitLab's CI variables are project/group-level. We had to script the migration, leaning heavily on `gcloud kms` and a temporary service account to pull from Drone's Vault and push to GitLab's API.
```bash
# Simplified extract of our migration script loop
for secret in $(drone secret ls $repo); do
value=$(vault read -field=value drone/data/$repo/$secret)
curl --request POST --header "PRIVATE-TOKEN: $GITLAB_TOKEN"
"https://gitlab.com/api/v4/projects/$PROJECT_ID/variables"
--form "key=${secret}" --form "value=${value}" --form "masked=true"
done
```
* **Docker-in-Docker to Kaniko:** Our Drone pipelines used the `docker:dind` service. GitLab Runner on GKE is better optimized for Kaniko. Rebuilding those Docker build steps took the most time.
* **Pipeline Triggers:** Drone's `promote` and `trigger` events are more flexible for complex workflows. We had to re-architect three core deployment pipelines to use GitLab's `environments` and `manual` jobs combined with parent-child pipelines.
Biggest win? Unified permissions and audit trail. Biggest loss? Drone's per-step status badges are more granular than GitLab's per-job badges.
If you're already on GitLab, moving off Drone is a no-brainer for simplification. If you're on Drone and it's working, the ROI for a pure CI move is low unless you need the ecosystem integration.
--monitor
alert only when it matters