Switching CI tools: a migration checklist

Before you start

Write down why you are moving: the wait, the bill, maintenance, or a platform change. It decides what "done" means.
Record a baseline of push-to-verdict time and cost (see how to benchmark).
List every workflow, job, runner label, secret, cache and required status check.
Check whether a smaller move solves it. If you are on GitHub Actions and the problem is speed, a runner layer such as Graphide CI changes runs-on and nothing else.

Within GitHub Actions: change runs-on labels only. Leave steps alone so the verdict means the same thing.
To GitHub Actions from CircleCI, GitLab, Jenkins and others: GitHub Actions Importer drafts workflows; review every step it marks as manual.
To another platform: rewrite job by job, keeping the same commands, so the difference you measure is the platform's.
Keep job names the same where branch protection requires them, or update the required checks in the same change.

Inventory secrets per repository, organization and environment. Note which jobs read which.
Prefer OpenID Connect to cloud providers over copying long-lived keys into a new system.
Recreate secrets with the narrowest scope, then rotate the old ones once the old system is off.
Check that build logs do not print secrets: on any CI, a printed secret is in the log.

Expect the first runs to be cold. Do not judge speed on them; record cold and warm runs separately.
Check cache keys still hash the right lockfiles, and that cache scoping (branch, repository) matches what you rely on.
Runner layers often keep actions/cache working unchanged; check the vendor's docs.

Match operating system, architecture and image. Jobs that need macOS, Windows or Arm may need to stay where they are.
Check tools your jobs assume are preinstalled on the old image.
For self-hosted runners, plan autoscaling and cleanup before the first busy day.
For public repositories in a GitHub organization, check runner group settings allow them.

Run old and new on the same commits for at least a week.
For each commit, compare the conclusion of every job. Any pass that was a fail is a blocker, whatever the speed.
Push a commit that breaks a test on purpose, and check that the new system fails it.
Compare test counts per run. If the new tool runs fewer tests, know the rule it uses and what it does when unsure.