This checklist turns CI/CD modernization into a series of evidence-backed release gates. Use it for a platform migration, a control uplift on an existing platform or consolidation of multiple delivery systems. Not every item applies equally to every workload, but every exclusion should have an owner and rationale. The implementation is ready only when teams can build, verify, deploy, observe and recover through the new path.
Record evidence beside each item: inventory export, architecture decision, threat model, test result, control mapping, service objective, runbook or approval. Use the companion CI/CD modernization FAQ for decision context and the CI/CD scope and delivery guide for estimating and migration planning.
Gate 0: define outcomes and governance
- Name the platform product owner, security owner, operations owner and application migration owners.
- Define workload risk tiers and the controls required for each tier.
- Baseline delivery measures at application or service level using stable definitions.
- Record reliability targets, release constraints, audit needs and retention requirements.
- Define platform support hours, incident ownership and change communication.
- Approve exception criteria, duration, compensating controls and review cadence.
- Set migration success, rollback and legacy decommission criteria before build.
Gate 1: inventory the current delivery estate
Discover the real release path, including manual steps. Scan repositories for pipeline definitions and reusable components, then interview representative teams to find local scripts, credentials, approvals and emergency processes. Classify repository archetypes by language, packaging, deployment target and risk rather than planning one migration per repository with no common pattern.
| Inventory object | Capture | Red flag |
|---|---|---|
| Repository | Owner, branch rules, contributors and sensitivity | No active owner or unrestricted pipeline changes |
| Runner | Hosting, tenancy, image, network and lifecycle | Persistent privileged worker shared with untrusted jobs |
| Credential | Issuer, scope, storage, rotation and usage | Long-lived production secret available during build |
| Dependency | Registry, version policy and update owner | Unpinned executable component |
| Artifact | Format, registry, retention and promotion | Production rebuild or mutable release tag |
| Deployment | Identity, approval, verification and recovery | Unlogged manual change with no tested rollback |
Gate 2: approve the target architecture and paved path
- Define versioned reusable workflow components and supported extension points.
- Separate trusted deployment workflows from untrusted build and pull-request execution.
- Select ephemeral or resettable runners and document isolation boundaries.
- Restrict network egress and internal reachability according to job purpose.
- Use short-lived workload identity and least-privilege token permissions where supported.
- Build once, publish an immutable artifact and promote the same object.
- Define artifact naming, retention, provenance, signing and verification policy.
- Protect central templates and roll out breaking changes through tested versions.
- Document the approved escape hatch for workloads the paved path cannot support.
Gate 3: protect source, workflows and dependencies
Require reviewed changes for protected branches and pipeline policy. Limit who can alter required checks or environments, and log exceptions. Pin executable third-party workflow components according to platform guidance, review their permissions and automate update proposals. Use approved registries and dependency policies. Define how urgent vulnerabilities are triaged, rebuilt and redeployed, including ownership outside normal business hours where required.
| Control test | Pass evidence | Failure response |
|---|---|---|
| Unauthorized workflow change | Protected review and audit event | Block merge and investigate access |
| Forked or external contribution | No protected secret or privileged runner exposure | Cancel job and rotate affected credentials |
| Dependency substitution | Approved source, pin and integrity verification | Quarantine build |
| Pipeline token misuse | Minimal permissions and short lifetime | Revoke token and inspect actions |
| Template update | Compatibility tests and canary cohort | Hold rollout and restore prior version |
| Emergency exception | Named approver, expiry and compensating control | Escalate overdue exception |
Gate 4: produce verifiable build evidence
Make builds deterministic enough for the required assurance and isolate them from unrelated tenants. Record source identity, builder identity, parameters, dependencies and resulting artifact. Generate provenance aligned with the chosen SLSA target and verify it before deployment. If artifacts are signed, protect the signing identity and test verification failure. Connect software inventory to vulnerability response rather than generating unused files.
- Use minimal, patched and versioned build images.
- Prevent builds from silently publishing mutable tags over released artifacts.
- Store test, scan and policy results with the release record.
- Redact secrets and sensitive values from logs and artifacts.
- Set artifact and log retention from recovery, audit and privacy needs.
- Verify that a failed test, scan or policy check cannot be bypassed without an audited exception.
- Trace a deployed version back to source commit, workflow and builder.
Gate 5: test deployment, observability and recovery
Automate environment promotion with controls proportionate to risk. Verify the artifact and its evidence at admission. Keep environment-specific configuration outside the built artifact and govern changes. Define progressive delivery or maintenance-window behavior where useful, but never assume a deployment technique replaces service-level monitoring. A pipeline success means little if users cannot complete the journey.
- Deploy the exact tested artifact to a production-like environment.
- Validate database and stateful changes with forward and recovery procedures.
- Test health checks against user-visible behavior, not process existence alone.
- Correlate deployment markers with application and infrastructure telemetry.
- Exercise rollback or roll-forward using an approved prior artifact.
- Test a failed deployment, partial rollout and unavailable dependency.
- Confirm operators can pause promotion without losing evidence.
- Verify break-glass access is controlled, logged and reviewed.
Gate 6: migrate a representative pilot
Choose a service representative of a larger cohort but with manageable business risk. Run old and new builds against the same source where practical, compare artifacts and test results, then deploy non-production through the new path. Resolve differences explicitly. Before production, complete access review, recovery rehearsal, support handoff and a return plan to the old release path if the new platform fails.
| Pilot decision | Evidence | Exit criterion |
|---|---|---|
| Functional parity | Tests and artifact comparison | Known differences accepted |
| Security | Threat model, access review and provenance verification | Required controls pass |
| Performance | Queue, build, test and deployment timings | Service objective met or tradeoff accepted |
| Recovery | Failed-release exercise | Operator completes approved procedure |
| Support | Runbook, alerts and escalation exercise | On-call owner accepts service |
| Developer use | Observed migration and structured feedback | Blocking friction resolved or documented |
Gate 7: expand by cohort and retire the old path
Migrate repositories with similar patterns together. Publish readiness criteria, templates, examples, office hours and a known-issues register. Track adoption without counting a repository as complete until production release and recovery have been proven. Roll template versions gradually and observe failures by cohort. Stop accepting new work on the legacy platform once the paved path covers it.
- Remove old webhooks and scheduled jobs after a monitored hold period.
- Revoke legacy credentials and runner access.
- Archive required pipeline logs and release evidence.
- Delete obsolete runner images, caches and artifact stores under policy.
- Close licenses and infrastructure only after consumer verification.
- Update service catalogs and operational documentation.
- Review temporary exceptions and assign a removal date.
Operate the platform as a product
Monitor platform availability, queue time, feedback time, flaky tests, failed jobs by cause, deployment verification, policy exceptions and support load. At application level, interpret DORA delivery measures with reliability and user outcomes. Do not rank individuals or teams from context-free metrics. Review component vulnerabilities, runner images, template versions, identity use and provider changes on a defined cadence.
Run a platform incident exercise before declaring broad availability. Simulate an unavailable control plane, compromised runner image or revoked identity provider. Confirm teams know whether to wait, use an approved emergency path or stop releases; verify that emergency activity remains attributable and is reviewed afterward. Capture recovery dependencies outside the CI/CD platform itself so a platform outage does not make its own runbook, credentials and evidence unreachable.
Key takeaways
- Base migration scope on a verified inventory of delivery identities and assets.
- Separate untrusted build execution from trusted artifact promotion.
- Require traceable, immutable artifacts and test verification failure paths.
- Pilot a representative service through release and recovery before cohort scale.
- Finish migration by revoking old access and retiring legacy infrastructure.
Frequently asked questions
Who should own the checklist?
The platform product owner coordinates it, but evidence belongs to application, security, operations and compliance owners. No single team should self-approve every control that governs its own privileged path.
How long should old and new pipelines run together?
Only long enough to establish required parity, release confidence and rollback readiness. The period depends on release frequency and risk. Set exit criteria and an end date so temporary dual operation does not become permanent cost.
Should flaky tests be migrated unchanged?
Record baseline behavior, then fix or quarantine them through an owned policy. Silent retries can conceal instability and waste capacity. A migration is a useful point to classify test reliability, but avoid turning it into an unbounded application rewrite.
When is a repository migration complete?
When the new path has produced and deployed a verified artifact, operators have tested recovery, required evidence is accessible, the service owner accepts support and the old path's credentials and triggers are removed.
Conclusion
A CI/CD implementation is ready when it can prove what source produced an artifact, which trusted system built it, why it was allowed to deploy and how the service will recover. Use the checklist to make those claims testable. Migrate in representative cohorts, learn from real releases and close the old path. That discipline turns pipeline modernization into a durable delivery capability rather than another layer of tooling.