How do you migrate an existing deployment pipeline to GitOps?

Migrating to GitOps is not a big-bang cutover — it works best as a phased process where the old pipeline and the GitOps operator run in parallel until confidence is established, then the old pipeline is decommissioned.

Step-by-step migration:

1. Capture current state as declarative YAML: Export live Kubernetes resources with kubectl get all,configmap,secret,ingress -o yaml. Strip ephemeral fields (status, resourceVersion, uid, managed fields). This becomes your starting commit.
2. Create the config repository: Organise manifests into an app folder structure with base + overlays (or Helm chart + values files). Commit the cleaned-up YAML. Add secrets using SOPS or Sealed Secrets before committing.
3. Install the GitOps operator: Install Argo CD or Flux in the cluster. Keep the operator in dry-run or manual-sync mode initially.
4. Connect operator to config repo: Create an Application or Kustomization CR pointing to the new config repo.
5. Validate with dry-run: Confirm the operator produces manifests identical to what is currently running. Fix discrepancies in the config repo.
6. Enable sync — manual first, then automated: Switch to manual sync. Run a few syncs from the UI or CLI. Observe. Then enable automated sync with prune: false initially (no deletions yet).
7. Update CI to write to the config repo instead of kubectl:

# Replace: kubectl set image deployment/my-app my-app=${IMAGE}
# With: update the image tag in the config repo and push
- name: Promote image to config repo
  run: |
    cd gitops-config
    kustomize edit set image my-app=registry.example.com/my-app:${IMAGE_TAG}
    git add apps/my-app/overlays/prod/kustomization.yaml
    git commit -m "chore(cd): promote my-app ${IMAGE_TAG} to prod"
    git push origin main

8. Revoke direct cluster write access: Remove kubeconfig from the CI system. Update RBAC to deny write access to any service account not owned by the GitOps operator.
9. Enable prune: Once the team is comfortable, enable prune: true so deleted manifests are removed from the cluster.