diff --git a/docs/dist-git-move/index.rst b/docs/dist-git-move/index.rst
index d9e51e8..0d2cd12 100644
--- a/docs/dist-git-move/index.rst
+++ b/docs/dist-git-move/index.rst
@@ -70,21 +70,57 @@ Index
     summary
     solution
 
-Conclusions
------------
-To adequately complete the proposed work, 3-4 engineers for approximately 
-2 quarters is recommended.
+Estimate
+--------
 
+To adequately complete the proposed work, 3-4 engineers for approximately 2 quarters is
+recommended. 2-3 developers and 1 sysadmin should suffice the need of both building the
+said solution as well as creating the deployment.
 
-Proposed Roadmap
-----------------
+Roadmap
+-------
 
-- **Step 1** - Deploy to staging
-- **Step 2** - Community testing
-- **Step 3** - Deploy to production
+- **Step 1** - Discussing on the Git Forge and deciding on a specific one to use
+- **Step 2** - Introducing the *newer API compatibility* to the
+  *internally maintained applications*
+- **Step 3** - Adding Git Large File System support for the source tarballs and binary
+  files
+- **Step 4** - Developing the compatibility metaservice for the chosen Git Forge API
+- **Step 5** - Making a staging deployment for the Git Forge on a subdomain (say,
+  ``SUBDOMAIN A``)
+- **Step 6** - Pointing the Dist Git's staging URL (say, ``SUBDOMAIN B``) to the
+  compatibility metaservice
+- **Step 7** - Following up for the *externally maintained applications* to switch over
+  to the newer API
+- **Step 8** - Improving the project on the community feedback received on the staging
+  deployment tests
+- **Step 9** - Making a production deployment for the Git Forge on a subdomain (say,
+  ``SUBDOMAIN C``)
+- **Step 10** - Pointing the Dist Git's production URL (say, ``SUBDOMAIN D``) to the
+  compatibility metaservice
+- **Step 11** - Announcing a time limit for the planned obsolescence for the
+  compatibility metaservice
+- **Step 12** - Confirming that all the applications have switched over to the newer API
+- **Step 13** - Decommissioning of the compatibility metaservice after its utility is
+  outlived
+- **Step 14** - PROFIT?
 
-Proposed Technologies
----------------------
-- `Git LFS <https://git-lfs.com/>`_ Large File Storage for lookaside cache
-- 
+Appendix
+^^^^^^^^
 
+- **Internally maintained applications** - Projects maintained by the Red Hat CPE team
+  (eg. Monitor Gating, The New Hotness, Releng Scripts, Toddlers, Notifications and
+  Datanommer)
+- **Externally maintained applications** - Projects maintained by other teams (eg.
+  Fedpkg, COPR, Fedora CI, Bodhi and Packit)
+- **Newer API compatibility** - Making pre-releases with the compatibility changes
+  included as the said Git Forge is not yet deployed
+
+Technologies
+------------
+
+- `Git <https://git-scm.com/>`_ - For Source Code Management
+- `Git LFS <https://git-lfs.com/>`_ - For source tarballs and binary files in lookaside
+   cache
+- `FastAPI <https://fastapi.tiangolo.com/>`_ - For the compatibility metaservice backend
+- `Vue <https://vuejs.org/>`_ - For the Git Forge frontend