diff --git a/overview/deployment_environment.rst b/overview/deployment_environment.rst
index 45f3b9a..9f4815b 100644
--- a/overview/deployment_environment.rst
+++ b/overview/deployment_environment.rst
@@ -12,8 +12,8 @@
 Regardless of the chosen environment the deployment process is the same,
 more on this later, and the installation can be managed in the same way.
 
-Managing a VOLTHA deployment
-----------------------------
+VOLTHA deployment
+-----------------
 
 VOLTHA components on top of ``kubernetes`` are managed via ``helm`` charts.
 For more information about ``helm`` please refer to the `Official Documentation
@@ -49,8 +49,7 @@
 You can read more about VOLTHA deployments in:
 
 - :doc:`lab_setup`
-- :doc:`pod_physical`
-- :doc:`dev_virtual`
+- `Deployment with HELM <./../voltha-helm-charts/README.md>`_
 
 .. toctree::
    :maxdepth: 1
@@ -58,12 +57,4 @@
    :glob:
 
    ./lab_setup.rst
-   ./pod_physical.rst
-   ./dev_virtual.rst
-   ./multi-stack.rst
-
-Tooling
--------
-
-To simplify the installation of VOLTHA we provided a tool called ``kind-voltha``.
-You can read more on :doc:`kind-voltha <../kind-voltha/README>` in its own documentation.
+   Deploy VOLTHA <./../voltha-helm-charts/README.md>
diff --git a/overview/dev_virtual.rst b/overview/dev_virtual.rst
deleted file mode 100644
index 586b160..0000000
--- a/overview/dev_virtual.rst
+++ /dev/null
@@ -1,95 +0,0 @@
-.. _dev_virtual:
-
-Developing code with a virtual VOLTHA POD
-=========================================
-
-A guide to install a virtual POD. A virtual pod is generally used to gain familiarity with the
-environment or for development and testing purposes.
-
-How is it different from a Physical deployment?
------------------------------------------------
-
-The main difference is in the ``kubernetes`` cluster itself.
-In a Physical deployment we assume that the ``kubernetes`` cluster is installed
-on 3 (or mode) physical nodes.
-When installing a ``virtual`` cluster we refer to a ``kind`` (``kubernetes-in-docker``)
-cluster.
-
-Another common difference is that a Physical deployment is generally associated
-with one or more physical OLTs while a Virtual deployment normally emulates the
-PON network using :doc:`BBSim <../bbsim/docs/source/index>`.
-
-.. figure:: ../_static/voltha_cluster_virtual.png
-   :alt: VOLTHA Component Diagram
-   :width: 100%
-
-   VOLTHA Kubernetes kind deployment
-
-Note that is anyway possible to connect a physical OLT to a virtual cluster, as
-long as the OLT is reachable from the ``kind`` host machine. If you need to control
-your OLT "in-band" then it's not advised to connect it to a virtual cluster.
-
-Quickstart
-----------
-
-Requires:
-
-- ``docker`` and ``go`` installed on your machine
-- `kind-voltha <https://gerrit.opencord.org/gitweb?p=kind-voltha.git>`_ cloned
-  on your machine
-
-.. code:: bash
-
-    TYPE=minimal WITH_RADIUS=y CONFIG_SADIS=y WITH_BBSIM=y ./voltha up
-
-For more information you can visit the :doc:`kind-voltha page <../kind-voltha/README>`.
-
-Developing changes on a virtual pod
------------------------------------
-
-We assume you already have downloaded the git repository you want to modify and
-your IDE is correctly set up.
-
-In this tutorial we are going to use ``voltha-go`` as an example.
-
-Make the required changes in the ``voltha-go`` repository (the process
-is the same for all the VOLTHA repositories) to the code and build the
-docker images and push them on your private dockerhub account:
-
-.. code:: bash
-
-   $ DOCKER_REGISTRY="matteoscandolo/" DOCKER_TAG="dev" make docker-build
-
-Then push them to your docker hub account:
-
-.. code:: bash
-
-   $ DOCKER_REGISTRY="matteoscandolo/" DOCKER_TAG="dev" make docker-push
-
-Deploy your changes on kind-voltha
-----------------------------------
-
-Create a copy of the `minimal-values.yaml` file:
-
-.. code:: bash
-
-    $ cp minimal-values.yaml dev-values.yaml
-
-And edit that file so that it contains the appropriate values for the images you want to try,
-for example uncomment and change these two lines (mind the indentation):
-
-.. code:: yaml
-
-    images:
-      ro_core:
-        repository: matteoscandolo/voltha-ro-core
-        tag: dev
-      rw_core:
-        repository: matteoscandolo/voltha-rw-core
-        tag: dev
-
-Then redeploy `kind-voltha` using that the edited value file:
-
-.. code:: bash
-
-    $ DEPLOY_K8S=no ./voltha down && DEPLOY_K8S=no EXTRA_HELM_FLAGS="-f dev-values.yaml" ./voltha up
diff --git a/overview/lab_setup.rst b/overview/lab_setup.rst
index d0fb41b..8c11c70 100644
--- a/overview/lab_setup.rst
+++ b/overview/lab_setup.rst
@@ -11,7 +11,9 @@
 
 - The ``RG`` can be emulated by an ``lxc`` container (from now on ``client``)
 - The ``BNG`` can be emulated by a Linux server
-- The ``AggSwitch`` is optional in a VOLTHA deployment.
+- The ``AggSwitch`` is mandatory if control of the OLT is done with ``in-band`` mode, while
+  optional if the OLT is controlled out of band, in this case the NNI port of the OLT will go directly
+  into the emulated BNG linux server NIC card.
 
 .. figure:: ../_static/voltha_lab_setup.png
    :alt: VOLTHA Lab Setup
@@ -196,3 +198,17 @@
      option routers 10.11.2.254;
      option domain-name-servers 8.8.8.8;
    }
+
+Configuration for in-band OLT control
+-------------------------------------
+
+If OLT is being used in in-band connectivity mode, the
+`document <https://docs.google.com/document/d/1OKDJCPEFVTEythAFUS_I7Piew4jHmhk25llK6UF04Wg>`_
+details the configuration aspects in ONOS and the aggregation switch to
+trunk/switch in-band packets from the OLT to BNG or Voltha.
+
+In-band OLT software upgrade
+-------------------------------------
+If OLT with openolt agent is being used in in-band connectivity mode we provide the capability
+to execute SW updates of the image present on the device, the
+`README <https://github.com/opencord/openolt/tree/master/olt-sw-upgrade>`_ provides the required details.
diff --git a/overview/multi-stack.rst b/overview/multi-stack.rst
deleted file mode 100644
index 3ce4c3d..0000000
--- a/overview/multi-stack.rst
+++ /dev/null
@@ -1,95 +0,0 @@
-Deploy multiple VOLTHA stacks on a Kubernetes cluster
-=====================================================
-
-VOLTHA is designed so that multiple stacks can work together sharing the same infrastructure.
-You can read more about VOLTHA Stacks in this `document <https://docs.google.com/document/d/1Szo7vMS7M96O4Vsm1NpDYd3zckk9g0HLMck6eldwmcI/edit?usp=sharing>`_.
-
-This guide assumes you have a ``kubernetes`` cluster already up and running.
-We also assume you have familiarity with the `kind-voltha <../kind-voltha/README.html>`_. tool.
-
-Deploy the common infrastructure
---------------------------------
-
-When we refer to `infrastructure` components in VOLTHA, we are referring to:
-
-- ``Kafka``
-- ``ETCD``
-- ``ONOS``
-- ``RADIUS Server`` (optional)
-- ``Sadis Server`` (optional)
-
-*Note that these components can be deployed on ``kubernetes`` via ``kind-voltha`` or can be completely independent.*
-
-.. code:: bash
-
-  NAME=infra INFRA_NS=infra JUST_INFRA=y ./voltha up
-
-Note that this command will output configurations that you'll need to deploy your ``VOLTHA`` stack:
-
-.. code:: bash
-
-  To configure your VOLTHA stack to use this infrastructure please export these variables:
-    export INFRA_NS=infra
-    export WITH_ETCD=etcd.infra.svc:2379
-    export WITH_KAFKA=kafka.infra.svc:9092
-    export WITH_ONOS=onos-onos-classic-hs.infra.svc:6653
-
-  Or use:
-
-    INFRA_NS=infra WITH_ETCD=etcd.infra.svc:2379 WITH_KAFKA=kafka.infra.svc:9092 WITH_ONOS=onos-onos-classic-hs.infra.svc:6653 ./voltha up
-
-    If you are deploying mutltiple VOLTHA stack, also remember to configure a different NAME, NAMESPACE and BBSIM_BASE_INDEX for each stack:
-    export NAME=voltha1
-    export VOLTHA_NS=voltha1
-    export ADAPTER_NS=voltha1
-    export BBSIM_NS=voltha1
-    export BBSIM_BASE_INDEX=1
-
-  Or use:
-
-    INFRA_NS=infra WITH_ETCD=etcd.infra.svc:2379 WITH_KAFKA=kafka.infra.svc:9092 WITH_ONOS=onos-onos-classic-hs.infra.svc:6653 NAME=voltha1 VOLTHA_NS=voltha1 ADAPTER_NS=voltha1 BBSIM_NS=voltha1 BBSIM_BASE_INDEX=1 ./voltha up
-
-Deploy a VOLTHA stack
----------------------
-
-Once the ``infrastructure`` is set up you can deploy a ``VOLTHA`` stack using this command:
-
-.. code:: bash
-
-  NAME=voltha1 VOLTHA_NS=voltha1 ADAPTER_NS=voltha1 BBSIM_NS=voltha1 BBSIM_BASE_INDEX=1 ./voltha up
-
-NOTE that this command assumes you have exported the variables printed at the end of the ``infra`` deployment.
-In particular the required variables are:
-
-- ``INFRA_NS=infra`` (optional) only required if you installed the infrastructure using ``kind-voltha``
-- ``WITH_ETCD=etcd.infra.svc:2379`` the ETCD address
-- ``WITH_KAFKA=kafka.infra.svc:9092`` the KAFKA address
-- ``WITH_ONOS=onos-onos-classic-hs.infra.svc:6653`` the ONOS address
-
-Deploying multiple VOLTHA stacks
-********************************
-
-When you deploy a second ``VOLTHA`` stack there are some information that you need to customize in order to keep the
-two stacks independent:
-
-- ``NAME`` - the name of the stack, is used in log and configuration files and to customize the KAFKA topics each stack
-  is listening on
-- ``VOLTHA_NS, ADAPTER_NS, BBSIM_NS`` - are used to configure in which namespace the components are installed
-- ``BBSIM_BASE_INDEX`` - is used to guarantee that different ``BBSim`` instances won't have the same ID (have to be
-  unique across all the stacks)
-
-Operate a VOLTHA stack
-----------------------
-
-Once the installation completes a ``voltctl`` config file is generated for each cluster, in the format:
-
-.. code:: bash
-
-  VOLTCONFIG="~/.volt/config-<$NAME>"
-
-In order to use multiple stacks via the same ``voltcl`` tools we **strongly** suggest to **always** specify
-the appropriate configuration with the ``-c`` flag, for example:
-
-.. code:: bash
-
-  voltctl -c ~/.volt/config-voltha1 adapter list
diff --git a/overview/operate.rst b/overview/operate.rst
index bbc5619..68231c3 100644
--- a/overview/operate.rst
+++ b/overview/operate.rst
@@ -50,7 +50,7 @@
 Authentication
 --------------
 
-If the use-case you installed (e.g. AT&T) expects EAPOL based authentication you want to make
+If the worflow you installed (e.g. AT&T) expects EAPOL based authentication you want to make
 sure that is working. Visit :ref:`workflows` for more information.
 
 In a **Physical POD** you need to trigger authentication on your client
@@ -75,7 +75,7 @@
 *Note that, depending on the workflow, authentication is not a requirement of subscriber provisioning*
 
 The process referred to as ``Subscriber provisioning`` causes traffic flows to be created in ONOS and
- data plane path to be configured in the device, enabling different services on a specific UNI port.
+data plane path to be configured in the device, enabling different services on a specific UNI port.
 
 In order to provision a subscriber you need to identify it. In ONOS a subscriber
 is viewed as an enabled port (UNI) on the logical switch that VOLTHA exposes, for example:
@@ -140,7 +140,7 @@
 DHCP Allocation
 ---------------
 
-If the use-case you installed expect DHCP to be handled by ONOS it's time to check
+If the worflow you installed expect DHCP to be handled by ONOS it's time to check
 that an IP has correctly been allocated to the subscriber.
 
 In a **Physical POD** you need to trigger a DHCP request on your client
diff --git a/overview/pod_physical.rst b/overview/pod_physical.rst
deleted file mode 100644
index 91be3a6..0000000
--- a/overview/pod_physical.rst
+++ /dev/null
@@ -1,56 +0,0 @@
-.. _pod_physical:
-
-Deploy a physical VOLTHA POD
-============================
-
-This document assumes you POD is already correctly cabled, if not you can
-refer to :ref:`lab_setup`
-
-Requires:
-
-- a physical kubernetes cluster
-- `kind-voltha <https://gerrit.opencord.org/gitweb?p=kind-voltha.git>`_ cloned
-  on your machine
-
-
-Enter the ``kind-voltha`` directory and execute this command (``kubectl`` must
-be installed and pointing to your cluster):
-
-.. code:: bash
-
-    DEPLOY_K8S=no WITH_RADIUS=y CONFIG_SADIS=y SADIS_CFG="my-sadis-cfg.json" ./voltha up
-
-*``my-sadis-cfg.json`` is a reference to your own ``sadis`` configuration.
-This is needed to specify the appropriate values for your devices and subsribers*
-
-If you already have a ``radius`` server that you want to use, change the flag to ``WITH_RADIUS=n``
-and `configure ONOS accordingly <https://github.com/opencord/aaa>`_.
-
-For more information please check :doc:`kind-voltha page <../kind-voltha/README>`.
-
-After the deployment please refer to :ref:`operate` .
-
-HA Cluster
-----------
-
-To deploy ONOS in a multi instance environment for redundancy, High avaliablity and scale, you can add
-`NUM_OF_ONOS=3 NUM_OF_ATOMIX=3` to any of the workflow command. You can pick the number of instances onf ONOS
-and ATOMIX independently. As a good suggestion is 3 or 5.
-
-If you are planning to support a big number of ONU we suggest to horizontally scale
-the ``openonu-adapater``, you can do so by setting the ``NUM_OF_OPENONU`` variable.
-Generally speaking a single ``openonu-adapter`` instance can support up to 200 ONU devices.
-
-As an example for the ATT workflow:
-
-.. code:: bash
-
-    WITH_RADIUS=y CONFIG_SADIS=y SADIS_CFG="my-sadis-cfg.json" NUM_OF_ONOS=3 NUM_OF_ATOMIX=3 NUM_OF_OPENONU=8 ./voltha up
-
-Configuration for in-band OLT control
--------------------------------------
-
-If OLT is being used in in-band connectivity mode, the following
-`document <https://docs.google.com/document/d/1OKDJCPEFVTEythAFUS_I7Piew4jHmhk25llK6UF04Wg>`_
-details the configuration aspects in ONOS and the aggregation switch to
-trunk/switch in-band packets from the OLT to BNG or Voltha.
diff --git a/overview/quickstart.rst b/overview/quickstart.rst
deleted file mode 100644
index e043b79..0000000
--- a/overview/quickstart.rst
+++ /dev/null
@@ -1,75 +0,0 @@
-.. _quickstart:
-
-Quickstart
-==========
-
-This page contains a set of one liner useful to setup different VOLTHA use-cases on
-a Virtual pod emulating the PON through :doc:`BBSim <../bbsim/docs/source/index>`.
-
-For more information on how to setup a :doc:`physical POD <./pod_physical>` or
-use a :doc:`Virtual POD <./dev_virtual>` for development
-refer to the respective guides.
-
-Common setup
-------------
-
-In order to install VOLTHA you need to have ``golang`` and ``docker`` installed.
-
-.. code:: bash
-
-    export KINDVOLTHADIR=~/kind-voltha
-    mkdir $KINDVOLTHADIR
-    cd $KINDVOLTHADIR
-    curl -sSL https://raw.githubusercontent.com/opencord/kind-voltha/master/voltha --output ./voltha
-    chmod +x ./voltha
-
-Now select the use-case you want to deploy:
-
-ATT Workflow
-------------
-
-The ATT Workflow expects EAPOL based authentication and DHCP to be handled within
-the VOLTHA POD.
-
-.. code:: bash
-
-    cd $KINDVOLTHADIR
-    WITH_BBSIM="yes" WITH_EAPOL="yes" WITH_DHCP="yes" WITH_RADIUS="yes" CONFIG_SADIS="bbsim" ./voltha up
-
-DT Workflow
-------------
-
-The DT workflow does not require EAPOL based authentication or DHCP packet handling
-in the VOLTHA POD.
-
-.. code:: bash
-
-    cd $KINDVOLTHADIR
-    WITH_BBSIM="yes" WITH_EAPOL="no" WITH_DHCP="no" CONFIG_SADIS="bbsim" BBSIM_CFG="configs/bbsim-sadis-dt.yaml" ./voltha up
-
-TT Workflow
-------------
-
-The TT workflow does not require EAPOL based authentication but expects DHCP packets
-for multiple services to be handled within the POD.
-
-.. code:: bash
-
-    cd $KINDVOLTHADIR
-    WITH_BBSIM="yes" WITH_EAPOL="no" WITH_DHCP="yes" CONFIG_SADIS="bbsim" BBSIM_CFG="configs/bbsim-sadis-tt.yaml" ./voltha up
-
-Post deploy actions
--------------------
-
-Once the deployment completed, make sure to export the required ``environment``
-variables as ``kind-voltha`` outputs:
-
-.. code:: bash
-
-    export KUBECONFIG="/Users/teone/.kube/kind-config-voltha-minimal"
-    export VOLTCONFIG="/Users/teone/.volt/config-minimal"
-    export PATH=/Users/teone/kind-voltha/bin:$PATH
-
-Once you have the POD up and running you can refer to the :doc:`./operate` guide.
-
-For more information please check :doc:`kind-voltha page <../kind-voltha/README>`.
diff --git a/overview/workflows.rst b/overview/workflows.rst
index 25bb7e6..fb550e2 100644
--- a/overview/workflows.rst
+++ b/overview/workflows.rst
@@ -5,27 +5,25 @@
 
 ``Workflow`` is a term that spilled from the SEBA Reference Design (RD) into VOLTHA.
 
-In SEBA a workflow is defined as the set of operations that control the lifecycle
-of a subscriber, authentication logic, customer tag management etc... Such workflow is operator specific.
+In SEBA a workflow is a collection of subscriber management items like identification, location,
+and bandwidth profile. In addition each workflows maps to a service type which translates to a technology profile,
+and an operator desired flow of operations (i.e state-machine).
+The workflow is implemented by a selection of ONOS apps, XOS services (in SEBA)
+and a set of configurations (sadis, etcd, netcfg). Those apps paired with the configuration specified by the
+workflow (e.g. need EAPOL) in turn create low level flows, groups, meters, schedulers, queues etc.
+A workflow is then triggered by a particular set of APIs, for example the request to add a subscriber.
 
-A full description of the workflows can be `found here <https://drive.google.com/drive/folders/1MfxwoDSvAR_rgFHt6n9Sai7IuiJPrHxF>`_.
+A full description of the different operator's workflows can be
+`found here <https://drive.google.com/drive/folders/1MfxwoDSvAR_rgFHt6n9Sai7IuiJPrHxF>`_.
 
 A big part of the workflow in SEBA is defined within NEM (Network Edge Mediator).
-Given that NEM is not available in a plain VOLTHA deployment the definition
-of workflow is a subset of the SEBA one, and comprises:
+Given that NEM is not available in a plain VOLTHA deployment the user has to ensure proper config in the right places,
+and then triggering of api's themselves.
 
-- Customer tags allocation
-- Technology profile
-- Bandwidth profile
-- Flow management (EAPOL/DHCP/Data path)
-- Group management
+To deploy a specific workflow follow the steps in the voltha-helm-charts
+`README <./../voltha-helm-charts/README.md#deploying-a-different-workflow>`_.
 
-The `workflows` are often referred to as `use-cases` and the two words are interchangeable
-in the VOLTHA environment.
-
-To deploy a specific workflow through ``kind-voltha`` please visit :ref:`quickstart`.
-
-How is the workflow defined in VOLTHA?
+What does the workflow entail in VOLTHA?
 ----------------------------------------
 
 Customer tag allocation