Merge pull request #311785 from Jeronika-MS/asrf

Updated docs for freshness-ASR

Author: Carolyn135

articles/site-recovery/how-to-migrate-run-as-accounts-managed-identity.md

@@ -4,37 +4,38 @@ description: This article describes how to migrate from a Run As account to a ma
 author: Jeronika-MS
 ms.service: azure-site-recovery
 ms.author: v-gajeronika
-ms.topic: how-to 
-ms.date: 04/29/2024
+ms.reviewer: v-gajeronika
+ms.topic: how-to
+ms.date: 02/13/2026
 ms.custom: sfi-image-nochange
 # Customer intent: As an Azure administrator, I want to migrate from a Run As account to a managed identity so that I can enhance security and simplify credential management in Azure Site Recovery.
 ---
 
 # Migrate from a Run As account to Managed Identities 
 
 > [!IMPORTANT]
-> - Azure Automation Run As Account was retired on September 30, 2023 and is replaced by Managed Identities. We recommend to start migrating your runbooks to use managed identities. For more information, see [migrating from an existing Run As accounts to managed identity](../automation/automation-managed-identity-faq.md).
-> - Delaying the feature has a direct impact on our support burden, as it would cause upgrades of mobility agent to fail.
+> - Azure Automation Run As Account was retired on September 30, 2023 and is replaced by Managed Identities. Start migrating your runbooks to use managed identities. For more information, see [migrating from an existing Run As accounts to managed identity](../automation/automation-managed-identity-faq.md).
+> - Delaying the feature has a direct impact on our support burden, as it causes upgrades of mobility agent to fail.
 
 This article shows you how to migrate your runbooks to use a Managed Identities for Azure Site Recovery. Azure Automation Accounts are used by Azure Site Recovery customers to auto-update the agents of their protected virtual machines. Site Recovery creates Azure Automation Run As Accounts when you enable replication via the IaaS VM Blade and Recovery Services Vault. 
 
-On Azure, managed identities eliminate the need for developers having to manage credentials by providing an identity for the Azure resource in Microsoft Entra ID and using it to obtain Microsoft Entra tokens. 
+On Azure, managed identities eliminate the need for developers to manage credentials by providing an identity for the Azure resource in Microsoft Entra ID and using it to obtain Microsoft Entra tokens. 
 
 ## Prerequisites
 
 Before you migrate from a Run As account to a managed identity, ensure that you have the appropriate roles to create a system-assigned identity for your automation account and to assign it the *Owner* role in the corresponding recovery services vault.
 
 > [!NOTE]
-> You can use the same automation account across multiple recovery services vaults, however, both the automation account and recovery services vault should be in the same region.
+> You can use the same automation account across multiple recovery services vaults. However, both the automation account and recovery services vault should be in the same region.
 
 ## Benefits of managed identities
 
 Here are some of the benefits of using managed identities:
 
 - **Credentials access** - You don't need to manage credentials.
-- **Simplified authentication** - You can use managed identities to authenticate to any resource that supports Microsoft Entra authentication including your own applications.
-- **Cost effective** - Managed identities can be used at no extra cost.
--  **Double encryption** - Managed identity is also used to encrypt/decrypt data and metadata using the customer-managed key stored in Azure Key Vault, providing double encryption.
+- **Simplified authentication** - You can use managed identities to authenticate to any resource that supports Microsoft Entra authentication, including your own applications.
+- **Cost effective** - Use managed identities at no extra cost.
+-  **Double encryption** - Managed identity is also used to encrypt and decrypt data and metadata by using the customer-managed key stored in Azure Key Vault, providing double encryption.
 
 > [!NOTE]
 > Managed identities for Azure resources is the new name for the service formerly known as Managed Service Identity (MSI).
@@ -60,21 +61,21 @@ You can configure your managed identities through:
 
 1. In the [Azure portal](https://portal.azure.com), select the recovery services vault for which you want to migrate the runbooks.
 
-1. On the homepage of your recovery services vault page, do the following:
+1. On the homepage of your recovery services vault, complete the following:
     1. On the left pane, under **Manage**, select **Site Recovery infrastructure**.
         :::image type="content" source="./media/how-to-migrate-from-run-as-to-managed-identities/manage-section.png" alt-text="Screenshot of the **Site Recovery infrastructure** page.":::
     1. Under **For Azure virtual machines**, select **Extension update settings**.
-     This page details the authentication type for the automation account that is being used to manage the Site Recovery extensions.
+     This page shows the authentication type for the automation account that manages the Site Recovery extensions.
 
-    1. On this page, select **Migrate** to migrate the authentication type for your automation accounts to use Managed Identities. 
+    1. Select **Migrate** to change the authentication type for your automation accounts to use Managed Identities. 
 
         :::image type="content" source="./media/how-to-migrate-from-run-as-to-managed-identities/extension-update-settings.png" alt-text="Screenshot of the Create Recovery Services vault page.":::
 
 
 > [!NOTE]
-> Ensure that the System assigned Managed Identity is turned off for the Automation account for the _"Migrate"_ button to appear. If the account is not migrated and the _"Migrate"_ button isn't appearing, turn off the Managed Identity for the Automation Account and try again.
+> The **Migrate** button appears only if the System assigned Managed Identity is turned off for the Automation account. If the account isn't migrated and the **Migrate** button isn't appearing, turn off the Managed Identity for the Automation Account and try again.
 
-3. After the successful migration of your automation account, the authentication type for the linked account details on the **Extension update settings** page is updated.
+1. After you successfully migrate your automation account, the authentication type for the linked account details on the **Extension update settings** page is updated.
 1. Once the _Migrate_ operation is completed, toggle the **Site Recovery to manage** button to turn it _On_ again.
 
 When you successfully migrate from a Run As to a Managed Identities account, the following changes are reflected on the Automation Run As Accounts :
@@ -86,11 +87,11 @@ When you successfully migrate from a Run As to a Managed Identities account, the
 
 ### Link an existing managed identity account to vault
 
-To link an existing managed identity Automation account to your Recovery Services vault. Follow these steps:
+To link an existing managed identity Automation account to your Recovery Services vault, follow these steps:
 
 #### Enable the managed identity for the vault
 
-1. Go to the automation account that you have selected. Under **Account settings**, select **Identity**.
+1. Go to the automation account that you selected. Under **Account settings**, select **Identity**.
 
    :::image type="content" source="./media/how-to-migrate-from-run-as-to-managed-identities/mi-automation-account.png" alt-text="Screenshot that shows the identity settings page.":::
 
@@ -104,9 +105,9 @@ To link an existing managed identity Automation account to your Recovery Service
     :::image type="content" source="./media/how-to-migrate-from-run-as-to-managed-identities/add-mi-iam.png" alt-text="Screenshot that shows IAM settings page.":::
 1. Select **Add** > **Add role assignment** > **Contributor** to open the **Add role assignment** page.
     > [!NOTE]
-    > Once the automation account is set, you can change the role of the account from *Contributor* to *Site Recovery Contributor*.
-1. On the **Add role assignment** page, ensure to select **Managed identity**.
-1. Select the **Select members**. In the **Select managed identities** pane, do the following:
+    > After you set the automation account, you can change the role of the account from *Contributor* to *Site Recovery Contributor*.
+1. On the **Add role assignment** page, select **Managed identity**.
+1. Select **Select members**. In the **Select managed identities** pane, do the following:
     1. In the **Select** field, enter the name of the managed identity automation account.
     1. In the **Managed identity** field, select **All system-assigned managed identities**.
     1. Select the **Select** option.

articles/site-recovery/how-to-move-from-classic-to-modernized-vmware-disaster-recovery.md

@@ -2,20 +2,21 @@
 title: How to move from classic to modernized VMware disaster recovery?
 description: This article describes how to move from classic to modernized VMware disaster recovery.
 ms.author: v-gajeronika
+ms.reviewer: v-gajeronika
 author: Jeronika-MS
 ms.service: azure-site-recovery
 ms.topic: how-to
-ms.date: 05/23/2024
+ms.date: 02/13/2026
 ms.custom: engagement-fy23
 # Customer intent: "As a VMware administrator, I want to migrate replicated items from classic to modernized disaster recovery architecture, so that I can benefit from enhanced protection and efficiency without redoing the entire replication process."
 ---
 
 # How to move from classic to modernized VMware disaster recovery  
 
-This article provides information about how you can move/migrate your VMware or Physical machine replications from [classic](./vmware-azure-architecture.md) to [modernized](./vmware-azure-architecture-modernized.md) protection architecture. With this capability to migrate, you can successfully transfer your replicated items from a configuration server to an Azure Site Recovery replication appliance. This migration is guided by a smart replication mechanism, which ensures that the complete initial replication is not performed again for noncritical replicated items, and only the differential data is transferred. 
+This article explains how to move or migrate your VMware or physical machine replications from [classic](./vmware-azure-architecture.md) to [modernized](./vmware-azure-architecture-modernized.md) protection architecture. By using this migration capability, you can transfer your replicated items from a configuration server to an Azure Site Recovery replication appliance. A smart replication mechanism guides this migration. It ensures that the complete initial replication isn't performed again for noncritical replicated items, and only the differential data is transferred. 
 
 > [!NOTE]
-> - Recovery plans is not migrated and must be created again in the modernized Recovery Services vault.   
+> - Recovery plans aren't migrated and must be created again in the modernized Recovery Services vault.   
 
 ## Prerequisites  
 
@@ -27,47 +28,47 @@ This article provides information about how you can move/migrate your VMware or
 
 Follow these steps to move the replicated items from classic architecture to modernized architecture: 
 
-1. Navigate to the classic Recovery Services vault and open **Replicated items**.
+1. Go to the classic Recovery Services vault and open **Replicated items**.
 
    :::image type="Replicated items" source="media/migrate-tool/replicated-items-inline.png" alt-text="Screenshot showing replicated items." lightbox="media/migrate-tool/replicated-items-expanded.png":::
 
-2. Select **Upgrade to modernized VMware replication**. The **Pre-requisites** details are displayed. Ensure you read through the prerequisites and then select **Next** to proceed to configure the migration settings.
+1. Select **Upgrade to modernized VMware replication**. The portal displays the **Pre-requisites** details. Make sure you read through the prerequisites and then select **Next** to proceed to configure the migration settings.
 
     :::image type="Prerequisites" source="media/migrate-tool/prerequisites-inline.png" alt-text="Screenshot showing prerequisites." lightbox="media/migrate-tool/prerequisites-expanded.png":::
 
-3. Select the modernized vault you plan to move to, machines from the current vault, which is moved to the modernized vault and an appliance for each of them.
+1. Select the modernized vault you plan to move to, machines from the current vault, which is moved to the modernized vault, and an appliance for each of them.
 
    :::image type="Migration settings" source="media/migrate-tool/migration-settings-inline.png" alt-text="Screenshot showing migration settings." lightbox="media/migrate-tool/migration-settings-expanded.png":::
 
-4. Select **Next** to review and make sure to check **Maximum migration time**.
+1. Select **Next** to review and make sure to check **Maximum migration time**.
 
-5. Select **I understand the risk. Proceed to move selected replicated item(s)** check box.  
+1. Select **I understand the risk. Proceed to move selected replicated item(s)** check box.  
 
    :::image type="review" source="media/migrate-tool/review-inline.png" alt-text="Screenshot showing review." lightbox="media/migrate-tool/review-expanded.png":::
 
-6. Select **Migrate**.
+1. Select **Migrate**.
 
-7. You can monitor the migration jobs in the **Site Recovery jobs** section of the vault.  
+1. You can monitor the migration jobs in the **Site Recovery jobs** section of the vault.  
 
 ## Allowed actions during migration and post migration  
 
 ### During the migration of machines   
 
-During the migration of a replicated item, continuous replication may get broken for some time. Replication continues as soon as the migration is complete. During migration, you are allowed to do **Failover** operation. The last available recovery point is present for selection and can be chosen for replication.   
+During the migration of a replicated item, continuous replication might stop temporarily. Replication resumes as soon as the migration finishes. During migration, you can initiate the **Failover** operation. You can select the last available recovery point for replication.   
 
-While the migration is in progress, you can only perform **Failover** operation. Once the migration is complete, data starts replicating using the modernized architecture and the new vault. All the operations are available for you to perform from the new vault.   
+While the migration is in progress, you can only perform the **Failover** operation. After the migration finishes, data starts replicating by using the modernized architecture and the new vault. You can perform all operations from the new vault.   
 
 > [!NOTE]
-> If the migration fails, Site Recovery automatically rolls back the changes and ensures the replication starts again from the classic vault.   
+> If the migration fails, Site Recovery automatically rolls back the changes and ensures replication starts again from the classic vault.   
 
-### Post migration operations from Classic vault  
+### Post migration operations from classic vault  
 
-**Failover** and **Disable replication** operations continue to be available from the classic vault even after migration is performed successfully. The classic vault continues to exist until the retention period of last available recovery point has expired. Once the retention period is up, the vault is cleaned up automatically. During this time, recovery points from both the vaults can be used for failover. It depends on your failover needs to select a proper recovery point.  
+**Failover** and **Disable replication** operations continue to be available from the classic vault even after migration is performed successfully. The classic vault continues to exist until the retention period of last available recovery point has expired. Once the retention period is up, the vault is cleaned up automatically. During this time, recovery points from both the vaults can be used for failover. It depends on your failover needs to select a proper recovery point.    
 
 You can continue to get charged for the retention points until the deletion of classic vault, . Once the deletion is done, no charge is associated to the classic vault.  
 
-After migration, if the failover is performed using the classic vault, then the replicated items present in the modernized vault is automatically cleaned up. Once done, all the further operations, such as commit, reprotect, failback, is only possible via the classic vault.   
+After migration, if you perform failover by using the classic vault, the replicated items in the modernized vault are automatically cleaned up. After this cleanup, you can perform all further operations, such as commit, reprotect, and failback, only through the classic vault.   
 
 ## Next steps
 
--  Learn to [move from classic to modernized VMware disaster recovery](move-from-classic-to-modernized-vmware-disaster-recovery.md).
+-  Learn how to [move from classic to modernized VMware disaster recovery](move-from-classic-to-modernized-vmware-disaster-recovery.md).