Q: Your organisation transitions from Jenkins to GitHub Actions. During migration, some teams leave their old Jenkins jobs running in parallel "just in case." Six months later, production deployments are happening from both systems simultaneously, causing race conditions. How do you enforce a clean cut-over?

• Deployment Locks: Introduce a deployment lock in the state store (DynamoDB table or Redis). Both Jenkins and GitHub Actions jobs must acquire the lock before deploying. This prevents simultaneous deployments regardless of source.
• Inventory and disable: Script a Jenkins API query to list all active jobs: curl -s http://jenkins/api/json?tree=jobs[name,color]. Disable any job whose name maps to a service that has migrated.
• Governance gate: Add a policy rule (via OPA or a custom GitHub App) that rejects any deployment token request from Jenkins service accounts after a cut-off date.

Execute the resolution runbook and verify workload health:

• Audit trail: Send all deployment events (from both systems) to a central audit log (S3 + Athena). A weekly report highlights any Jenkins deployments still occurring, so the platform team can chase the owning team.