What changed

Microsoft published the change on 1 September 2026 as two capabilities reaching general availability. The first is that the Auxiliary plan now supports a subset of standard Azure tables in addition to DCR-based custom tables, so low-value data can stay on its original standard table, keeping its name, schema and existing queries, rather than being reshaped through a custom pipeline. The second is that existing tables can be switched between the Analytics and Auxiliary plans without being recreated: the change applies to the table in place, history, schema and integrations are kept, and Microsoft states that the switch is fully reversible as your workload evolves. The table plan documentation sets out what that switch carries with it. Moving a table from Analytics to Auxiliary means alerts stop working for that table, summary rules break where the rule uses resource query scope, and queries attract billing that the Analytics plan includes. A note on the same page limits table plan updates to one switch per table per week. The feature comparison is broader still: on Auxiliary there are no alerts, no data export rules, no restore, no insights, no customer lockbox and no workspace replication, resource-scope queries are unavailable, and queries are explicitly slower and described as good for auditing rather than optimised for real-time analysis. Search jobs, summary rules limited to a single table, and Microsoft Sentinel remain supported. On availability, Microsoft states that the Auxiliary plan matches Log Analytics availability except for Qatar Central, so South Africa North is in scope, and that neither Basic nor Auxiliary is available for workspaces on legacy pricing tiers.

The risk here is a quiet one and it lands on the security team rather than on the person who made the change. Moving a log table to the cheapest plan stops alerts working on that table, and nothing about the change announces itself afterwards. The alert rule still exists, the workspace still reports healthy, and the dashboards still draw. What has gone is the thing that would have told somebody. A cost optimisation made by one team can therefore remove a detection owned by another, and because the failure mode is silence rather than error, the gap is only found when it is needed.

What the term means in plain language

A Log Analytics workspace holds log data in tables, and each table carries a plan that decides what the data costs to ingest and what you can do with it. Analytics is the full-capability plan: fast queries, alerts, insights, dashboards, data export and restore, with the standard ingestion price. Basic sits below it, cheaper to ingest, with reduced query capability and simple log alerts. Auxiliary, also called the Lake plan, is the cheapest and the most restricted: minimal ingestion cost, slower queries, single-table KQL, and it is intended for high-volume verbose data kept for auditing and compliance and rarely read. All three plans support total retention of up to twelve years. The distinction that matters operationally is not price but capability, because the plans differ in what they let you do with the data after it arrives rather than only in what it costs to put there.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

On 1 September 2026 Microsoft made two Azure Monitor changes generally available. The Auxiliary log plan now accepts a subset of standard Azure tables rather than only custom ones, and an existing table can be switched between the Analytics and Auxiliary plans in place, keeping its name, schema and queries. Microsoft describes the switch as fully reversible. The documentation qualifies that in three ways worth understanding before anyone moves a table: alerts stop, plan changes are limited to one per table per week, and data written while on Auxiliary is not available to interactive queries after switching back.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

This is a real saving and it is worth taking, provided the decision is made with the whole of the documentation rather than the announcement. Verbose telemetry that exists for audit and is queried once a quarter has no business sitting on the plan that pays for real-time analytics, and until now the obstacle was practical rather than commercial: moving that data meant recreating a table or building a custom pipeline, which cost more effort than the saving justified. Switching a table in place removes that obstacle, and for a South African business carrying an Azure Monitor bill in rands against a dollar-denominated price list, the arithmetic is not marginal. The care required is in the word reversible, and the asymmetry underneath it. Moving a table from Analytics to Auxiliary leaves the older data interactively queryable, with Microsoft noting that a query spanning the changeover date may return partial results and warn you accordingly. Moving it back the other way does not behave symmetrically: Microsoft states that data ingested under the Auxiliary plan before the change is not available in the interactive query experience, and that reaching it requires a search job or the search REST API. So the setting is reversible and the data written while the setting was in place is not, at least not in the way an analyst expects to reach it, and a search job is a separate operation with its own cost. That distinction is ours rather than Microsoft’s, but it follows directly from their own data-continuity table, and it is the sentence to have ready for the conversation with finance. The operational consequence is sharper than the cost one. Alerts stop working on a table moved to Auxiliary. Not degrade, not delay: stop. In most organisations the person watching the bill and the person who wrote the alert rule are not the same person, and the plan change is made in a place the second person does not look. That is why the alert inventory belongs before the change rather than after it, and why the one-switch-per-week limit deserves respect: it removes the option of undoing a mistake on the same afternoon you make it.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

Setting a table plan requires Microsoft.OperationalInsights/workspaces/write and workspaces/tables/write on the workspace, as provided by the Log Analytics Contributor role; reading it requires only tables/read, as provided by Log Analytics Reader. Custom tables can be given a plan when they are created, Azure tables default to Analytics, and support for the Basic and Auxiliary plans varies by table, so the table feature support reference is the place to confirm a specific table qualifies before planning around it. The change can be made in the portal under the workspace’s Tables blade, through Manage table and the Table plan dropdown, which shows only the plans available for that table. It can also be made with the Azure CLI through az monitor log-analytics workspace table update with the –plan parameter, with the Update-AzOperationalInsightsTable PowerShell cmdlet, or through the Tables Update REST operation as a PATCH setting properties.plan to Analytics, Basic or Auxiliary. Three constraints should be built into whatever runs the change. Table plan updates are limited to one switch per table per week, so a scripted sweep across many tables should be staged rather than run in a loop and re-run on failure. Moving a table from Analytics to Basic carries its own separate consequences, distinct from Auxiliary: the total retention period does not change but data older than thirty days is treated as long-term retention, and summary rules break where they use resource query scope. And on either move to a cheaper plan, queries and summary rule queries attract billing that the Analytics plan includes, which is a real cost against the saving and belongs in the calculation rather than beside it. On data continuity, the behaviour is documented explicitly in both directions. Changing a plan neither deletes nor moves existing data, and data ingested before the change is preserved for its retention period. From Analytics to Auxiliary, the earlier Analytics data remains available interactively, and a single query spanning the changeover date may return a warning that the table has Auxiliary data from a given time and that results may be partial. From Auxiliary back to Analytics, data ingested under the Auxiliary plan is not available interactively at all, and reaching it means running a search job or using the search REST API against the table. Plan the retention math on that basis rather than on the assumption that moving back restores the previous state.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: Whoever is accountable for the Azure Monitor bill, normally the cloud or platform lead, jointly with whoever owns detection and alerting, because the second party carries the consequence of the first party’s decision.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: Before moving anything, list the tables you would move and then list every alert rule and summary rule that reads them, and keep both lists with the current plan settings as your record of the position before the change. Then move at most one table and watch it for a week, because Microsoft limits plan changes to one per table per week and a rushed second change is not available to you. Where a table feeds a detection you rely on, either leave it on Analytics or move the detection first.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: The table plan configuration for the workspace as it stood before any change, the list of alert rules and summary rules bound to each affected table, the date of each plan change, and, for any table moved to Auxiliary and later moved back, a note of the window during which data is reachable only through a search job. The last of these is the one nobody records and the one an investigation later needs.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

What exactly went generally available?

Two things, on 1 September 2026. Auxiliary now supports a subset of standard Azure tables in addition to DCR-based custom tables, and existing tables can be switched between the Analytics and Auxiliary plans in place, keeping name, schema, history and integrations.

Microsoft says the switch is fully reversible. Is it not?

The setting is. The data is not, in the sense that matters day to day. Microsoft’s own data-continuity table states that after switching from Auxiliary back to Analytics, data ingested under the Auxiliary plan is not available in the interactive query experience and must be reached with a search job or the search REST API. Nothing is lost; it is reached differently and at a different cost.

What happens to alerts?

They stop working for a table moved to Auxiliary. Microsoft states it in the change-considerations table without qualification. Summary rules also break where the rule uses resource query scope. This is the single most important thing to check before making the change.

How often can we change a table plan?

Once per table per week. Microsoft states the limit in a note directly under the change table. It is a good reason to move one table first rather than a batch.

Is the Auxiliary plan available to us in South Africa?

Yes. Microsoft states that the Auxiliary table plan matches Log Analytics availability except for Qatar Central, so South Africa North is in scope. Note separately that neither Basic nor Auxiliary is available for workspaces on legacy pricing tiers.

What else do we lose on Auxiliary besides alerts?

The feature comparison lists no data export rules, no restore, no insights, no customer lockbox and no workspace replication, and no resource-scope queries. Queries are described as slower and suited to auditing rather than real-time analysis. Search jobs, single-table summary rules and Microsoft Sentinel remain supported.

Does moving a table save money on queries too?

No, the opposite. Query pricing is included on Analytics and is not included on Basic or Auxiliary, and Microsoft notes extra billing for queries including summary rule queries. The saving is on ingestion and retention; a table that turns out to be queried more than expected can erode it.

Which tables are the right candidates?

High-volume, verbose data kept for audit or compliance and rarely queried, on tables that support the plan. Microsoft names container stdout and stderr, audit trails and node syslog as examples in a related update, and specifically mentions ContainerLogV2, AKS audit logs and control-plane logs as Basic plan candidates in Kubernetes environments.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.