Loading source
Pulling the file list, source metadata, and syntax-aware rendering for this listing.
Source from repo
Assess and upgrade Azure workloads between plans, tiers, or SKUs with automated migration steps
Files
Skill
Size
Entrypoint
Format
Open file
Syntax-highlighted preview of this file as included in the skill package.
references/global-rules.md
1# Global Rules23These rules apply to ALL phases of the azure-upgrade skill.45## Destructive Action Policy67⛔ **NEVER** perform destructive actions without explicit user confirmation via `ask_user`:8- Deleting apps, services, or resource groups9- Stopping or disabling the original app/service10- Overwriting app settings or configuration in the new app11- Removing the original hosting plan or service tier12- Modifying DNS or custom domain bindings1314## User Confirmation Required1516Always use `ask_user` before:17- Selecting target Azure subscription18- Selecting target Azure region/location19- Creating new Azure resources20- Stopping or deleting the original app/service21- Modifying custom domains or network restrictions22- Any irreversible configuration change2324## Best Practices2526- Always use `mcp_azure_mcp_get_azure_bestpractices` tool before generating upgrade commands27- Prefer managed identity over connection strings — upgrades are a good time to improve security28- **Always target the latest supported runtime version** — check Azure docs for the newest GA version29- Keep the original app/service running until the upgraded one is fully validated30- Use the same resource group for the new resource to maintain access to existing dependencies31- Follow Azure naming conventions for all new resources3233## Identity-First Authentication (Zero API Keys)3435> Enterprise subscriptions commonly enforce policies that block local auth. Always design for identity-based access from the start.3637- Prefer managed identity connections over connection strings/keys38- Use `DefaultAzureCredential` in code — works locally and in Azure39- When using User Assigned Managed Identity, always pass `managedIdentityClientId` explicitly40- See service-specific identity configuration in the scenario reference files4142## Rollback Policy4344- Always document rollback steps before executing upgrade45- Keep the original app intact and running until upgrade is validated46- If upgrade fails, guide the user to restart the original app47- Never delete the original app automatically — always require `ask_user`48