What should you check before enabling Server-Side Apply on CRDs and Helm-managed workloads?

SSA merges structurally using the OpenAPI schema, so behavior depends on how types describe their lists. Built-in types are annotated, but a CRD without x-kubernetes-list-type: map/set and merge keys is treated as atomic — an apply replaces the entire list instead of merging elements, which can wipe entries other managers added. Second, SSA only governs the apply path; a plain kubectl patch, an update, or a subresource write still overwrites an SSA-owned field and does not surface an SSA conflict, so mixing imperative edits can still bite you. Third, plan the Helm story: Helm 4 adopts server-side apply for new releases, but releases created under the old model must be migrated explicitly rather than switching automatically. Validate these before flipping SSA on cluster-wide.