Migrate Prometheus rule delivery separately from scrape configuration

Source facts

Azure Managed Prometheus does not support the PrometheusRule custom resource. Existing alerting and recording rules instead use Azure Prometheus rule groups, with Microsoft documenting conversion to an Azure Resource Manager template. Migrating pod and service monitors also requires changing their apiVersion to azmonitoring.coreos.com/v1. Successfully transferring collection configuration therefore does not by itself complete rule migration. Microsoft Learn.

Applicability

Use this distinction when an existing Prometheus deployment relies on Kubernetes custom resources for both scraping and rules. Inventory what the current configuration actually deploys rather than treating every resource in the same repository as equivalent.

DSE recommendation

Track scrape configuration and alerting or recording-rule delivery as separate migration work items. Have the monitoring owner identify each rule that must survive and its intended destination rule group. Keep the collection owner responsible for the supported monitor definitions, while assigning a named reviewer to the converted alert and recording logic. Do not remove the old rule-delivery path solely because metrics are visible in the new workspace.

Verification

In the migration pilot, confirm representative targets are scraped and their expected metrics can be queried. Separately inspect the deployed rule inventory and exercise an approved alert workflow. Compare recording-rule outputs that downstream dashboards or alerts depend on. Preserve the mapping from the original rule object to the deployed Azure resource, including deliberate omissions, so a successful scrape is not mistaken for complete alerting coverage.

Official references

Microsoft Learn: Migrate self-hosted Prometheus. Source reviewed September 9, 2026.