Moving deployments into Argo CD from other GitOps tools, CI pipelines and Helm releases, and restructuring existing Argo CD installations.
Replacing Flux Kustomizations and HelmReleases with Argo CD Applications: mapping Flux objects to Applications and ApplicationSets, Helm values handling, avoiding two controllers reconciling the same resources, and cutover per namespace.
Splitting Jenkins pipelines so Jenkins builds and tests while Argo CD deploys from Git: replacing kubectl or helm steps with a commit to a config repository, image tag updates, webhooks for fast refresh, and keeping an audit trail.
Taking cluster credentials out of CI by replacing kubectl apply or helm upgrade steps in GitHub Actions or GitLab CI with GitOps: config repository layout, environment promotion by pull request, and webhook-driven refresh.
Replacing Azure Pipelines release stages that push to AKS with Argo CD pulling from Azure Repos: repository credentials and webhooks, AKS cluster access with workload identity, approvals moved to pull requests, and staged cutover.
Bringing charts installed with helm install under Argo CD without downtime: matching release names and instance labels, why helm list stops showing them, hook behavior after adoption, and removing the old Helm release records.
Switching a single-replica Argo CD that grew into production onto the HA manifests: node requirements, Redis HA, API server and controller replicas, sharding settings, and doing it without losing applications.
Relocating Argo CD to another cluster, for example during a Kubernetes platform change: exporting and importing settings, re-registering clusters and repositories, matching versions, and switching DNS without double reconciliation.
Merging per-team or per-cluster Argo CD instances into a shared multi-tenant installation: projects per team, Applications in any namespace, RBAC from SSO groups, controller sharding for many clusters, and the cutover order.
Moving custom manifest plugins defined in the argocd-cm ConfigMap, which no longer work after 2.8, to sidecar plugins: writing plugin.yaml, discovery rules, parameters, volumes and testing before upgrading.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.