How to migrate argocd-cm plugins to sidecar plugins before upgrading
If your team runs custom manifest plugins defined in the argocd-cm ConfigMap, those plugins stop working once Argo CD is upgraded to v2.8 or later, so each one must be rewritten as a sidecar plugin on argocd-repo-server and tested before the upgrade. Installing plugins through argocd-cm was deprecated in v2.4 and removed completely starting in v2.8, so the old definitions cannot be carried across the upgrade unchanged. Treat this as a dependency to resolve in the current version, not as an upgrade-day task. The effort depends on three things: how many plugins you run, how many parameters each one accepts, and how much each one depends on the repo-server environment. A plugin that renders a single chart from a fixed command with no parameters is a small rewrite. A plugin that reads files outside the repository, relies on tools baked into the stock repo-server image, or expects a particular tmp volume layout needs a custom sidecar image, volume design and more testing. Inventory every plugin first and record its command, its inputs and any tools or paths it touches. Confirm the exact v2.8 behavior for your Argo CD version against the official Config Management Plugins guide, since that guide governs the sidecar format you will write. Build a parallel test environment on the target version, register the sidecar plugins there, and render every affected Application from the same Git revision on both the old and new setups. Compare the generated manifests, not just whether the sync succeeds. Pay attention to plugin discovery rules, parameter defaults and anything that worked only because the repo-server could see a shared volume. Also keep the sidecar off the repo-server tmp volume, since the sidecar should not mount the same tmp volume as the repo-server to reduce path traversal risk. Only upgrade production once every plugin renders identically or the differences are understood and approved.
What maps cleanly from argocd-cm plugins to sidecar plugins
This table compares each part of an argocd-cm plugin with its sidecar equivalent and gives a migration note for each: what carries over, what moves into a separate container, and what to test again. Read it as a checklist while you rewrite each plugin, and note that the generate command usually survives largely intact while discovery and the runtime environment change.
| Element | Behavior in argocd-cm plugin | Migration note for sidecar plugin |
|---|---|---|
| Plugin name | Set under the name field in argocd-cm, which Applications reference through their plugin settings. | Carries over in concept, but the name is now defined in the plugin.yaml file inside the sidecar. Confirm that Applications still reference the same name after the change. |
| Generate command | Shell command run in the repo-server against the application source directory, printing manifests to stdout. | Usually moves largely intact into the sidecar's generate command. Check that every binary it calls is present in the sidecar image, because the repo-server image no longer provides them. |
| Discovery rules | Defined as a file or find pattern in argocd-cm that decides which applications the plugin claims. | Changes form. Discovery is written in plugin.yaml, and the sidecar must match the rule set exactly. Re-test every application to confirm it is still picked up by the intended plugin and no other. |
| Parameters | Declared in argocd-cm and passed to the command as environment variables or arguments set on the Application. | Declared in plugin.yaml and passed in the same way. Re-check default values and any parameter that expands into shell arguments, since quoting rules are easy to break when the command moves. |
| Runtime environment | Runs inside the repo-server container with the tools, environment variables and permissions that image provides. | Runs in a separate sidecar container with its own image, user, and environment. Install required tools, set needed variables, and confirm file permissions on the shared workspace. |
| Volumes and file access | Uses the repo-server's own working directories without extra mounts. | Requires explicit volume mounts. Do not mount the same tmp volume the repo-server uses, because the project recommends separation to reduce path traversal risk. Test that the plugin can read the source checkout and write output. |
| Credentials and secrets | Any credential the command needed was available through the repo-server environment. | Credentials must be supplied to the sidecar deliberately, through Kubernetes objects mounted only where needed. Review what the plugin can reach, since the sidecar's scope should be no wider than the job requires. |
| Upgrade behavior | Works until the argocd-cm mechanism was removed, which the project made in v2.8. | Check the plugin on a staging Argo CD at the target version before the production upgrade, and confirm that the plugin still renders the same manifests for a representative set of applications. |
The four parts of a sidecar plugin to rewrite
Each argocd-cm plugin entry carried its behavior in one block of YAML. A sidecar plugin splits that behavior across four parts, and each one must be rebuilt and checked before the upgrade. Inventory the old entry field by field so nothing it did implicitly is lost in the move.
The plugin.yaml definition
This file names the plugin and sets the commands Argo CD runs to generate manifests, which replace the command and args you used to put in argocd-cm. Start by copying every command from the old entry, including any shell pipes, environment setup and output redirection, because the sidecar runs in its own container and inherits none of the repo-server's tools. The most common breakage is a command that works on the repo-server image but is missing from the plugin image. Check exact keys and structure against the Config Management Plugins guide before writing the file.
Discovery rules for Applications
Discovery decides which Applications the plugin handles. In argocd-cm, teams often relied on a plugin name in the Application spec, but the sidecar version uses discovery criteria that Argo CD checks against repository content. Inventory the file patterns, directories and marker files the old entry depended on, and confirm which Applications used it by name. The most common breakage is discovery that matches too broadly and captures Applications that were previously handled by Helm or Kustomize, or too narrowly and leaves some Applications with no generator at all.
Parameters users can set
Parameters let Application authors pass values into the plugin without editing its command. Many argocd-cm plugins used environment variables or hand-built flags that teams set in each Application, so list every variable the old command read and decide which ones become declared parameters. The most common breakage is a parameter renamed during the move, which silently leaves Applications running with the default value. Confirm the parameter syntax and naming rules in the guide, and test each Application that sets one.
Volumes for tools, credentials and caches
The sidecar needs its own volumes for anything the plugin reads or writes, such as binaries, credential files, shared caches or generated output. Since v2.4, the sidecar should not mount the same tmp volume as the repo-server, which reduces path traversal risk, so any data passed between the two must go through a different path that you design. Inventory every file path, secret and cache the old entry used. The most common breakage is a plugin that worked because it shared the repo-server's temp directory and now fails with a missing file.
Credentials the plugin needs
Old plugins often read tokens or keys from the repo-server environment or from files the repo-server already mounted. In the sidecar model, those secrets must be mounted into the plugin container explicitly, with only the access the plugin needs. Record each credential the old command used, where it came from and who rotates it. The most common breakage is a secret mounted to the repo-server but not to the sidecar, which produces an authentication failure that looks like an upstream outage.
Why the plugin sidecar must not share the repo-server tmp volume
The plugin sidecar should mount its own volume, not the tmp volume that argocd-repo-server uses. Since v2.4, the Argo CD guidance has been that a sidecar should not mount the same tmp volume as the repo-server, because sharing it widens the path traversal risk. During manifest generation, the repo-server places checked-out repository content and intermediate files in that tmp space and then runs the tool against them. Anything written there is input to the next step, so the volume is effectively a staging area for untrusted files.
The risk comes from reach. If a plugin container can read and write the same paths as the repo-server, a crafted repository or a plugin command that follows a relative or symbolic path can touch files that belong to other applications, or to the repo-server's own working state. Separate mounts limit each container to the paths you give it. Treat every plugin command with the same scrutiny you already give Helm and Kustomize, which the security documentation flags as running on repository content. Review what each generate command reads, what it writes, and whether it executes anything fetched from the repository.
Before go-live, confirm the separation in the running cluster rather than only in the manifest you wrote. Inspect the Deployment of argocd-repo-server and check that the volumeMounts for the plugin sidecar reference a volume name that the repo-server does not also mount at the same path. Then run a test application whose repository contains a path traversal attempt, and confirm the plugin cannot read files outside its working directory. Ask your platform team to record this check in the change ticket, because it is the evidence an auditor or security reviewer will ask for.
Documented paths for converting a plugin
Plugins that run one command against the manifests in the repository, such as a templating tool that reads files and prints YAML, usually map most directly to a sidecar plugin. The official Config Management Plugins guide describes the sidecar layout: a container running next to argocd-repo-server, a plugin.yaml file that names the plugin and sets its discovery rules, and a command that writes manifests to standard output. Start by copying the existing argocd-cm entry's generate command into the sidecar's plugin.yaml, then rewrite any reference to paths that the old setup assumed.
- Discovery rules: Replace the old file match with a discovery
findorfileNamerule so Argo CD selects the plugin only for the intended directories. - Parameters: Convert environment-variable inputs from the old entry into declared parameters, and check each Application's values still resolve.
- Working directory: Confirm the command reads from the sidecar's working directory and never from paths outside the repository checkout.
- Volumes: Since v2.4 the sidecar should not mount the same tmp volume as the repo-server, so use a separate volume for any scratch space.
- Output comparison: Render the same Application with the old and new plugin and diff the manifests before cutover.
This path rarely needs a partner. Check that the rendered manifests match exactly, because a small change in output can cause unexpected drift in production.
Some plugins call external tools, fetch secrets, or contact internal services during manifest generation. These need the sidecar to carry its own binaries, a container image you build and maintain, and credentials supplied through Kubernetes objects. The guide covers how to define the sidecar container in the repo-server pod spec, and the upgrade notes for your target release describe how the repo-server is configured. Because the repo-server runs plugins on repository content, anything the sidecar can reach is reachable from any repository that Argo CD is allowed to read, so credential scope matters.
- Image ownership: Decide who builds, scans and patches the sidecar image, and pin tool versions so output does not change silently.
- Credential scope: Mount only the secrets the plugin needs, with the narrowest service account possible.
- Network reach: Restrict egress from the repo-server pod to the endpoints the plugin requires.
- Secret handling: Keep secret values out of rendered manifests that Argo CD caches, and confirm the approach against the secrets guidance in your planning.
- Failure behavior: Test what happens when the external service is unavailable, since Application sync will show a generation error.
Bring in a partner when the plugin touches several external systems or when the sidecar must pass a security review, because the trust boundary changes with each added credential.
Many argocd-cm plugins existed because Argo CD did not yet support a particular template or transformation. Before writing a sidecar, check whether a built-in tool already produces the same manifests. Argo CD supports Helm and Kustomize natively, and a replacement often means moving logic into chart values, Kustomize overlays, or plain YAML in Git. This path removes the plugin entirely, which also removes a container to maintain. Compare the outputs carefully, since a built-in tool may render resources in a different order or with different defaults.
- Feature mapping: List what the plugin does step by step and find the built-in equivalent for each step.
- Value migration: Move hard-coded or environment-specific settings into Helm values or Kustomize overlays.
- Output parity: Compare rendered manifests for every environment, not only one.
- Team ownership: Record who will maintain the new chart or overlays after the plugin is gone.
- Rollback: Keep the old plugin definition available in Git until the upgrade is verified.
Ask for a partner review when the plugin encodes business rules that are not documented anywhere, because reproducing those rules is the main risk in this path.
Whichever path applies, the conversion should be proven in a non-production Argo CD instance running the target release before the production upgrade. The Config Management Plugins guide and the 2.14 to 3.0 upgrade notes describe the changes that affect plugin behavior and RBAC, so read the notes for every major version you cross. Test on a copy of real Applications where possible, using sanitized data if the repository contains sensitive values. Record the rendered output from the old plugin on the current version as the baseline for comparison.
- Staging instance: Install the target version with the new sidecar and point test Applications at it.
- Baseline capture: Save the old rendered manifests for each Application before any change.
- Negative tests: Confirm that repositories outside the discovery rules are not picked up by the plugin.
- Access checks: Verify that RBAC for sync and logs behaves as the upgrade notes describe.
- Runbook: Document the rollback steps and who approves the production change.
Confirm exact version requirements with the official documentation and your own test results rather than relying on this summary, and ask a partner to review the test plan if the plugin is business critical.
Sequence from plugin inventory to decommissioning the argocd-cm entries
This sequence moves each custom plugin from argocd-cm to a sidecar plugin in a controlled order, so every Application is proven on the new plugin before the production upgrade and the old entries are removed.
Inventory plugins and dependent Applications
Export the argocd-cm ConfigMap from each Argo CD instance and list every plugin entry, its name, its discovery rules and the tools it calls, such as the binary and version baked into the image it runs. Then query each Application for the plugin name it uses through spec.source.plugin, and record the owning team, the cluster and the repository. The step is done when every argocd-cm plugin has a named owner and a list of Applications that use it, including Applications that are not yet synced. Keep this inventory in version control so later steps can compare against it.
Rewrite each plugin as a sidecar plugin
For each inventoried plugin, write a plugin.yaml with the same name, discovery rules and generate commands, then package the tooling in a sidecar container that runs alongside argocd-repo-server. Confirm the sidecar does not mount the same tmp volume as the repo-server, since that mount increases path traversal risk. Deploy the change to a non-production Argo CD only, and keep the argocd-cm entry in place there until the new plugin passes testing. The output is a versioned sidecar manifest per plugin that the team can review in a pull request.
Test discovery and parameters against real Applications
Point a copy of each dependent Application at the sidecar plugin in the non-production instance and render its manifests. Check that discovery matches the intended repository paths, that every parameter declared in plugin.yaml is passed correctly, and that the rendered output matches the output from the old plugin for the same commit. Record any differences and fix them in the sidecar before moving on. The step is done when rendered manifests are identical or every difference is explained and approved by the owning team.
Rehearse the upgrade in staging with both plugins
In a staging Argo CD that mirrors production's version and configuration, run the old argocd-cm plugin and the new sidecar plugin side by side, so each Application can be rendered with either one. Run the full upgrade path in this environment, including the version changes listed in the official upgrade notes, and confirm that Applications still using the old plugin fail in a predictable way that your checks will catch. Write down the exact rollback commands for this staging rehearsal, such as restoring the previous image and ConfigMap. The output is a rehearsal log that the change board can review.
Cut over Applications to the sidecar plugin
Change each Application's plugin reference from the argocd-cm plugin to the sidecar plugin in batches, starting with the least critical Applications. After each batch, compare sync status, rendered manifests and health with the pre-change baseline recorded in step one. Keep the argocd-cm entry in place while any batch is still being observed. Rollback for this phase is to revert the Application's source definition in Git, which Argo CD will apply on its next sync. The step is done when every inventoried Application renders correctly on the sidecar plugin.
Confirm no Application depends on argocd-cm plugins
Before the production upgrade, rerun the inventory query across every Argo CD instance and confirm that no Application, ApplicationSet template or pending pull request still references an argocd-cm plugin name. Include Applications generated by ApplicationSets, because their templates can hide plugin references. Ask each owning team to sign off on their Applications in writing. The check passes when the query returns no references and the sign-offs are recorded. If any reference remains, stop the upgrade and return to the cutover step for that Application.
Upgrade the production instance
Upgrade the production Argo CD using the same version path rehearsed in staging, with the sidecar plugin deployed before the Argo CD version that removes argocd-cm plugins takes effect. Watch sync status and repo-server logs for each Application, and confirm that the sidecar is serving plugin requests. Keep the previous image tags and the saved configuration available until the upgrade is confirmed. Rollback at this point means reverting to the previous Argo CD version with the saved configuration, which is why the backup must be verified before the change window opens.
Remove the argocd-cm plugin entries
After production has run the sidecar plugins through its normal sync cycles, delete the plugin entries from the argocd-cm ConfigMap and remove any leftover plugin-related configuration, then commit that change to Git. Verify that a fresh render of each Application still succeeds and that no errors reference a missing plugin in the controller or repo-server logs. Archive the inventory, the rehearsal log and the sign-offs with the change record. The step is done when the ConfigMap contains no plugin definitions and the archived evidence is complete.
What drives the cost and duration of a plugin migration
This table lists the factors that raise or lower the effort of moving argocd-cm plugins to sidecar plugins, who typically pays for each piece of work, and what to request in a written quote. Read it before comparing estimates, because two plugins that look alike can differ widely in effort once parameters, tooling and test coverage are counted.
| Driver | Why it changes effort | Who pays and what to ask for in a quote |
|---|---|---|
| Number of plugins and Applications per plugin | Each plugin needs its own plugin.yaml, discovery rule and sidecar entry, and every Application that references it must be checked for the new plugin name and parameter format. | Both. Internal staff usually inventory Applications; a partner typically quotes per plugin. Ask for a list of plugins with the Application count for each. |
| Number and complexity of parameters | Parameters defined in the old ConfigMap must be re-expressed in the sidecar's parameter schema, and any Applications passing values through the old format must be updated. | Partner work, one-time. Ask how each parameter maps to the new format and which Application manifests will change. |
| Extra tools, credentials or volumes in the sidecar | Binaries such as helm, kustomize or custom CLIs must be packaged into the sidecar image, and any secrets or config files must be mounted without sharing the repo-server tmp volume. | Both. Platform staff own image builds and registries; a partner handles the sidecar design. Ask who maintains the image after handover. |
| Discovery rules and manifest generation behavior | Discovery decides which Applications the plugin claims, so ambiguous file patterns cause wrong renders and extra debugging time. | Partner work, one-time, with ongoing review when repositories change. Ask for the discovery rule per plugin and the test repositories used to verify it. |
| Number of environments and clusters | Each environment needs its own validation pass, and differences in cluster Argo CD versions or repo-server images can change plugin behavior. | Both. Ask whether the quote covers staging validation and how many environments are in scope. |
| Existing test coverage | Plugins with saved expected manifests or a staging copy of Argo CD can be compared before cutover. Without them, comparison is manual and slower. | Usually internal staff supply sample applications and expected output. Ask whether the quote includes building new test fixtures. |
| Change control and approvals | Regulated teams may need change tickets, peer review of plugin definitions, and evidence of pre-upgrade testing, which adds steps to every change. | Internal staff for approvals; partner for documentation. Ask which artifacts the partner delivers and whether they are kept in Git. |
| Ongoing maintenance of plugin definitions | Plugin images and tool versions need updates, and Argo CD upgrades may require checks against plugin behavior, which recurs after go-live. | Recurring. Decide whether internal staff or a retainer covers updates. Ask what support window and upgrade checks the quote includes. |
What usually goes wrong during a plugin migration and how to prevent it
Most failed plugin migrations share a cause: the cluster changed before the team could prove the rendered output stayed the same. The cards below cover the risks that tend to surface during an argocd-cm plugin move, with a prevention step and a check for each.
Upgrading before every plugin is replaced
Argo CD removed argocd-cm plugin definitions starting in v2.8, so an upgrade past that point leaves any unmigrated Application without a working generator. Inventory every Application that references a plugin by name before scheduling the upgrade, and keep a list of which plugins have a sidecar replacement. Check that the inventory and the replacement list match before the upgrade window opens. Any Application still pointing at an old plugin name is a blocker, not a warning.
Silent drift from discovery rules
A sidecar plugin is chosen by its discovery rules, so a broad or overlapping pattern can capture Applications that previously rendered with a different tool. Write discovery narrowly, using the files that identify each source type, and document which plugin wins when two match. Check each Application's rendered manifest against the value from before the change, not just whether sync succeeds, because a successful sync can still apply the wrong output.
Dependencies that exist only in the old pod
Old plugin commands often call binaries, helper scripts or cached files that were baked into the repo-server image or mounted there by hand. The sidecar starts from its own image, so those tools are missing and the render fails or falls back to a different path. List every binary and file each plugin command uses, then package them in the sidecar image or a mounted volume. Check by running each plugin command inside the sidecar container with an empty cache.
Sidecar sharing the repo-server tmp volume
Since v2.4, the plugin sidecar should not mount the same tmp volume as the repo-server, because a shared path makes path traversal between the two containers easier. Teams copying an old repo-server pod spec often carry this mount across unchanged. Give the sidecar its own volume and mount only the paths its plugin needs. Check the rendered Deployment for any volume that appears in both the repo-server and the sidecar.
Credentials leaking into plugin output
Plugins that read repository or cluster credentials from the environment, or that echo debug output, can place secrets into manifests or container logs. Argo CD redacts its own credentials from API responses and logs, but a plugin's custom output is outside that protection. Pass only the variables a plugin needs, avoid verbose flags in generate commands, and keep secret values out of rendered manifests. Check the sidecar logs and a rendered manifest for any token, password or key string after a test sync.
No parallel run to compare output
Without a comparison run, the first sign of a rendering change is often a production drift alert. Render every migrated Application with the old plugin and the new sidecar on a staging copy of the cluster, then diff the manifests object by object. Record the diff for each Application in the change ticket so reviewers can approve differences explicitly. Check that every Application has a zero-diff result or a signed-off exception before the production upgrade.
Questions teams ask before migrating argocd-cm plugins
How long does migrating argocd-cm plugins to sidecar plugins take?
The duration depends on how many plugins you run, how much logic each one contains, and how many Applications depend on them. Plugins that only wrap a simple render command usually take less work than plugins that fetch secrets, generate manifests from several inputs, or rely on parameters that teams set in the Application spec. Count each plugin, its discovery rule, its parameters and its volume needs, then compare rendered output for every Application that uses it. Ask any partner to base the timeline on that inventory and to state which Applications and environments are in the written scope.
Can our own team move plugins to sidecars without outside help?
Yes, if your team already runs Argo CD in production and has someone comfortable with Kubernetes Deployments, ConfigMaps and container images. The work is mostly writing a plugin.yaml, defining discovery rules and parameters, adding the sidecar container and volumes to the repo-server, and rendering manifests to compare results. The harder part is usually finding every Application that touches a plugin and agreeing on a test plan with the application teams. Outside help is most useful when the plugins are old, undocumented or tied to secrets handling, or when the change must happen before a fixed upgrade date.
What do the platform and application teams need to provide?
The platform team owns the repo-server, the sidecar image, its volumes and the change to the Argo CD configuration, so it must be able to edit the Argo CD installation and test in a non-production cluster. Application teams need to confirm which plugin each of their Applications uses, which parameters they set, and what the expected output looks like. Both teams should agree who signs off on rendered-output comparisons and who can roll back a plugin change. Write these responsibilities down before work starts so that no plugin is left without an owner after cutover.
Is there an automated importer that converts argocd-cm plugins?
Confirm this with the Argo CD project documentation for the version you run before assuming a tool exists, because the official guide describes the sidecar pattern and the manual steps to define it. Any conversion is therefore likely to be partial: a plugin's shell command and its discovery logic can often be carried over, but parameters, environment variables and file access need review. Treat any script you find as a starting point and check its output against the rendered manifests produced by the original plugin.
What happens if we upgrade Argo CD before migrating the plugins?
Installing Config Management Plugins through the argocd-cm ConfigMap was deprecated in v2.4 and completely removed starting in v2.8, so a plugin defined only there stops working once you move to v2.8 or later. Applications that depend on it can fail to render, which blocks syncs and may stall releases. The safer order is to build and test the sidecar plugins on the current version first, confirm rendered output matches, and then upgrade. Also check the release cadence: Argo CD ships a minor release every three months and only the three most recent minors receive patches, so waiting too long can leave you on an unsupported line.
How do we test that rendered manifests match after the change?
Render every affected Application with the old argocd-cm plugin and with the new sidecar plugin, then compare the output with a diff tool and review any difference before merging. Run the same comparison for each parameter combination and each environment, because a plugin often behaves differently when a parameter is missing. Add a non-production Argo CD instance that runs the same version and sidecar configuration as production, and check that the sidecar cannot read files from the repo-server tmp volume, since the plugin guide advises against mounting that volume. Keep the comparison results as change evidence.
What does a fixed-scope engagement from DeployOpen cover?
A fixed-scope engagement covers the plugins, Applications, clusters and environments named in a written scope, with deliverables and timelines agreed before work starts. Typical deliverables for this topic include the inventory, the plugin.yaml and discovery rules for each plugin, the sidecar and volume configuration, rendered-output comparisons, and a cutover and rollback plan. It does not usually include changes to unrelated applications, work on the Argo CD upgrade itself beyond what the plugin move requires, or ongoing operations unless you add a retainer. Ask for the exclusions in writing so that the quote reflects the work you actually need.
How DeployOpen scopes and delivers a plugin migration
DeployOpen inventories each argocd-cm plugin, rebuilds it as a sidecar plugin with its own plugin.yaml, discovery rules and parameters, and proves it renders the same manifests before the Argo CD upgrade goes ahead. Engagements are fixed-scope, with the written scope and deliverables agreed before work starts.
How we scope
- The written scope lists every argocd-cm plugin, the applications that depend on it, and the target Argo CD version.
- We record each plugin's inputs, parameters, binaries, volumes and secrets so the sidecar rebuild has a clear baseline.
- Scope names who confirms rendered output, who approves the cutover window, and which environments count as acceptance.
How we build
- Each plugin becomes a sidecar with its own plugin.yaml, discovery rules and parameter definitions in the agreed repository.
- Volumes are set up so the plugin sidecar does not mount the repo-server tmp volume, reducing path traversal risk.
- Rendered manifests from the old and new plugins are compared per application in a non-production cluster before any upgrade.
How we hand over
- Deliverables include the plugin definitions, the Argo CD configuration changes, and a comparison record for each migrated application.
- Documentation explains how to add a parameter, change a discovery rule, and roll back a plugin change through Git.
- Handover includes a walkthrough with your platform team of the test results and the upgrade checklist for the target version.
How we support
- Ongoing support, upgrades and continuous testing of plugin changes are available as a retainer.
- Support can cover new plugins added after handover, so new tooling follows the sidecar pattern from the start.
- Confirm with your team which plugin owners will review changes and how Argo CD upgrade windows are scheduled before the engagement starts.
