How to: Readme before migration
***WARNING:*** All data migrations carry a level of risk. Helm v2 migration is no different.
You should be aware of any risks specific to your environment and prepare a data migration
strategy for your needs.

Here are some suggestions to mitigate against potential risks during migration:

- Perform a data backup of the following:
  - Helm v2 home folder.
  - Release data from the cluster. Refer to [How Helm Uses ConfigMaps to Store Data](http://technosophos.com/2017/03/23/how-helm-uses-configmaps-to-store-data.html)
  for details on how Helm v2 store release data in the cluster. This should apply
  similarly if Helm v2 is configured for secrets.
- Avoid performing operations with Helm v3 until data migration is complete and you are
  satisfied that it is working as expected. Otherwise, Helm v3 data might be overwritten.
  The operations to avoid are chart install, adding repositories, plugin install etc.
- The recommended data migration path is as follows:
  1. Backup v2 data, as suggested above.
  2. Migrate [Helm v2 configuration](#migrate-helm-v2-configuration).
  3. Migrate [Helm v2 releases](#migrate-helm-v2-releases).
  4. When happy that Helm v3 is managing Helm v2 data as expected, then [clean up](#clean-up-helm-v2-data) Helm v2 data.
     *Note:*: Only use the plugin to do clean up. Using `helm`, `kubectl` or other tools could lead to data loss and an indeterminate
      state for the release(s).

**Note:**
A Helm v2 client:

- can manage 1 to many Kubernetes clusters.
- can connect to 1 to many Tiller instances for  a cluster.

This means that you have to cognisant of this when migrating as releases are deployed into clusters by Tiller and
its namespace. You have to therefore be aware of migrating for each cluster and each Tiller instance that is managed
by the Helm v2 client instance. [Clean up](#clean-up-helm-v2-data) should only be run once all migration for a Helm v2 client is complete.