diff --git a/beacon_node/client/src/config.rs b/beacon_node/client/src/config.rs
index 15ff7d024..8a15e4598 100644
--- a/beacon_node/client/src/config.rs
+++ b/beacon_node/client/src/config.rs
@@ -141,11 +141,47 @@ impl Config {
         ensure_dir_exists(self.get_freezer_db_path())
     }
 
+    /// Returns the "modern" path to the data_dir.
+    ///
+    /// See `Self::get_data_dir` documentation for more info.
+    fn get_modern_data_dir(&self) -> PathBuf {
+        self.data_dir.clone()
+    }
+
+    /// Returns the "legacy" path to the data_dir.
+    ///
+    /// See `Self::get_data_dir` documentation for more info.
+    pub fn get_existing_legacy_data_dir(&self) -> Option<PathBuf> {
+        dirs::home_dir()
+            .map(|home_dir| home_dir.join(&self.data_dir))
+            // Return `None` if the directory does not exists.
+            .filter(|dir| dir.exists())
+            // Return `None` if the legacy directory is identical to the modern.
+            .filter(|dir| *dir != self.get_modern_data_dir())
+    }
+
     /// Returns the core path for the client.
     ///
     /// Will not create any directories.
-    pub fn get_data_dir(&self) -> PathBuf {
-        self.data_dir.clone()
+    ///
+    /// ## Legacy Info
+    ///
+    /// Legacy versions of Lighthouse did not properly handle relative paths for `--datadir`.
+    ///
+    /// For backwards compatibility, we still compute the legacy path and check if it exists.  If
+    /// it does exist, we use that directory rather than the modern path.
+    ///
+    /// For more information, see:
+    ///
+    /// https://github.com/sigp/lighthouse/pull/2843
+    fn get_data_dir(&self) -> PathBuf {
+        let existing_legacy_dir = self.get_existing_legacy_data_dir();
+
+        if let Some(legacy_dir) = existing_legacy_dir {
+            legacy_dir
+        } else {
+            self.get_modern_data_dir()
+        }
     }
 
     /// Returns the core path for the client.
diff --git a/beacon_node/src/lib.rs b/beacon_node/src/lib.rs
index b536fb8cb..4ff474571 100644
--- a/beacon_node/src/lib.rs
+++ b/beacon_node/src/lib.rs
@@ -66,6 +66,15 @@ impl<E: EthSpec> ProductionBeaconNode<E> {
         let freezer_db_path = client_config.create_freezer_db_path()?;
         let executor = context.executor.clone();
 
+        if let Some(legacy_dir) = client_config.get_existing_legacy_data_dir() {
+            warn!(
+                log,
+                "Legacy datadir location";
+                "msg" => "this occurs when using relative paths for a datadir location",
+                "location" => ?legacy_dir,
+            )
+        }
+
         if !client_config.chain.enable_lock_timeouts {
             info!(log, "Disabling lock timeouts globally");
             TimeoutRwLock::disable_timeouts()
diff --git a/book/src/advanced-datadir.md b/book/src/advanced-datadir.md
index 3b95bc9d7..9f81112bd 100644
--- a/book/src/advanced-datadir.md
+++ b/book/src/advanced-datadir.md
@@ -13,3 +13,47 @@ lighthouse --network mainnet --datadir /var/lib/my-custom-dir vc
 ```
 The first step creates a `validators` directory under `/var/lib/my-custom-dir` which contains the imported keys and [`validator_definitions.yml`](./validator-management.md).
 After that, we simply run the beacon chain and validator client with the custom dir path.
+
+### Relative Paths
+
+[#2682]: https://github.com/sigp/lighthouse/pull/2682
+[#2846]: https://github.com/sigp/lighthouse/pull/2846
+
+Prior to the introduction of [#2682][] and [#2846][] (releases v2.0.1 and earlier), Lighthouse would
+not correctly parse relative paths from the `lighthouse bn --datadir` flag.
+
+If the user provided a relative path (e.g., `--datadir here` or `--datadir ./here`), the `beacon`
+directory would be split across two paths:
+
+1. `~/here` (in the *home directory*), containing:
+    - `chain_db`
+    - `freezer_db`
+1. `./here` (in the *present working directory*), containing:
+    - `logs`
+    - `network`
+
+All versions released after the fix ([#2846][]) will default to storing all files in the present
+working directory (i.e. `./here`). New users need not be concerned with the old behaviour.
+
+For existing users which already have a split data directory, a backwards compatibility feature will
+be applied. On start-up, if a split directory scenario is detected (i.e. `~/here` exists),
+Lighthouse will continue to operate with split directories. In such a scenario, the following
+harmless log will show:
+
+```
+WARN Legacy datadir location    location: "/home/user/datadir/beacon", msg: this occurs when using relative paths for a datadir location
+```
+
+In this case, the user could solve this warn by following these steps:
+
+1. Stopping the BN process
+1. Consolidating the legacy directory with the new one:
+    - `mv /home/user/datadir/beacon/* $(pwd)/datadir/beacon`
+    - Where `$(pwd)` is the present working directory for the Lighthouse binary
+1. Removing the legacy directory:
+    - `rm -r /home/user/datadir/beacon`
+1. Restarting the BN process
+
+Although there are no known issues with using backwards compatibility functionality, having split
+directories is likely to cause confusion for users. Therefore, we recommend affected users migrate
+to a consolidated directory structure.