Migrate from Flux to Argo CD: what the move involves and how much effort it takes
A platform team running Flux on clusters it controls may want Argo CD's web UI, ApplicationSets for fleet rollouts, and RBAC tied to SSO groups. The move itself is mapping each Flux Kustomization and HelmRelease to an Argo CD Application (or to an ApplicationSet where the same pattern repeats across clusters or environments), then handing each namespace over in a controlled sequence. The effort is set mainly by how many Flux objects exist, how many of them depend on each other, and how much logic lives in Helm values files, value overlays and post-render patches. A small set of plain Kustomize overlays is a short exercise. A large estate with generated values, chart dependencies and per-cluster exceptions is a much larger one. Ask any partner for a written inventory of Flux objects and value sources before accepting a fixed scope, because that inventory is what the quote should be built from.
Flux and Argo CD are both released under the Apache License 2.0, so the licence does not block the move or add cost on either side. Neither project requires a vendor-side migration tool. The work is done by reading the existing Flux manifests, recreating equivalent Argo CD definitions in Git, and proving that each one renders the same resources before any cutover. Confirm with your team which Flux version and which Argo CD minor release you will target, because the Argo CD release cadence and the set of supported minor versions change over time. The Argo CD release process describes which minor versions receive patches, and that should drive the target version.
Recurring costs after the move are the same kind of cost you already carry for Flux: running the Argo CD control plane, keeping it patched, and maintaining the Git repository layout. One-time costs are the inventory, the translation of manifests, parallel verification, and the cutover itself. Ask a partner to separate these in the quote, and to state who performs the verification in each target namespace and who signs off that the old Flux objects were removed. If a partner cannot describe how they would confirm that no resource is claimed by two controllers during the transition, treat that as a scoping gap, not a detail to settle later.
Which Flux objects map cleanly to Argo CD and which need redesign
This table compares the Flux objects and behaviors you are most likely to migrate with their closest Argo CD counterparts. Read the third column first, since it marks which mappings translate directly and which need a design decision before cutover. The main takeaway is that sources and charts translate with modest changes, while postBuild substitution, valuesFrom, dependsOn ordering and RBAC impersonation need decisions made before any namespace moves.
| Flux object or behavior | Argo CD counterpart | Mapping and decision needed |
|---|---|---|
| GitRepository and OCIRepository | Application source (repoURL, targetRevision, path) plus repository Secret | Git sources map cleanly. Repository credentials must be Kubernetes Secrets since Argo CD 3.0. Confirm OCI source support for your target version. |
| HelmRepository and HelmRelease | Application with a Helm chart source and values | Maps with changes. Release names and instance labels differ, so existing Helm-managed resources need an adoption plan before Argo CD syncs them. |
| Kustomization path and prune | Application path with automated sync, prune and self-heal options | Maps cleanly for plain manifests and overlays. Confirm prune and health behavior per resource kind in a staging run. |
| Kustomization postBuild substitution | No direct equivalent. Use Kustomize overlays, Helm values or an approved plugin | Design decision. Plugins run on the repo-server against repository content, so review any plugin against the security documentation first. |
| HelmRelease valuesFrom | Helm valueFiles, parameters or per-cluster values in an ApplicationSet | Design decision. Move secret-bearing values out of Git and confirm how the Argo CD version you target merges value sources. |
| dependsOn ordering | Sync waves and sync phases on resources, or parent Applications that order child Applications | Design decision. Ordering across Applications behaves differently from Flux, so test the sequence in a non-production cluster. |
| Flux RBAC impersonation (serviceAccountName) | AppProject destination and source limits plus RBAC from SSO groups | Design decision. Map each Flux service account to a project boundary and an SSO-backed role during planning. |
| Repeated Kustomizations per cluster or tenant | ApplicationSet with cluster, Git or other generators | Design decision. Choose generators from your cluster inventory and naming model before writing any ApplicationSet. |
| Flux and Argo CD managing the same resources | No equivalent. Two controllers must not reconcile one resource | Design decision. Assign each namespace to one controller at a time and suspend Flux reconciliation before Argo CD takes it over. |
Documented paths for moving Flux objects into Argo CD
Moving from Flux to Argo CD is mostly a translation exercise: each Flux Kustomization or HelmRelease becomes an Argo CD Application or ApplicationSet. The cards below cover the options for writing or generating those objects, the sources they point to, and what to export from the running Flux installation before anything changes. No automatic converter is assumed here, so confirm any tooling against the current Argo CD and Flux documentation before relying on it.
Hand-written Application manifests
An Argo CD Application is a Kubernetes object that names a Git source, a path and a destination cluster and namespace. For each Flux Kustomization, a team can write one Application that points at the same path and branch, then compare the rendered output against what Flux currently applies. This path gives the most control over naming, sync policy and project assignment, and it works well for a small number of workloads. Check that the destination namespace and project match the Flux object exactly before the first sync.
Generated ApplicationSet manifests
An ApplicationSet produces many Applications from one template, using generators over clusters, Git directories or lists. Teams with many Flux Kustomizations that follow the same directory layout can express them once and let the generator create the Applications. Because one template change affects every generated Application, review the generator output before enabling automated sync. Confirm which generator fits your directory and cluster layout in the ApplicationSet documentation.
Argo CD CLI and API
The argocd CLI and the Argo CD API can create Applications, set sync options and trigger syncs from a script. This suits repeatable migrations where each namespace is cut over with the same steps, and it leaves a command history for review. Scripts that run the CLI need credentials with the right project and application permissions, so issue a scoped token rather than reusing an administrator login. Test the script against a non-production cluster first.
Helm chart sources in Applications
Flux HelmReleases reference a chart from a HelmRepository or an OCI registry, with values supplied inline or from ConfigMaps and Secrets. An Argo CD Application can point directly at a Helm chart repository or OCI chart, and the values can come from files in Git or from parameters. Map each valuesFrom entry to a Helm values file in Git, and keep secret values out of Git by pointing to a secret management approach. Compare rendered manifests before and after to confirm that the values were carried over without drift.
Kustomize overlays in Git
Flux Kustomizations usually reference a Kustomize overlay path in a Git repository, and Argo CD can read the same overlay directly. Keeping the existing overlay structure avoids rewriting manifests during the migration and makes the diff easy to review. Confirm that the overlay does not depend on Flux-specific variables such as postBuild substitutions, because Argo CD will not substitute those values unless they are supplied another way. Note any patch that targets Flux controller objects so it can be removed or retargeted.
Exporting Flux objects and sources
Before writing any Argo CD object, export the live Flux state with kubectl get for Kustomization, HelmRelease, GitRepository, HelmRepository and OCIRepository objects across the namespaces in scope. Record the source URL, branch or tag, path, interval, target namespace and any dependsOn ordering for each one. The Git repositories that hold the manifests are the authoritative source, so confirm that they match what the cluster is running. Store the exported files with the migration plan so reviewers can trace every Application back to a Flux object.
How to sequence the cutover so Flux and Argo CD never reconcile the same resources
This sequence moves one namespace at a time from Flux to Argo CD, so that at every point exactly one controller owns each resource. Each step closes with a check that confirms ownership before the next step starts.
Inventory Flux objects and the resources they own
List every Flux Kustomization, HelmRelease, GitRepository, HelmRepository and notification or image automation object in the target cluster, and record the namespace, source path, chart version and values reference for each. Then list the resources each one manages, using the inventory labels and the owner references Flux writes on applied objects. The platform team completes this with read access to the cluster, and the output is a spreadsheet or config file mapping each Flux object to its managed resources. The check is that every namespace in scope has a complete list, and that no managed resource is missing an owner.
Choose and prepare a pilot namespace
Pick one low-risk namespace with a single Flux Kustomization or HelmRelease and no cross-namespace dependencies. Confirm with the application owner that a short period of manual change freeze is acceptable and that rollback steps are understood. Record the Git repository and path that Argo CD will read, and confirm that Argo CD can access it with a read-only credential. The check is that the pilot's manifests render identically from the Argo CD repo-server path and from the Flux source path, which you can compare with a dry run diff.
Create Argo CD Applications with auto-sync disabled
Define an Argo CD Application for the pilot namespace, using a dedicated AppProject that limits the destination namespace and the resource kinds allowed. Leave automated sync off so Argo CD only reports differences and never applies them on its own. Use a Helm values file or inline values that match the HelmRelease values exactly, and check which tracking method is in effect, since annotation-based tracking is the default in Argo CD 3.0 and later. The check is that the Application shows the expected resources in the Compare view, and the diff against live state is empty or limited to fields Flux manages.
Suspend Flux reconciliation before Argo CD takes ownership
Suspend the Flux Kustomization or HelmRelease for the pilot namespace so Flux stops applying changes, and confirm that its source objects are also suspended if they would trigger new reconciliation. Do this in a single change window so there is no time in which both controllers can write. The platform engineer runs the suspend command and records the time and the Flux object names. The check is that the suspended object reports a suspended status and that no new reconciliation events appear for it in the controller logs during a short observation period.
Run a parallel drift check before enabling sync
With Flux suspended and Argo CD still in manual mode, compare the live cluster state with the Argo CD view for every resource in the pilot. Investigate any field that differs, including labels and annotations that Flux added, because these can cause Argo CD to flag or remove them later. Decide whether each difference belongs in Git, should be ignored through an ignoreDifferences rule, or is noise to remove. The check is a written sign-off from the platform team that the remaining differences are understood and accepted for each resource.
Hand ownership to Argo CD and verify the pilot
Enable sync for the pilot Application, either manually for the first run or with automated sync if your policy allows it, and let Argo CD apply the desired state from Git. Confirm the Application reaches Synced and Healthy, and confirm that the Flux object is still suspended and has not been deleted. Watch the workloads roll out and check application-level health, such as readiness and error rates, for a period agreed with the application owner. The check is that the Application is healthy, the workload matches Git, and no Flux controller has written to the resources since the handover.
Repeat the cutover per namespace with rollback criteria
Migrate the remaining namespaces in batches, applying the same suspend, compare, sync and verify sequence to each one. Before each batch, write down the rollback criteria, such as failed health checks, unexpected resource deletions in the Argo CD diff, or a sync that cannot complete. If a criterion is met, resume the Flux object and remove or disable the Argo CD Application for that namespace while keeping the same Git source, so the rollback does not require manual reapplication. The check for each batch is that Argo CD reports Synced and Healthy and that no namespace has two active owners.
Decommission Flux controllers last
Once every namespace is owned by Argo CD and has run cleanly for an agreed period, remove the Flux Kustomizations, HelmReleases and source objects, and then uninstall the Flux controllers and their CRDs. Remove any Flux finalizers or labels still on resources, and confirm the Flux Git deploy key or token is revoked. Keep the final Git history and cluster inventory as the migration record. The check is that no Flux CRDs or controller pods remain, and that Argo CD still reports all Applications as Synced and Healthy.
How Helm values move from HelmRelease into Argo CD Applications
In a Flux migration, the Helm settings are the part most likely to change a running workload without anyone noticing. A HelmRelease carries its chart pin in spec.chart.spec.version, its inline overrides in spec.values, and additional layers from spec.valuesFrom, which points at ConfigMaps and Secrets. In Argo CD, the equivalent settings live on the Application's Helm source: the chart version goes in targetRevision, file-based layers go in helm.valueFiles, inline overrides go in helm.values, and single key overrides go in helm.parameters. Map each valuesFrom entry to one of these explicitly and record the precedence order Flux applied, because a later layer overriding an earlier one must keep doing so after the move. Confirm the exact field names and precedence rules against the current Argo CD Helm documentation for your target version, since the source fields are version sensitive.
Values sourced from Secrets need a decision before cutover, not during it. Flux reads a valuesFrom Secret inside the cluster, but Argo CD will not read that Secret on your behalf unless you choose a mechanism for it. Options include keeping the Secret out of Git and managing it with an external secrets operator or a sealed or encrypted pattern, or moving the sensitive values into the destination cluster's own secret store. Whichever you pick, check that the rendered manifest does not place secret material in the Application spec, in logs, or in Argo CD's cache, and that the secret-management approach is agreed with the people who own the credentials. Do this before the first sync, not after an Application shows a diff.
Helm rendering is not identical across controllers. Flux runs the helm controller and Argo CD renders charts in the repo-server, so differences in release naming, hook execution, CRD handling and default values can produce a different set of live objects from the same chart and values. Upgrades add risk: a chart version bump that a HelmRelease applied on its own schedule may show as a large diff in Argo CD. Before cutover, render each chart with the Flux inputs and the Argo CD inputs, diff the output objects by kind, name and namespace, and treat any removed or renamed resource as a blocker. Keep the chart version identical during the comparison so that only the tool, not the chart, changes. Record the review in the change ticket so the cutover has evidence behind it.
Questions teams ask before moving from Flux to Argo CD
How much effort does a Flux to Argo CD migration take?
Effort depends mostly on how many Flux Kustomizations and HelmReleases exist, how much Helm values logic they carry, and how many clusters and namespaces must move. Each Flux object maps to an Argo CD Application or, where the same workload repeats across clusters, an ApplicationSet. Work also covers repository layout changes, SSO and RBAC setup, and removing Flux controllers after each namespace is cut over. Ask any partner to itemize the object inventory, the number of clusters and the Helm value sources in the written scope, since these are the inputs that move the quote most.
How long does the migration run, and what changes the timeline?
No duration is fixed by the Argo CD or Flux project documentation, so the timeline should come from the written scope, not from a generic estimate. The main drivers are the number of namespaces, whether Helm values come from Git, external secrets or generated files, how many environments need a separate approval path, and how many change windows the organization allows. Confirm the number of cutover waves, the rollback criteria for each wave and the date when the Flux controllers will be removed.
What must our team provide before the work starts?
Plan to provide four things: an inventory of every Flux Kustomization, HelmRelease, source and notification object across clusters; read access to the Git repositories that hold those manifests; administrative access to each target cluster, along with a named contact for it; and agreed change windows for each namespace. Also provide the identity provider details if SSO will be part of the scope. Ask the partner to confirm in writing which of these items it needs from you and which it will gather itself.
Can an in-house platform team do this migration without a partner?
Yes, if the team already runs Kubernetes in production, has tested Git-based deployments and can dedicate people to the cutover. The steps themselves are documented in the Argo CD and Flux documentation. The risk lies in running two controllers against the same resources during the parallel period, in Helm values that were applied through Flux and must be reproduced exactly, and in the Argo CD security settings that apply on day one. A partner can take on any part of that work under a fixed scope, or review the team's plan before it runs.
How do we avoid downtime while Flux and Argo CD run side by side?
Avoid downtime by making sure each resource is reconciled by exactly one controller at any time. Move one namespace at a time: suspend the Flux object for that namespace, confirm the Argo CD Application reports the same desired state, sync it, and only then remove the Flux objects and their finalizers. Do not leave a Flux Kustomization with pruning enabled pointed at resources that Argo CD also manages. Keep a rollback path for each namespace until the wave is verified, and record which controller owns each namespace in the cutover log.
Do Argo CD's SSO and RBAC replace Flux's impersonation model?
Not one for one. Flux uses Kubernetes RBAC with impersonation, so each reconciliation runs as a service account that the cluster administrator scopes per tenant. Argo CD instead controls access through SSO groups, AppProjects and its own RBAC policy, while the controller still needs cluster permissions to apply resources. Map each Flux tenant to an Argo CD project, define which destination clusters and namespaces it can touch, and review the cluster-level permissions Argo CD holds. Confirm this model with the security team before cutover, because it determines who can change what.
What should we check on the Argo CD side before the first cutover?
Check the Argo CD version against the project's release cadence, since only the three most recent minor versions receive patch releases, and confirm the SSO and admin settings. Argo CD 3.0 changed where repositories are defined, requiring Kubernetes Secrets instead of the argocd-cm ConfigMap, and changed RBAC on applications and logs. Enable annotation-based resource tracking only after checking for conflicts with Flux labels. Disable the built-in admin user once SSO is working, and plan high availability with at least three nodes if the instance will be production critical.
Risks that cause outages during a Flux to Argo CD move
Most outages in a Flux to Argo CD move come from two tools claiming the same objects, or from one tool deleting what the other just applied. The risks below share a root cause: ownership of each resource is unclear during the overlap, so each card pairs a risk with a check that makes ownership explicit before a namespace moves.
Two controllers reconciling the same resources
When a namespace is managed by a Flux Kustomization and an Argo CD Application at the same time, each controller applies its own desired state and the two fight over every field they both render. The result is flapping Deployments and unexpected rollouts. Before cutover, confirm that each namespace and each workload has exactly one owning controller, and suspend the Flux Kustomization or HelmRelease for that namespace before the Argo CD Application syncs it.
Prune and self-heal deleting Flux objects
An Argo CD Application with prune enabled deletes any live resource that is not in its rendered source, and self-heal reverts manual or other-controller changes. Flux-created objects such as its own Kustomization labels, Helm release records or controller-applied annotations can be treated as drift or as orphans. Start new Applications with automated sync and prune turned off, review the diff, and enable them only after the namespace is confirmed as Argo CD owned.
Helm rendering differences causing rollouts
A HelmRelease values block is not always the same input Argo CD gets when it renders the same chart. Differences in chart version pins, value merge order, default values or hook handling can change pod specs and trigger a rolling restart across the namespace. Export the rendered manifests from the Flux HelmRelease, render the same chart with the Argo CD values source, and compare them before the first sync. Treat any unexplained change in a pod template as a stop condition.
Flux secrets and Git credentials left behind
Flux stores Git and Helm repository credentials as Kubernetes Secrets and may reference decryption keys for SOPS-encrypted values. When the move finishes, those Secrets can remain in the cluster, still readable by service accounts that no longer need them, or be copied into Argo CD repository Secrets without scope limits. Inventory every Flux Secret and its consumers, create Argo CD repository Secrets with read-only deploy credentials, and delete the Flux copies once the namespace cutover is verified.
Repo-server access to out-of-tree files
The Argo CD repo-server runs Helm and Kustomize on repository content, and a Helm chart or Kustomize overlay can reference files outside its own directory. During migration, teams often point Applications at an existing mixed repository that includes Flux manifests and secrets. Limit each Application to a dedicated path or repository, avoid relative references that leave the source directory, and review repositories that will be rendered before they are added as sources.
Missing RBAC for logs and resources
Argo CD 3.0 changed RBAC so that update and delete permissions apply only to the Application itself, and viewing logs requires an explicit logs, get permission. Teams that migrated under 2.14 may find that on-call users can no longer read pod logs or delete resources they relied on, which slows incident response during cutover. Before moving a namespace, test each role against the new rules, including logs access, and confirm the change with a named user from each team.
What drives the effort and what the migration cannot change
The effort follows the number of clusters, namespaces and HelmReleases you have to move, and how much logic sits in each one. A single cluster with a handful of Kustomizations is a small job. Many clusters, each with its own Flux bootstrap and dozens of namespaces, multiplies the cutover steps, the Argo CD cluster registrations and the verification work. HelmReleases with complex values files, value merges across several valuesFrom sources, or chart version pins that differ between environments take the most time, because each one has to be rendered and compared before it is trusted. Ask your team for an inventory of every Flux object by cluster and namespace, including which ones use postBuild substitution. Substitution variables sourced from ConfigMaps or Secrets have no direct Argo CD equivalent in the same form, so each one needs a planned replacement, such as a Kustomize overlay, Helm values or a plugin you have chosen to accept the risk of.
Image automation and notification controllers are the factors teams most often forget, because they act outside the manifests. Flux image update automation writes new tags back to Git, and Argo CD Image Updater or a CI pipeline may replace it, so you must decide who owns each image tag before cutover. Flux notification providers, alerts and receivers that post to chat tools or trigger reconciliation need a mapping to Argo CD Notifications or to your existing alerting. Existing SSO and RBAC design also shapes the work: Flux relies on Kubernetes RBAC with impersonation, while Argo CD adds its own projects and roles, so group mappings and per-team permissions must be designed on the Argo CD side. Plan the Argo CD installation itself (high availability, SSO, projects) as a separate piece of work, and confirm the target Argo CD version first, because configuration keys and access rules differ between releases. The Argo CD upgrade notes for 2.14 to 3.0 show how far RBAC and repository configuration changed in one major step.
Some things do not change: the Git history, the cluster state you must not disrupt and the controller that owns each resource at any moment. Your Git repositories and their commit history stay as they are, but the paths, sync options and ownership model in Argo CD will differ from Flux, so the target layout should be agreed before work starts. Live resources keep their current labels and annotations until a sync touches them, which is why tracking method and ownership must be checked on each namespace. Migration cannot remove the need for a short period in which both controllers exist, and it cannot make Argo CD and Flux reconcile the same object safely at once. Confirm with your platform team which Flux version is running and whether Flux will be suspended or removed per namespace, then write the cutover order down before any Flux object is deleted.
What makes a Flux to Argo CD migration cost more or less
This table lists the factors that move effort up or down in a Flux to Argo CD migration, with the question to ask in a quote for each. Read it before scoping, because the same number of objects can take very different amounts of work depending on Helm values, cluster count and how long both controllers must run side by side.
| Driver | Effect on effort | What to confirm in a quote |
|---|---|---|
| Object count | Effort grows with the number of Flux Kustomizations and HelmReleases, and with how many Applications or ApplicationSets they must map to. | Inventory of Kustomizations, HelmReleases, sources and namespaces, and whether the quote covers conversion of every object or a sample. |
| Helm value complexity | Charts with many overrides, valuesFrom references, or values stored in Secrets and ConfigMaps take longer to translate and verify than charts with defaults. | How values are sourced today, whether value files will be rendered and compared, and who signs off on rendered manifests. |
| Multi-cluster topology | Each additional cluster adds cluster registration, credentials, and per-cluster cutover checks, and affects whether ApplicationSets can replace repeated Applications. | Number of clusters, how Argo CD will reach each one, and whether the quote includes per-cluster cutover steps. |
| Required SSO and RBAC design | Mapping Flux access (Kubernetes RBAC with impersonation) to Argo CD projects, SSO groups and roles is a design task that often runs in parallel with the migration. | Identity provider, group mapping model, whether SSO is in scope, and who approves the role design. |
| Validation and parallel-run length | Longer parallel runs add verification work and operational overhead while both controllers are present, but reduce cutover risk. | Validation criteria per namespace, length of the planned parallel run as a decision made with your team, and what evidence is delivered at each gate. |
| Team familiarity with Argo CD | Teams new to Argo CD need more time for sync policies, health checks, and troubleshooting, which can shift work from build to training and support. | Whether knowledge transfer, runbooks and pairing are included, and how many people will operate the new installation. |
What your team provides and what DeployOpen delivers
Your team's inputs decide how safely the cutover can be planned, so collect them before any Argo CD Application is written. The first item is read access to the Flux repository, including every path that holds a Kustomization or HelmRelease object, the GitRepository and HelmRepository sources they reference, and any postBuild substitution values or valuesFrom ConfigMaps and Secrets. Provide a current inventory of clusters and namespaces where Flux reconciles, with the spec.targetNamespace and prune settings for each Kustomization, because these determine which resources Argo CD must take over. Also provide the change windows your organization allows, the people who approve production changes, and a named owner for each application who can confirm expected behavior during and after the move. Ask your Flux administrators to confirm whether any Flux resources are managed outside Git, since those will not appear in your repository review.
Once those inputs are in place, DeployOpen delivers planning and build artifacts scoped to your environment. The main artifacts are an object mapping that pairs every Flux Kustomization and HelmRelease with its target Argo CD Application or ApplicationSet, Application manifests stored in your Git repository, and a per-namespace cutover runbook listing the order of suspension, ownership transfer, sync verification and Flux removal. The runbook includes a rollback plan that states how to restore Flux reconciliation for a namespace and which Git revision to return to. DeployOpen does not set calendar timelines in advance; the schedule follows from the written scope, the number of namespaces and the approval cadence you confirm. Ask for those artifacts, and their review points, to be listed explicitly in any quote so the deliverables can be checked against the written scope before work begins.
How DeployOpen scopes, delivers and supports a Flux to Argo CD migration
DeployOpen, a Chainscore Labs company, plans and carries out Flux to Argo CD migrations inside your own clusters and infrastructure. Each engagement starts with a written, fixed scope that maps your existing Flux objects, sets the cutover order by namespace, and defines what gets handed over to your team.
How we scope
- Inventory of Flux Kustomizations, HelmReleases, sources and notification rules in each cluster
- Mapping of each object to an Argo CD Application or ApplicationSet, with the target project and destination
- Written list of namespaces, cutover order, rollback steps and the acceptance checks agreed before work starts
How we build
- Argo CD installed in your infrastructure with repositories defined as Kubernetes Secrets and Helm values carried over unchanged
- Flux suspended per namespace before its Argo CD Application syncs, so only one controller reconciles each resource
- Test runs in a non-production cluster that compare rendered manifests from both tools before any production namespace moves
How we hand over
- Runbook covering each cutover step, the rollback path and the removal of Flux resources once a namespace is stable
- Documented Application layout, sync policy choices, SSO group-to-role mapping and admin account settings
- Working session with your platform team to walk through the deployed configuration and open questions
How we support
- Ongoing support, version upgrades and continuous testing are available as a retainer after handover
- Retainer scope agreed in writing, covering Argo CD patch and minor version planning against the project's release cadence
- Quotes follow from the written scope, so you can ask for the effort split between build, testing and handover
