Merge pull request #313716 from MicrosoftDocs/main

Auto Publish – main to live - 2026-03-26 11:00 UTC

Author: learn-build-service-prod[bot]

articles/automation/automation-hrw-run-runbooks.md

@@ -16,10 +16,7 @@ author: RochakSingh-blr
 
 > [!IMPORTANT]
 > - Starting 1st April 2025, all jobs running on agent-based Hybrid Worker will be stopped. 
-> - Azure Automation Agent-based User Hybrid Runbook Worker (Windows and Linux) has retired on **31 August 2024** and is no longer supported. Follow the guidelines on how to [migrate from an existing Agent-based User Hybrid Runbook Workers to Extension-based Hybrid Workers](migrate-existing-agent-based-hybrid-worker-to-extension-based-workers.md).
-
-> [!NOTE]
-> Azure Automation Run As Account has retired on September 30, 2023 and is replaced with Managed Identities. Follow the guidelines on [how to start migrating your runbooks to use managed identities](automation-security-overview.md#managed-identities). For more information, see [migrating from an existing Run As accounts to managed identity](migrate-run-as-accounts-managed-identity.md#sample-scripts).
+> - Azure Automation Agent-based User Hybrid Runbook Worker (Windows and Linux) has retired on **31 August 2024** and is no longer supported. Follow the guidelines on how to [migrate from an existing Agent-based User Hybrid Runbook Workers to Extension-based Hybrid Workers](migrate-existing-agent-based-hybrid-worker-to-extension-based-workers.md)
 
 
 Runbooks that run on a [Hybrid Runbook Worker](automation-hybrid-runbook-worker.md) typically manage resources on the local computer or against resources in the local environment where the worker is deployed. Runbooks in Azure Automation typically manage resources in the Azure cloud. Even though they are used differently, runbooks that run in Azure Automation and runbooks that run on a Hybrid Runbook Worker are identical in structure.
@@ -96,7 +93,7 @@ If the *Python* executable file is at the default location *C:\Python27\python.e
 
 > [!NOTE]
 >- PowerShell 7.4 and Python 3.10 runbooks are supported on extension-based Linux Hybrid Workers only. Ensure the Linux Hybrid worker extension version is 1.1.23 or above.
->- PowerShell 5.1, PowerShell 7.1 (preview), Python 2.7, Python 3.8 runbooks are supported on both extension-based and agent-based Linux Hybrid Runbook Workers. For agent-based workers, ensure the Linux Hybrid Runbook worker version is 1.7.5.0 or above.
+>- PowerShell 7.1 (preview), Python 2.7, Python 3.8 runbooks are supported on both extension-based and agent-based Linux Hybrid Runbook Workers. For agent-based workers, ensure the Linux Hybrid Runbook worker version is 1.7.5.0 or above.
 >- PowerShell 7.2 runbook is supported on extension-based Linux Hybrid Workers only. Ensure the Linux Hybrid worker extension version is 1.1.11 or above.
 
 #### Extension-based Hybrid Workers

articles/migrate/assessment-prerequisites.md

@@ -34,5 +34,14 @@ The recommended discovery source is the Azure Migrate appliance as it provides a
 
 If you're using the Azure Migrate appliance for assessment, see [metadata and performance data](discovered-metadata.md) collected as an input for the assessment. 
 
+## Tag workloads correctly
+
+It is recommended to correctly tag all the servers and workloads for appropriate target recommendations. Assessment uses special tags for identifying the machines and workloads operating in the Dev/Test environment and to mark the workloads and servers for retention or retirement. 
+
+In case the workloads and servers are operating in the Dev/Test environment they should be tagged with the tag **AzM.Environment: Dev**. In case this tag is absent on the servers or workloads, they are considered as production workloads by default. 
+
+In case the workloads and servers are to be retained or retired they should be tagged with the tag **AzM.MigrationIntent: Retain** or **AzM.MigrationIntent:Retire** respectively. In case these tags are absent on these servers or workloads, they are considered for migration or modernization. 
+It is recommended that the servers and all the associated workloads are tagged consistently for appropriate and consistent recommendations. For eg. In case *Server 1* hosts *Database 1* and *Database 2* and the server has to be retained, it is expected that the tag exists on server as well as the databases for appropriate recommendation. 
+
 ## Next steps
 Migrate [VMware VMs](tutorial-migrate-vmware.md), [Hyper-V VMs](tutorial-migrate-hyper-v.md), and [physical servers](tutorial-migrate-physical-virtual-machines.md).

articles/migrate/assessment-report.md

@@ -48,9 +48,6 @@ If you want to pick the peak usage for the period and don't want to miss any out
 
 This value is multiplied by the comfort factor(taken as an input in assessment setting) to get the effective performance utilization data for these metrics that the appliance collects and right size the target requirements. 
 
->[!Note] 
->Azure SQL assessments are only performance-based and Webapp assessments are only As-is on premises. You can create Azure VM assessments and AVS assessments with both performance-based and As-is on premises sizing. 
-
 ### Monthly costs 
 
 After right-sizing target candidates are selected, and if more than one suitable candidate is available the recommended target is selected based on selected migration strategy. By default **Minimizing the cost** is the selected strategy. In the case of Azure VM and AVS assessment that is the only strategy. Once the targets are finalized a monthly cost is calculated by aggregating the cost of all resources, licenses and ancillary services like security. Based on the selected input from assessment settings the prices and offer details are fetched to arrive at the final cost. Learn more [about how pricing](cost-estimation.md) works in Azure Migrate assessments. 

articles/migrate/concepts-business-case-calculation.md

@@ -73,19 +73,19 @@ Cost components for running on-premises servers. For TCO calculations, an annual
 |     | **Windows Server - Extended Security Update (ESU)** | License cost | Calculated for 3 years after the end of support of Windows server license: <br/><br/> ESU (Year 1) – 75% of the license cost <br/><br/> ESU (Year 2) – 100% of the license cost <br/><br/> ESU (Year 3) – 125% of the license cost <br/><br/>|
 |     |     | Software Assurance | Calculated per year as in settings. |
 |     | **Virtualization software for servers running in VMware environment** | Virtualization Software (VMware license cost) | License cost based on VMware Cloud Foundation licensing. |
-| **Storage** | **Storage Hardware** |     | The total storage hardware acquisition cost is calculated by multiplying the Total volume of storage attached to  per GB cost. Default is USD 2 per GB per month. |
+| **Storage** | **Storage Hardware** |     | The total storage hardware acquisition cost is calculated by multiplying the total volume of storage attached to per GB cost. Default is $2 per GB. |
 |     | **Storage Maintenance** |     | Default is 10% of storage hardware acquisition cost. |
-| **Network** | **Network Hardware and software** | Network equipment (Cabinets, switches, routers, load balancers etc.) and software | As an industry standard and used by sellers in Business cases, it's a % of compute and storage cost. Default is 10% of storage and compute cost. |
+| **Network** | **Network Hardware and software** |  Calculated based on the number of cabinets, routers required. Default cost per cabinet is $906 and default number of physical servers per cabinet are 16.  |
 |     | **Maintenance** | Maintenance | Defaulted to 15% of network hardware and software cost. |
 | **Security** | **General Servers** | Server security cost | Default is USD 250 per year per server. This is multiplied with number of servers (General servers) |
 |     | **SQL Servers** | SQL protection cost | Default is USD 1000 per year per server. This is multiplied with number of servers running SQL |
 | **Facilities** | **Facilities & Infrastructure** | DC Facilities - Lease and Power | The Facilities cost is based on a colocation model, which includes space, power, and lease costs per kWh.<br> Annual facilities cost = Total energy capacity * Average colocation costs * 12. (Assume 40% of datacenter energy capacity remains unused.) <br> Total energy capacity = Energy consumption by current workloads / (1 - unused energy capacity). <br>To determine energy consumption for your workloads: <br>- Compute resources: Total physical cores * On-Premises TDP (0.009 kWh per core) * Load factor (2.00) * On-Premises PUE (1.80).<br> - Storage resources: Total storage in TB * On-Premises storage power rating (10 kWh per TB) * Conversion factor (0.0001) * Load factor (2.00) * On-Premises PUE (1.80). |
-| **Labor** | **Labor** | IT admin | DC admin cost = ((Number of virtual machines) / (Avg. # of virtual machines that can be managed by a full-time administrator)) * 730 * 12 |
+| **Labor** | **Labor** | IT admin | DC admin cost = ((Number of virtual machines) / (Avg. # of virtual machines that can be managed by a full-time administrator)) * Average hourly rate for an IT administrator * Average yearly working hours  |
 | **Management** | **Management Software licensing** | System center Management software | Used for cost of the System center management software that includes monitoring, hardware and virtual machine provisioning, automation, backup and configuration management capabilities. Cost of Microsoft system center management software is added when the system center agents are identified on any of the discovered resources. This is applicable only for windows servers and SQL servers related scenarios and includes Software assurance. |
 |     |    | Other Management software | This is the cost of the management software for Partner management products. |
-|     | **Management cost other than software** | Monitoring cost | Specify costs other than monitoring software. Default is USD 430 per year per server. This is multiplied with the number of servers. The default used is the cost associated with a monitoring administrator. |
-|     |    | Patch Management cost | Specify costs other than patch management software. Default is USD 430 per year per server. This is multiplied with the number of servers. Default is the cost associated with a patch management administrator. |
-|     |    | Backup cost | Specify costs other than backup software. Default is USD 580 per year per server. This is multiplied with the number of servers. Default used includes the cost per server for a backup administrator and storage required locally for backup. |
+|     | **Management cost other than software** | Monitoring cost |  Specify costs other than monitoring software. Default is USD 145 per year per server. This is multiplied with the number of servers. The default used is the cost associated with a monitoring administrator.  |
+|     |    | Patch Management cost | Specify costs other than patch management software. Default is USD 145 per year per server. This is multiplied with the number of servers. Default is the cost associated with a patch management administrator.  |
+|     |    | Backup cost | There are 2 components for backup cost. Default backup admin cost is USD 145 per server. Backup cost on-premises also includes a per GB backup cost as $0.022 per GB. Backup costs are only applied to Prod servers. |
 
 ### TCO (steady state): Azure cost
 

articles/migrate/how-to-view-a-business-case.md

@@ -102,53 +102,17 @@ This report contains detailed insights about the Azure costs for the application
     - **Rehost**: Covers costs of applications and workloads rehosted to targets such as Azure VM or SQL server on Azure VM. 
     - **Replatform**: Covers costs of applications and workloads replatformed to targets such as Azure SQL MI or App service. 
     - **Refactor**: Covers costs of applications and workloads refactored to Azure native-PaaS and serverless services.
+    - **Retain**: Covers costs of Arc enabling applications and workloads retained in their current state, without migration or modernization to Azure. 
+    - **Retire**: Covers savings from applications and workloads planned for retirement, where the workload is decommissioned. 
+
 - Cost details by Azure target:
 
-    - **Infrastructure cost**: This card shows cost split of applications and workloads moving to infrastructure targets (eg. Azure Virtual Machines, SQL server on Azure VM etc.).
+    - **Infrastructure cost**: This card shows cost split of applications and workloads moving to infrastructure targets (eg. Azure Virtual Machines, Azure VMware Solution, SQL server on Azure Virtual Machine etc.). 
     - **Database cost**: This card shows cost of application workloads moving to database targets on Azure (eg. Azure SQL DB/MI, Azure Database for MySQL).
     - **Webapps cost**: This card shows cost of application workloads moving to Webapp targets on Azure (eg. App service, AKS etc.).
 
 ---
 
-## On-premises vs AVS report
-It covers cost components for on-premises and AVS, savings, and insights to understand the savings better.
-:::image type="content" source="./media/how-to-view-a-business-case/comparison-avs-inline.png" alt-text="Screenshot of on-premises and AVS comparison." lightbox="./media/how-to-view-a-business-case/comparison-avs-expanded.png":::
-
-## AVS report
-
-#### [AVS (Azure VMware Solution)](#tab/avs-azure)
-
-This section contains the cost estimate by recommended target (Annual cost includes Compute, Storage, Network, labor components) and savings from Hybrid benefits.
-
-#### AVS cost estimate
-
-**Estimated AVS cost**:  This card includes the total cost of ownership for hosting all workloads on AVS including the AVS nodes cost (which includes storage cost), networking, and labor cost. The node cost is computed by taking the most cost optimum AVS node SKU. The infrastructure settings used are as follows:
-    
-- The number and SKU of AVS hosts used in a business case aligns to the SKUs available in the given region and optimized to use the least number of nodes required to host all VMs ready to be migrated.
-- Azure NetApp File (ANF) is used when it can be used to optimize the number of AVS hosts required. ANF Standard tier is used when the VMs have been imported using RVTools. For an Azure Migrate appliance-based business case, the tier of ANF used in the business case depends on the IOPS & throughput data for VMs. 
-    - CPU over-subscription of 4:1
-    - Memory overcommits of 100% 
-    - Compression and deduplication factor of 1.5. You can learn more about this [here](concepts-azure-vmware-solution-assessment-calculation.md#whats-in-an-azure-vmware-solution-assessment). 
-
-**Compute and license cost**: This card shows the comparison of compute and license cost when using Azure hybrid benefit and without Azure hybrid benefit. 
-
-#### Savings and optimization:
-    
-**Savings with 3-year RI**: This card shows the node cost with 3-year RI.
-
-**Savings with Azure Hybrid Benefit & Extended Security Updates**: This card displays the estimated maximum savings when using Azure hybrid benefit and with extended security updates over a period of one year.
-
-:::image type="content" source="./media/how-to-view-a-business-case/avs-estimation-inline.png" alt-text="Screenshot of AVS estimation." lightbox="./media/how-to-view-a-business-case/avs-estimation-expanded.png":::
-
-#### [On-premises](#tab/avs-on-premises)
-
-- On-premises footprint of the servers recommended to be migrated to AVS.
-- Contribution of Zombie servers in the on-premises cost.
-- Distribution of servers by OS, virtualization, and activity state.
-- Distribution by support status of OS licenses and OS versions. 
-
----
-
 ## On-premises with Azure Arc report 
 This section contains the cost and savings estimate by Arc-enabling your on-premises estate: