Microsoft published updated guidance on moving eligible SQL Server workloads to pay-as-you-go licensing through Azure Arc on September 4, 2026.

The important message is operational: a commercial decision alone does not change how a SQL Server instance is billed. Each eligible resource needs the intended license configuration, Azure Arc connectivity, usage reporting, and a governance process that keeps the setting correct as the estate changes.

That turns licensing into an Azure resource-management concern. The teams responsible for SQL Server, Azure Arc, networking, finance, and security need a common rollout plan instead of a handoff from a licensing spreadsheet to a server administrator.

What Pay-As-You-Go Changes

For supported SQL Server enabled by Azure Arc scenarios, pay-as-you-go is a consumption model billed on an hourly meter. It can be an alternative to assigning fixed license capacity to individual workloads, particularly where the estate changes frequently or workloads are intermittent.

Microsoft's guidance points to several potential operational advantages:

• Billing aligns with the resources that are actually configured for consumption.

• New, moved, resized, or retired workloads do not require the same repeated fixed-license allocation work.

• Azure provides a central surface to inspect resource-level licensing configuration.

• After usage becomes stable, organizations can evaluate applicable commitments such as savings plans or reservations.

Those are potential fit benefits, not a universal cost claim. A steady, heavily utilized production estate may have a different optimal model from a seasonal development environment. Eligibility, terms, and savings depend on the resource, agreement, location, operating system, and workload pattern.

License Choice Is a Resource Configuration

One of the most important technical points in the new guidance is that an agreement or policy decision does not automatically change a resource's license setting.

If an organization selects pay-as-you-go for a set of SQL Server workloads, it must update the configuration on each eligible resource so that the Azure Arc billing state matches the intended model. Treat that as an infrastructure change with the same rigor as enabling a monitoring agent or changing an identity assignment.

Before changing anything, build an inventory that includes:

• SQL Server edition and version.

• Operating system and whether the server is virtual or physical.

• Core visibility and assigned capacity.

• Existing license declaration and contractual entitlement.

• Azure Arc onboarding and extension health.

• Network and proxy path to Azure usage reporting services.

• High-availability role, passive-replica behavior, and DR design.

• Subscription, resource group, owner, environment, and cost-center tags.

This turns a broad licensing request into a set of reviewable resource changes.

Azure Arc Connectivity Is Part of Billing Correctness

SQL Server pay-as-you-go relies on the host maintaining successful communication with Azure usage-reporting services. Microsoft documentation states that built-in resilience accommodates intermittent connectivity for up to 30 consecutive days, but an instance disconnected for longer can have its subscription expire and is no longer authorized for use under that model.

Treat connectivity as a licensing control, not merely a monitoring issue.

The operating checklist should include:

• Required outbound HTTPS endpoints are reachable through proxies and firewalls.

• DNS resolution and TLS inspection policies allow the documented Azure Arc and usage-reporting traffic.

• The Azure Connected Machine agent and SQL Server extension are healthy.

• The portal's last usage upload time is monitored; Microsoft recommends investigating if uploads are not received for more than 24 hours.

• Activity Logs and agent diagnostics are reviewed before a billing discrepancy becomes a compliance incident.

An offline server can continue executing queries while quietly failing to report usage. That is exactly why this must have an owner and an alert.

Linux Requires an Explicit Review

Pay-as-you-go is supported for SQL Server on Linux, but Microsoft documents important limitations. Automatic passive-instance detection, connected-user verification on readable secondaries, and Database Engine-level core visibility are not available in the same way as on Windows. Linux instances are billed as active under the documented model.

This does not make Linux unsupported. It means the business case must include the platform-specific billing behavior. Do not extend a Windows HA and DR cost assumption to a Linux topology without checking its documented treatment.

Likewise, an affinity mask that limits the SQL Server process to a subset of available cores does not necessarily reduce pay-as-you-go charges. Microsoft notes that licensing is based on the full core count accessible to the virtual or physical machine, subject to the applicable licensing terms and minimums.

Use PowerShell for the Change, Azure Policy for the State

Microsoft recommends PowerShell for a controlled, scoped bulk transition and Azure Policy for ongoing governance.

These tools serve different purposes:

• PowerShell is useful to discover, review, test, and change an approved population of resources in a known scope.

• Azure Policy is useful to identify drift, apply the approved configuration at scale, and remediate noncompliant resources over time.

A safe pattern is:

1. Export and validate the resource inventory. 2. Test the configuration change in a small nonproduction resource group or subscription. 3. Confirm the resulting Arc and billing signals. 4. Roll out a controlled PowerShell change to the approved population. 5. Assign Azure Policy at the right scope to detect or remediate drift. 6. Reconcile exceptions with finance, licensing, and the service owner.

Avoid assigning broad auto-remediation on day one without proving the eligibility criteria and exception handling. Policy should make the desired state durable, not amplify an incorrect assumption across the estate.

Separate Cost Optimization from Licensing Compliance

Pay-as-you-go is a payment option. It does not eliminate SQL Server licensing rules, product terms, or workload eligibility checks. Microsoft explicitly advises reviewing the applicable terms and consulting a licensing specialist or Microsoft representative where needed.

Keep the decision process clear:

• Licensing and legal stakeholders confirm the permitted model for the workload.

• Infrastructure teams confirm Azure Arc supportability and connectivity.

• Database teams confirm SQL configuration, HA behavior, and operational impact.

• FinOps teams model the expected spend and assign cost accountability.

• Security teams validate outbound connectivity and least-privilege access.

No single dashboard can replace that cross-functional review, especially when an estate mixes Software Assurance, subscriptions, perpetual licenses, CSP arrangements, and production and nonproduction workloads.

Measure the Workload Before You Commit

Before migrating a broad group of servers, collect enough data to understand the usage shape:

• Core count and edition.

• Active hours and seasonal behavior.

• Uptime and shutdown patterns.

• HA topology and passive-replica treatment.

• Current entitlement and renewal timeline.

• Existing Azure consumption commitments.

• Required Arc, proxy, and firewall changes.

Then compare the scenario under the legally eligible options. The best decision for a dev/test workload that runs only during business hours can be very different from a continuously loaded production instance with stable capacity.

A Production Rollout Checklist

1. Confirm eligibility and approvals for each workload group. 2. Onboard external SQL Server instances to Azure Arc and validate their agents and extensions. 3. Verify usage-reporting connectivity from the actual server network. 4. Pilot the resource-level change in a limited scope. 5. Confirm license configuration, usage upload, billing visibility, and operational monitoring. 6. Roll out with a tested PowerShell process and recorded change evidence. 7. Use Azure Policy to monitor the target state and handle new resources. 8. Revisit the cost model once usage stabilizes, including any eligible commitment-based options.

Who Should Care?

• SQL Server and database platform teams operating hybrid estates.

• Azure Arc owners responsible for agent and extension health.

• FinOps and procurement teams modernizing SQL licensing operations.

• Security and network teams responsible for usage-reporting connectivity.

Practical Cloud Engineer Takeaway

Azure Arc makes SQL Server pay-as-you-go an operationally governable configuration. The transition is successful only when the resource setting, agent health, network path, usage reporting, policy controls, and financial ownership all agree.

Pilot first, monitor the reporting signal, and use policy only after the approved target state is demonstrated on real resources.

Bottom Line

The updated SQL Server guidance makes a strong case for treating consumption licensing as a managed Azure resource state rather than a one-time commercial exercise.

Pay-as-you-go can improve flexibility for eligible workloads, but it must be implemented with the same care as any production configuration: inventory, validation, telemetry, governance, and clear ownership.

Sources

Microsoft SQL Server Blog, published September 4, 2026: https://techcommunity.microsoft.com/blog/sqlserver/move-to-modern-sql-server-licensing-with-confidence/4553599

Microsoft Learn, manage licensing and billing of SQL Server enabled by Azure Arc: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/manage-license-billing

Microsoft Learn, transition SQL Server to pay-as-you-go: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/manage-pay-as-you-go-transition

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz