Documentation Updates

Why these changes are being introduced:
After much testing, this captures the latest understanding of how to
manage the installation of new premium plugins (e.g., those plugins
that require a license key and that might make changes to the database).

How this addresses that need:
* Minor edits to old migration document
* Update the How-To document for installing new premium plugins based
on the experience in Dev1 and Stage-Workloads for the current attempt

Side effects of this change:
None.

Relevant ticket(s):
* https://mitlibraries.atlassian.net/browse/INFRA-517

Author: cabutlermit

docs/HowTos/HOWTO-migrate-from-legacy-AWS.md

@@ -21,12 +21,12 @@ Before getting started, make sure that you have access to the `root` password fo
 
 ### Legacy AWS
 
-In the legacy Stage/Prod account, log in to the `efs-access-matomo-<env>` EC2 instance (`<env>` is either `stage` or `prod` depending on the database being backed up). Requires AWS CLI v2, AWS Session-Manager Plugin for AWSCLI.
+In the legacy Stage/Prod account, log in to the `matomo-efs-mgmt` EC2 instance (`<env>` is either `stage` or `prod` depending on the database being backed up). Requires AWS CLI v2, AWS Session-Manager Plugin for AWSCLI.
 
 To capture the InstanceID of the EC2 instance to connect to, run the following command:
 
 ```bash
-aws ec2 describe-instances --filters "Name=tag:Name,Values=efs-access-matomo-<env>" --query "Reservations[*].Instances[*].[InstanceId]" --output text
+aws ec2 describe-instances --filters "Name=tag:Name,Values=matomo-efs-mgmt" --query "Reservations[*].Instances[*].[InstanceId]" --output text
 ```
 
 To capture the RDS_ENDPOINT for the database, run the following command:

docs/HowTos/HOWTO-premium-plugins.md

@@ -23,7 +23,7 @@ In the end, the premium plugin installation is a two-pass process.
 ### High level overview
 
 1. Install license key (via UI or CLI) so that it is in the database.
-2. Go through a dev -> stage -> prod deployment cycle of the container to install the plugin folder(s) into the container and update the `config.ini.php` file with new line(s) in the `[PluginsInstalled]` section.
+2. Go through a dev -> stage -> prod deployment cycle of the container to install the plugin folder(s) into the container.
 3. Activate the new plugin(s) (via UI or CLI) so that any database changes are properly executed.
 4. Go through a dev -> stage -> prod deployment cycle of the container to match the updated `config.ini.php` file on the server.
 
@@ -41,20 +41,20 @@ According to the support team at Matomo, the premium license key can be installe
 
 This needs to be done on each of the stage & prod instances of Matomo.
 
-#### 2. Install plugin
+#### 2. Install the plugin files
 
-In this phase, the files are installed in the container and the `config.ini.php` is updated to match the installation. This will **not** activate the plugins, it will just make them visible in the UI. The only new lines in the `config.ini.php` should be in the `[PluginsInstalled]` section.
+In this phase, the files are installed in the container *but no changes are made to the `config.ini.php` file. This will **not** activate the plugins, it will just make them visible in the UI.
 
-#### 3. Activate plugin
+#### 3. Activate the plugin
 
-Once the plugin is installed, it's time to activate it. In the UI, it's just a matter of clicking the `Activate` link for the plugin. For the CLI, the command is
+Once the plugin files are installed in the container, it's time to activate the plugin. In the UI, it's just a matter of clicking the `Activate` link for the plugin. For the CLI, the command is
 
 ```bash
 ./console plugin:activate [<plugin>...]
 ```
 
 This will change the `config.ini.php` file on the container. It is **very** important to capture these changes and put them back in the `config.ini.php` in the container (see step 4).
 
-#### 4. Deploy new config.ini.php
+#### 4. Backfill this repo
 
-After capturing the changes to `config.ini.php`, go through another round of dev -> stage -> prod deploys.
+Update the `config.ini.php` file in this repo and go through another dev -> stage -> prod deployment to ensure that the repo code matches the container running in AWS.