> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/troubleshooting-and-resources/armory/general/deploy-manifest-stage-does-not-remove-previous-helm2-deployment-resources-from-kubernetes.md).

# Deploy (Manifest) stage does not remove previous Helm2 deployment resources from Kubernetes

### Issue <a href="#issue" id="issue"></a>

Sometimes when migrating an application to Spinnaker that was previously deployed using Helm2 or `kubectl create`, the deployment's old resources are not removed or modified as expected.Example workflow:

* Helm2 chart was previously deployed in target Kubernetes namespace\* This chart was migrated into Spinnaker and modified to include a new container, deployed in same namespace
* Deployment object in Kubernetes contained both the old container (installed in previous helm chart) and the new container.

### Cause <a href="#cause" id="cause"></a>

If the Kubernetes deployment resource does not contain a `last-applied-configuration` annotation, when Spinnaker uses `kubectl apply` to deploy the new manifest, Kubernetes may not know to remove the old container or other deployment resources. **Related issues:**[*spinnaker/spinnaker#2877*](https://github.com/spinnaker/spinnaker/issues/2877#issuecomment-429071589)*: Deploy (Manifest) stage merges attributes of existing object into deployed manifest*This user explains that they were running up against how kubectl apply was designed.`kubectl apply` is known to create states similar to this when, for example, the previous deployment was generated with `kubectl create`, which does not leave a `last-applied-configuration` annotation in the deployment. This annotation is used by `kubectl apply` to figure out what resources need to be removed or updated.