diff --git a/content/docs/Deployment/Kubernetes/helm.md b/content/docs/Deployment/Kubernetes/helm.md
index 71be5e7..834e5e0 100644
--- a/content/docs/Deployment/Kubernetes/helm.md
+++ b/content/docs/Deployment/Kubernetes/helm.md
@@ -88,55 +88,39 @@ You should at least provide both connection strings and ensure that workloads in
 Read also about [monitoring]({{% ref "observe" %}}) the replicator process in Kubernetes.
 {{%/ alert %}}
 
-## Complete the deployment
+## Configuring a JavaScript transform
 
-When you have the `values.yml` file complete, deploy the release using Helm. Remember to set the current `kubectl` context to the cluster where you are deploying to.
+Follow the documentation to configure a [JavaScript transform](/docs/features/transforms/js/) in your `values.yml` file.
 
+Then append the following option to your `helm install` command:
 ```bash
-$ helm install es-replicator es-replicator/es-replicator -f values.yml -n es-replicator
+--set-file transformJs=./transform.js
 ```
 
-You can choose another namespace, the namespace must exist before doing a deployment.
-
-The replication starts immediately after the deployment, assuming that all the connection strings are correct, and the Replicator workload has network access to both source and sink EventStoreDB instances.
-
-{{% alert color="warning" %}}
-The checkpoint is stored on a persistent volume, which is provisioned as part of the Helm release. If you delete the release, the volume will be deleted by the cloud provider, and the checkpoint will be gone. If you deploy the tool again, it will start from the beginning of the `$all` stream and will produce duplicate events.
-{{%/ alert %}}
-
-## Configuring JS transform
+## Configuring a custom partitioner
 
-If you want to use a [JavaScript transform](/docs/features/transforms/js/), you need to add a config map to the Replicator namespace before doing the Helm deployment. You'd need one config map, which contains the JavaScript code file for the transform function. The config map should contain the JS code as data:
+Follow the documentation to configure a custom [partitioner]({{% ref "writers" %}}) in your `values.yml` file.
 
+Then append the following option to your `helm install` command:
 ```bash
-kubectl create configmap transform --from-file=transform.js -n <replicator namespace>
-```
-
-Then, use the `jsConfigMaps` option in the `values.yml` file to provision volume and volume mount for the JS file:
-
-```yaml
-jsConfigMaps:
-  - configMapName: transform
-    fileName: transform.js
+--set-file partitionerJs=./partitioner.js
 ```
 
-The config map data will be mapped as a volume to the `js` directory of the application root directory inside the pod.
+## Complete the deployment
 
-Finally, configure the JS transform in the values override file:
+When you have the `values.yml` file complete, deploy the release using Helm. Remember to set the current `kubectl` context to the cluster where you are deploying to.
 
-```yaml
-replicator:
-  transform:
-    type: js
-    config: ./js/transform.js
+```bash
+helm install es-replicator \
+  es-replicator/es-replicator \
+  --values values.yml \
+  --namespace es-replicator
 ```
 
-Finally, proceed with the deployment as normal.
-
-## Configure JS partitioning
-
-To use a custom [partitioner]({{% ref "writers" %}}), use the same steps described above for the custom transform to create a config map from the function source code file. 
+You can choose another namespace, the namespace must exist before doing a deployment.
 
-Add the config map name and the file name to the `jsConfigMaps` section of the values override file.
+The replication starts immediately after the deployment, assuming that all the connection strings are correct, and the Replicator workload has network access to both source and sink EventStoreDB instances.
 
-Finally, set the `replicator.sink.partitioner` value to the file path (including the `./js/` directory).
+{{% alert color="warning" %}}
+The checkpoint is stored on a persistent volume, which is provisioned as part of the Helm release. If you delete the release, the volume will be deleted by the cloud provider, and the checkpoint will be gone. If you deploy the tool again, it will start from the beginning of the `$all` stream and will produce duplicate events.
+{{%/ alert %}}