Updating documentation

docs/content/patterns/alz/UpdateToNewReleases/Update_from_release_2023-11-14.md → docs/content/patterns/alz/UpdateToNewReleases/Update_to_release_2024-03-01.md

@@ -1,12 +1,12 @@
 ---
-title: Updating from release 2023-11-14
+title: Updating to release 2024-03-01
 geekdocCollapseSection: true
 weight: 100
 ---
 
 ## Post update actions
 
-Updating from release [2023-11-14](../../Whats-New#2023-11-14) will require running a post update script to remove the old Service Health action group(s) no longer in use.
+Updating to release [2024-03-01](../../Whats-New#2024-03-01) will require running a post update script to remove the old Service Health action group(s) no longer in use.
 
   To run the script, follow the following instructions:
 

docs/content/patterns/alz/UpdateToNewReleases/Update_from_release_2024-03-01.md → docs/content/patterns/alz/UpdateToNewReleases/Update_to_release_2024-04-12.md

@@ -1,5 +1,5 @@
 ---
-title: Updating from release 2024-03-01
+title: Updating to release 2024-04-12
 geekdocCollapseSection: true
 weight: 99
 ---
@@ -9,7 +9,7 @@ weight: 99
 
 # Post update actions
 
-Updating from release [2024-03-01](../../Whats-New#2024-03-01) might require running a post update script to remove the notification assets deployed by ALZ pattern <ins>***if and only if***</ins> customer decided to use existing action groups and alert processing rule. In this case, the Service Health alerts will be reconfigured to use the customer' action groups as per the _**B**ring **Y**our **O**wn **N**otifications_ (BYON) feature.
+Updating to release [2024-04-12](../../Whats-New#2024-04-12) might require running a post update script to remove the notification assets deployed by ALZ pattern <ins>***if and only if***</ins> customer decided to use existing action groups and alert processing rule. In this case, the Service Health alerts will be reconfigured to use the customer' action groups as per the _**B**ring **Y**our **O**wn **N**otifications_ (BYON) feature.
 
 To run the script, complete the following step:
 

docs/content/patterns/alz/UpdateToNewReleases/Update_from_release_2024-04-12.md → docs/content/patterns/alz/UpdateToNewReleases/Update_to_release_2024-06-05.md

@@ -1,5 +1,5 @@
 ---
-title: Updating from release 2024-04-12
+title: Updating to release 2024-06-05
 geekdocCollapseSection: true
 weight: 98
 ---
@@ -9,7 +9,7 @@ weight: 98
 
 # Pre update actions
 
-The parameter file structure has changed to accommodate a new feature coming soon. For this reason, updating from release [2024-04-12](../../Whats-New#2024-04-12) requires the alignment of the parameter file structure you have been using so far with the new one coming with the release.
+The parameter file structure has changed to accommodate a new feature coming soon. For this reason, updating from release [2024-06-05](../../Whats-New#2024-06-05) requires the alignment of the parameter file structure you have been using so far with the new one coming with the release.
 
 In particular the new parameter file has the following differences:
 

docs/content/patterns/alz/UpdateToNewReleases/Update_from_release_2024-06-05.md → docs/content/patterns/alz/UpdateToNewReleases/Update_to_release_2024-09-02.md

@@ -1,15 +1,15 @@
 ---
-title: Updating from release 2024-06-05
+title: Updating to release 2024-09-02
 geekdocCollapseSection: true
 weight: 97
 ---
 {{< hint type=Important >}}
-***Updating to release from release [2024-06-05](../../Whats-New#2024-06-05) or from previous releases, contains a breaking change. To perform the update, it's required to remove previously deployed policy definitions, policy set definitions, policy assignments and role assignments. As part of this release we made a script available to clean all the necessary items. <ins>***It's strongly recommended that you test the script thoroughly before running on production environment. It isn't necessary to remove alert definitions that will continue to work in the meantime.***</ins>
+***Updating to release [2024-09-02](../../Whats-New#2024-09-02) from previous releases, contains a breaking change. To perform the update, it's required to remove previously deployed policy definitions, policy set definitions, policy assignments and role assignments. As part of this release we made a script available to clean all the necessary items. <ins>***It's strongly recommended that you test the script thoroughly before running on production environment. It isn't necessary to remove alert definitions that will continue to work in the meantime.***</ins>
 {{< /hint >}}
 
 # Pre update actions
 
-Before updating to release [2024-06-05](../../Whats-New#2024-06-05), it's required to remove existing policy definitions, policy set definitions, policy assignments and role assignments. This action is required because of a breaking change caused by the redefinition of some parameters, which allows for more flexibility in disabling the policy remediation or, in some cases, the alerts. Unfortunately not all the alerts can be disabled after creation; only log-based alerts can be. Even if disabling the effect of policy was already possible in AMBA-ALZ, with this release we made sure that all the policies will honor both the ***PolicyEffect*** and the ***MonitorDisable*** parameters.
+Before updating to release [2024-09-02](../../Whats-New#2024-09-02), it's required to remove existing policy definitions, policy set definitions, policy assignments and role assignments. This action is required because of a breaking change caused by the redefinition of some parameters, which allows for more flexibility in disabling the policy remediation or, in some cases, the alerts. Unfortunately not all the alerts can be disabled after creation; only log-based alerts can be. Even if disabling the effect of policy was already possible in AMBA-ALZ, with this release we made sure that all the policies will honor both the ***PolicyEffect*** and the ***MonitorDisable*** parameters.
 
 In particular, the *MonitorDisable* feature has been redesigned to allow customer to specify they own existing tag and tag value instead of forcing a hard coded one. Given the ALZ guidance and the best practice of having a consistent tagging definition, it's only allowed to one parameter name fo r the entire deployment. Instead, parameter value can be different. You can specify an array of values assigned to the same parameter. For instance, you have the ```Environment``` tag name consistently applied to several environments, saying ```Production```, ```Test```, ```Sandbox```, and so on and you want to disable alerts for resources, which are in both ```Test``` and ```Sandbox```. Now it's possible by just configuring the parameters for tag name and tag values as reported in the sample screenshot (these are the default values) below:
 

docs/content/patterns/alz/UpdateToNewReleases/_index.md

@@ -71,9 +71,9 @@ Within the code editor of your choice, make sure you pull the changes from your
 
 ### Check for detailed requirement when updating to a newer release (always required)
 
-Check the content of the page corresponding to the release you are updating from, to see if there's any pre or post deployment action required. For instance, if you're updating from release **2023-11-14**, check the page called ***Updating from release 2023-11-14***
+Check the content of the page corresponding to the release you are updating to, to see if there's any pre or post deployment action required. For instance, if you're updating to release **2024-04-12**, check the page called ***Updating to release 2024-04-12***
 
-  ![Updating from release](../media/UpdatingFromRelease.png)
+  ![Updating from release](../media/UpdatingToRelease.png)
 
 ### Update the parameter file with any new parameter and configuration