Docs: (EE Port) Second Attempt to realign administration/geo docs

doc/administration/geo/disaster_recovery/bring_primary_back.md

-# Bring a demoted primary node back online
+# Bring a demoted primary node back online **[PREMIUM ONLY]**
 
 After a failover, it is possible to fail back to the demoted **primary** node to
 restore your original configuration. This process consists of two steps:

doc/administration/geo/disaster_recovery/planned_failover.md

-# Disaster recovery for planned failover
+# Disaster recovery for planned failover **[PREMIUM ONLY]**
 
 The primary use-case of Disaster Recovery is to ensure business continuity in
 the event of unplanned outage, but it can be used in conjunction with a planned
@@ -113,7 +113,7 @@ If any objects are failing to replicate, this should be investigated before
 scheduling the maintenance window. Following a planned failover, anything that
 failed to replicate will be **lost**.
 
-You can use the [Geo status API](../../../api/geo_nodes.md#retrieve-project-sync-or-verification-failures-that-occurred-on-the-current-node) to review failed objects and
+You can use the [Geo status API](https://docs.gitlab.com/ee/api/geo_nodes.html#retrieve-project-sync-or-verification-failures-that-occurred-on-the-current-node) to review failed objects and
 the reasons for failure.
 
 A common cause of replication failures is the data being missing on the

doc/administration/geo/replication/configuration.md

-# Geo configuration (GitLab Omnibus)
+# Geo configuration (GitLab Omnibus) **[PREMIUM ONLY]**
 
 NOTE: **Note:**
 This is the documentation for the Omnibus GitLab packages. For installations

doc/administration/geo/replication/configuration_source.md

-# Geo configuration (source)
+# Geo configuration (source) **[PREMIUM ONLY]**
 
 NOTE: **Note:**
 This documentation applies to GitLab source installations. In GitLab 11.5, this documentation was deprecated and will be removed in a future release.

doc/administration/geo/replication/database.md

-# Geo database replication (GitLab Omnibus)
+# Geo database replication (GitLab Omnibus) **[PREMIUM ONLY]**
 
 NOTE: **Note:**
 This is the documentation for the Omnibus GitLab packages. For installations

doc/administration/geo/replication/database_source.md

-# Geo database replication (source)
+# Geo database replication (source) **[PREMIUM ONLY]**
 
 NOTE: **Note:**
 This documentation applies to GitLab source installations. In GitLab 11.5, this documentation was deprecated and will be removed in a future release.

doc/administration/geo/replication/docker_registry.md

-# Docker Registry for a secondary node
+# Docker Registry for a secondary node **[PREMIUM ONLY]**
 
 You can set up a [Docker Registry] on your
 **secondary** Geo node that mirrors the one on the **primary** Geo node.

doc/administration/geo/replication/external_database.md

-# Geo with external PostgreSQL instances
+# Geo with external PostgreSQL instances **[PREMIUM ONLY]**
 
 This document is relevant if you are using a PostgreSQL instance that is *not
 managed by Omnibus*. This includes cloud-managed instances like AWS RDS, or

doc/administration/geo/replication/faq.md

-# Geo Frequently Asked Questions
+# Geo Frequently Asked Questions **[PREMIUM ONLY]**
 
 ## What are the minimum requirements to run Geo?
 

doc/administration/geo/replication/high_availability.md

-# Geo High Availability
+# Geo High Availability **[PREMIUM ONLY]**
 
 This document describes a minimal reference architecture for running Geo
 in a high availability configuration. If your HA setup differs from the one
@@ -6,7 +6,7 @@ described, it is possible to adapt these instructions to your needs.
 
 ## Architecture overview
 
-![Geo HA Diagram](../../img/high_availability/geo-ha-diagram.png)
+![Geo HA Diagram](https://docs.gitlab.com/ee/administration/img/high_availability/geo-ha-diagram.png)
 
 _[diagram source - gitlab employees only][diagram-source]_
 
@@ -68,7 +68,7 @@ NOTE: **Note:** PostgreSQL and Redis should have already been disabled on the
 application servers, and connections from the application servers to those
 services on the backend servers configured, during normal GitLab HA set up. See
 high availability configuration documentation for
-[PostgreSQL](../../high_availability/database.md#configuring-the-application-nodes)
+[PostgreSQL](https://docs.gitlab.com/ee/administration/high_availability/database.html#configuring-the-application-nodes)
 and [Redis](../../high_availability/redis.md#example-configuration-for-the-gitlab-application).
 
 The **primary** database will require modification later, as part of

doc/administration/geo/replication/index.md

@@ -20,7 +20,9 @@ Geo provides local, read-only instances of your GitLab instances, reducing the t
 For a video introduction to Geo, see [Introduction to GitLab Geo - GitLab Features](https://www.youtube.com/watch?v=-HDLxSjEh6w).
 
 CAUTION: **Caution:**
-Geo undergoes significant changes from release to release. Upgrades **are** supported and [documented](#updating-geo), but you should ensure that you're using the right [version of the documentation](https://docs.gitlab.com/archives/) for your installation.
+Geo undergoes significant changes from release to release. Upgrades **are** supported and [documented](#updating-geo), but you should ensure that you're using the right version of the documentation for your installation.
+
+To make sure you're using the right version of the documentation, navigate to [the source version of this page on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/administration/geo/replication/index.md) and choose the appropriate release from the **Switch branch/tag** dropdown. For example, [`v11.2.3-ee`](https://gitlab.com/gitlab-org/gitlab-ee/blob/v11.2.3-ee/doc/administration/geo/replication/index.md).
 
 ## Use cases
 
@@ -177,7 +179,7 @@ The steps below should be followed in the order they appear. **Make sure the Git
 If you installed GitLab using the Omnibus packages (highly recommended):
 
 1. [Install GitLab Enterprise Edition](https://about.gitlab.com/installation/) on the server that will serve as the **secondary** node. Do not create an account or log in to the new **secondary** node.
-1. [Upload the GitLab License](../../../user/admin_area/license.md) on the **primary** node to unlock Geo. The license must be for [GitLab Premium](https://about.gitlab.com/pricing/) or higher.
+1. [Upload the GitLab License](https://docs.gitlab.com/ee/user/admin_area/license.html) on the **primary** node to unlock Geo. The license must be for [GitLab Premium](https://about.gitlab.com/pricing/) or higher.
 1. [Set up the database replication](database.md) (`primary (read-write) <-> secondary (read-only)` topology).
 1. [Configure fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md). This step is required and needs to be done on **both** the **primary** and **secondary** nodes.
 1. [Configure GitLab](configuration.md) to set the **primary** and **secondary** nodes.
@@ -192,7 +194,7 @@ In GitLab 11.5, support for using Geo in GitLab source installations was depreca
 If you installed GitLab from source:
 
 1. [Install GitLab Enterprise Edition](../../../install/installation.md) on the server that will serve as the **secondary** node. Do not create an account or log in to the new **secondary** node.
-1. [Upload the GitLab License](../../../user/admin_area/license.md) on the **primary** node to unlock Geo. The license must be for [GitLab Premium](https://about.gitlab.com/pricing/) or higher.
+1. [Upload the GitLab License](https://docs.gitlab.com/ee/user/admin_area/license.html) on the **primary** node to unlock Geo. The license must be for [GitLab Premium](https://about.gitlab.com/pricing/) or higher.
 1. [Set up the database replication](database_source.md) (`primary (read-write) <-> secondary (read-only)` topology).
 1. [Configure fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md). Do this step for **both** **primary** and **secondary** nodes.
 1. [Configure GitLab](configuration_source.md) to set the **primary** and **secondary** nodes.
@@ -276,7 +278,7 @@ Take special note that these examples of GitLab features are both:
 
 Examples include:
 
-- [Elasticsearch integration](../../../integration/elasticsearch.md).
+- [Elasticsearch integration](https://docs.gitlab.com/ee/integration/elasticsearch.html).
 - [Container Registry](../../container_registry.md). [Object Storage](object_storage.md) can mitigate this.
 - [GitLab Pages](../../pages/index.md).
 - [Mattermost integration](https://docs.gitlab.com/omnibus/gitlab-mattermost/).

doc/administration/geo/replication/object_storage.md

-# Geo with Object storage
+# Geo with Object storage **[PREMIUM ONLY]**
 
 Geo can be used in combination with Object Storage (AWS S3, or
 other compatible object storage).

doc/administration/geo/replication/remove_geo_node.md

-# Removing secondary Geo nodes
+# Removing secondary Geo nodes **[PREMIUM ONLY]**
 
 **Secondary** nodes can be removed from the Geo cluster using the Geo admin page of the **primary** node. To remove a **secondary** node:
 

doc/administration/geo/replication/security_review.md

-# Geo security review (Q&A)
+# Geo security review (Q&A) **[PREMIUM ONLY]**
 
 The following security review of the Geo feature set focuses on security
 aspects of the feature as they apply to customers running their own GitLab

doc/administration/geo/replication/troubleshooting.md

-# Geo Troubleshooting
+# Geo Troubleshooting **[PREMIUM ONLY]**
 
 NOTE: **Note:**
 This list is an attempt to document all the moving parts that can go wrong.

doc/administration/geo/replication/tuning.md

-# Tuning Geo
+# Tuning Geo **[PREMIUM ONLY]**
 
 ## Changing the sync capacity values
 
@@ -13,5 +13,5 @@ However, this may not lead to more downloads in parallel unless the number of
 available Sidekiq threads is also increased. For example, if repository sync
 capacity is increased from 25 to 50, you may also want to increase the number
 of Sidekiq threads from 25 to 50. See the
-[Sidekiq concurrency documentation](../../operations/extra_sidekiq_processes.html#number-of-threads)
+[Sidekiq concurrency documentation](https://docs.gitlab.com/ee/administration/operations/extra_sidekiq_processes.html#number-of-threads)
 for more details.

doc/administration/geo/replication/updating_the_geo_nodes.md

-# Updating the Geo nodes
+# Updating the Geo nodes **[PREMIUM ONLY]**
 
 Depending on which version of Geo you are updating to/from, there may be
 different steps.

doc/administration/geo/replication/using_a_geo_server.md

 [//]: # (Please update EE::GitLab::GeoGitAccess::GEO_SERVER_DOCS_URL if this file is moved)
 
-# Using a Geo Server
+# Using a Geo Server **[PREMIUM ONLY]**
 
 After you set up the [database replication and configure the Geo nodes][req], use your closest GitLab node as you would a normal standalone GitLab instance.