GitHub Copilot's policy migration needs an acceptance test, not an admin click

Four announced changes land in one administrator window

GitHub's August 28 notice looks like a collection of product updates. For a managed enterprise, it is one control-plane migration: access, data lifetime, review behavior, and cost all change around the same feature family.

GitHub says that, no earlier than September 28, 2026, Copilot Chat on github.com, Copilot Chat in GitHub Mobile, and Copilot cloud agent will relaunch as one unified experience under one policy. The unified experience will be enabled by default after launch. GitHub also says that opting out will remove Copilot on github.com and GitHub Mobile rather than preserve the old split experiences.

The same notice changes data lifetime. Chat on github.com will move to the agent sessions experience, and its conversation data will be retained for the life of the account instead of 28 days. That is a material change for organizations that accepted Copilot Chat under a short-lived conversational-data assumption. A setting that keeps access unchanged can still change privacy, discovery, data-subject, incident-response, and account-offboarding work.

Code review has its own default migration. For repositories and organizations using Copilot code review, Default will resolve to Balanced beginning September 28. Teams that want to keep Lite must choose Lite explicitly. Balanced may be the correct setting, but an inherited label that changes meaning is configuration drift even when GitHub intended it.

Billing follows on October 1 for existing Copilot Business and Enterprise customers paying by card or PayPal. GitHub announced an upfront charge for assigned seats at the start of the cycle, immediate payment before a newly assigned seat gains access, no prorated refund when a seat is revoked, and continued proration for mid-cycle additions. These terms belong in the same migration record because access tests can fail for either policy or payment reasons.

These dates are announced targets, not evidence that rollout is already complete on September 6. A sound migration plan records the announcement, prepares before the earliest date, and verifies the effective behavior after GitHub exposes it to the actual enterprise.

The product surface now carries a longer-lived session

Product convergence is often presented as fewer menus. The deeper change is ownership. A short Chat interaction on github.com becomes part of the same agent-session model used for delegated work. The session can contain prompts, repository context, model output, tool decisions, code changes, review activity, and operational metadata. The organization must decide which of those records it expects GitHub to keep, which it separately exports, and which it must prevent from entering the session at all.

The official github/app repository describes the Copilot app as an agent-native desktop experience for finding, running, steering, and landing work across repositories. Its data-and-telemetry note says GitHub may collect usage data, associated conversation data, and submitted feedback when a user works through a Copilot account. Debug logs may contain sensitive information. The repository is public for releases, issues, and discussion, but the application source lives elsewhere. That means a platform team can inspect public behavior and documentation without pretending it has a full implementation audit.

The migration should therefore start with a surface inventory, not one enterprise toggle. Include github.com Chat, Mobile, cloud agent, Copilot code review, IDE Chat and agent mode, CLI, the desktop app, Spaces, Spark, third-party agents, and any repository automation. GitHub documents that policies may apply across surfaces, but not every policy applies everywhere; the app and CLI have separate client policies. “Copilot enabled” is not a sufficient control state.

Separate five planes before assigning owners

A single “Copilot owner” obscures incompatible responsibilities. Divide the migration into five planes and give each an authoritative record.

Identity determines which policy and bill apply. Policy determines which surfaces can create or continue a session. Data-lifecycle rules govern what the organization may place in those surfaces. Execution controls decide what a session can change. Billing controls decide whether a permitted session can continue when included usage or payment thresholds are reached.

Keep the planes linked but do not merge their evidence. An activity report can show that a user interacted with Copilot; it cannot prove that an invoice line is correct. An audit event can show that an administrator changed a policy; it cannot prove that every existing session adopted the new state. A successful agent run can show functional access; it cannot establish compliant retention.

Account-lifetime conversation retention is not 90-day activity telemetry

Retention discussions become confused when every Copilot record is called “chat data.” GitHub's announced account-lifetime rule concerns conversation data for Chat on github.com after it moves to agent sessions. GitHub separately documents a rolling 90-day retention period for the last_activity_at property in Copilot user management. That activity timestamp is calculated from interactions across several surfaces and becomes nil after 90 days without new activity.

Usage metrics form another class. GitHub documents per-user AI-credit consumption, prompt counts, code-generation events, code-review activity, model and mode distributions, and repository-level PR outcomes. Some reports have different aggregation scopes, and GitHub warns that enterprise and organization totals may differ because of user deduplication and attribution timing. The per-user ai_credits_used field is for consumption analysis, not invoicing totals.

Repository content and execution artifacts form a fourth class: prompts may bring code and context into a conversation, while cloud agents can create branches, commits, pull requests, comments, logs, and changesets in systems with their own retention and deletion rules. Locally collected app debug logs form a fifth class and may contain sensitive information.

Create one row per record class with controller, processor, owner, purpose, approved input, retention rule, export path, deletion route, incident contact, and legal-hold behavior. If GitHub has not documented a required deletion or export property, mark it unknown and route it to the account team or trust documentation. Do not fill the gap with a confident assumption.

Effective policy is a function, not a screenshot

GitHub's policy documentation explains that enterprise and organization settings can conflict. Within one enterprise, the least restrictive policy usually applies when a user receives access from multiple organizations, with exceptions. Across different enterprises, the most restrictive policy almost always applies. Model access on a GitHub Team plan can depend on the organization shown under “Usage billed to.” The app and CLI have independent client policies.

This makes a policy screenshot incomplete. Store the assignment path and calculate effective behavior for representative identities: an enterprise-assigned user, an organization-assigned user, a user licensed through multiple organizations, a contractor, a repository outside the main organization, and a user with both desktop app and CLI installed.

effective_access = evaluate(
  identity = user_login,
  license_sources = [enterprise, organizations],
  billing_source = usage_billed_to,
  surface = [github_chat, mobile, cloud_agent, app, cli, ide],
  feature_policy = explicit_policy_snapshot,
  repository_scope = tested_repository,
  paid_usage_policy = enabled_or_disabled
)

assert effective_access == approved_target
assert every_unknown_has_owner_and_due_date

Run this as a test matrix, not as invented universal code. GitHub remains the evaluator of its platform policy. Your system records inputs, observed outcomes, and mismatches against the approved target.

Version the decision before touching the live setting

A migration manifest turns meetings into a testable artifact. It records what was observed, what has been approved, who owns the decision, and which evidence must exist before close. Keep vendor facts separate from local policy.

change_id: copilot-unified-policy-2026-09
vendor_notice_observed: 2026-09-06
earliest_unified_rollout: 2026-09-28
billing_change_date: 2026-10-01
scope:
  enterprise: acme
  test_organizations: [platform, payments, regulated-products]
target:
  unified_experience: enabled
  code_review_effort: lite   # explicit, never "Default"
  paid_ai_credit_usage: disabled_until_finance_signoff
  clients:
    github_web: enabled
    mobile: enabled
    cloud_agent: limited_to_platform
    copilot_app: pilot_only
    copilot_cli: disabled
data_classes:
  conversation:
    allowed: [public_code, approved_internal_code]
    prohibited: [secrets, production_customer_data, privileged_advice]
    announced_retention: account_lifetime
  activity_telemetry:
    documented_retention: 90_days
gates:
  privacy: pending
  security: approved
  developer_experience: pending
  finance: hold
rollback:
  note: opt_out_removes_web_and_mobile_access
  owner: platform-governance

The manifest is not a claim that YAML configures GitHub. It is the organization's control record. Administrators apply supported settings in GitHub, then attach exports, screenshots, audit events, and test results to the same change ID.

Never use Default for a control that has a required stable meaning. If Balanced is approved, select Balanced. If Lite is approved, select Lite. Repeat that rule for feature access and paid usage: “vendor default” is a decision only when the owner knowingly accepted its change behavior.

Test the migration with users, repositories, and retained records

Use synthetic or low-risk accounts that represent real entitlement paths. Test one repository with ordinary code, one with content exclusions, one with stricter branch protection, and one where cloud-agent access should be denied. Keep secrets and customer data out of the test corpus.

1. Export or capture current enterprise, organization, repository, client, model, code-review, content-exclusion, and paid-usage settings.
2. Record current access results for github.com Chat, Mobile, cloud agent, app, CLI, IDE Chat, and code review.
3. Create a low-risk conversation and agent session; record identifiers, repository scope, policy source, and visible lifecycle controls.
4. Run the same representative pull request under Lite and Balanced. Compare suggestions, elapsed time, AI credits, Actions minutes, false positives, and applied fixes.
5. Verify a blocked identity stays blocked and a permitted identity cannot escape its repository, organization, tool, branch, or merge controls.
6. After rollout, repeat the matrix. Confirm that existing and new sessions resolve to the approved policy rather than an inherited assumption.
7. Test offboarding: revoke the seat and account access, then verify the approved behavior for conversations, branches, pull requests, logs, audit records, and billing.
8. Reconcile usage and activity exports to test runs while recording latency and known attribution gaps.

Code-review acceptance needs more than “it produced comments.” Build a small fixture set: a clear correctness bug, a security boundary change, generated code with noisy formatting, a clean pull request, and a repository with content exclusions. Measure useful findings, false positives, suppressed context, reviewer effort, and whether required checks remain authoritative. Balanced may improve coverage while increasing latency, usage, or comment volume. The organization should see the tradeoff before the new default resolves in production.

Policy and payment can produce the same user-visible failure

A user who cannot start an agent session may be blocked by feature policy, user-level budget, exhausted included credits, a cost-center spending limit, the paid-usage policy, payment state, allowed additional usage, seat assignment, or a client-specific control. Support and platform teams need one classification tree instead of repeatedly toggling access.

GitHub documents that user-level budgets cap each user's AI-credit consumption across both the shared pool and paid usage. Cost-center, organization, and enterprise budgets generally cap metered charges after the shared pool is exhausted. Some of those limits are hard stops only when “Stop usage when budget limit is reached” is enabled. Paid overage also requires the AI-credit paid-usage policy. These are separate controls, not synonyms.

One August GitHub Community thread illustrates the operational risk. A user reported that Copilot stopped even though a self-set budget remained. The discussion distinguishes the user's spending ceiling from a separate allowed-additional-usage or payment boundary. Treat the thread as a failure example, not authoritative product specification. The correct response is to preserve usage export, payment and invoice records, entitlement state, budget configuration, and support correspondence before changing controls.

Finance needs its own reconciliation. The companion AI usage-billing review workflow separates assigned-seat commitments, pooled credits, user limits, metered spending, usage exports, invoice lines, and service interruptions so an administrator does not mistake a budget for prepaid entitlement.

Failure modes to rehearse before September 28

Do not solve these failures by granting every administrator broad access. GitHub recommends reviewing who can manage policies and using the audit log to monitor policy changes. Limit the right to alter AI controls, record emergency changes, and require retrospective review when an incident forces a temporary exception.

A practical migration checklist

1. Name accountable owners for identity, policy, privacy, security, developer experience, finance, support, records, and legal questions.
2. Inventory every Copilot surface and license path used by the enterprise.
3. Freeze current settings, representative access results, active sessions, seat assignments, budgets, and usage baselines.
4. Classify conversation, telemetry, audit, billing, repository, and debug-log records separately.
5. Decide whether the unified experience is permitted and record the operational cost of opting out.
6. Replace Default with explicit Lite or Balanced where review effort is governed.
7. Validate content exclusions and branch protections with adversarial fixtures; do not assume convergence expands their coverage.
8. Align paid-usage policy, user limits, cost-center limits, enterprise limit, payment state, and interruption response.
9. Run the identity-by-surface and repository acceptance matrix before and after rollout.
10. Verify audit evidence, usage exports, conversation lifecycle, offboarding, and one support escalation path.
11. Approve one target manifest and record every exception with owner, deadline, evidence, and compensating control.
12. Recheck GitHub's changelog on the actual rollout date because “no earlier than” is not a guarantee.

The release gate should produce one of five decisions: enable, enable with bounded exceptions, delay, opt out with an approved alternative, or stop. A silent carry-forward of current defaults is not a sixth decision.

Frequently asked questions

When will the unified Copilot policy apply?

GitHub announced a relaunch no earlier than September 28, 2026. Prepare for that earliest date, then inspect the enterprise's effective setting and rerun tests. Do not label the migration complete from the calendar alone.

Is conversation retention the same as activity-metric retention?

No. GitHub announced account-lifetime retention for github.com Chat conversation data after it moves to agent sessions. GitHub separately documents a 90-day rolling period for last_activity_at. Usage, audit, repository, and debug-log records have their own purposes and lifecycle rules.

Should every team switch code review to Lite before the deadline?

No. Choose the effort that meets the repository's risk, latency, cost, and reviewer-noise tolerance. The control lesson is to make the choice explicit and test it, not to prefer Lite or Balanced universally.

Does a GitHub budget guarantee continued service?

No. User limits, shared credits, paid-usage policy, cost-center or enterprise spending limits, payment state, allowed additional usage, seat status, and feature policy can each affect service. Record which control blocked the request before changing it.

Does a unified policy make Copilot sessions safer?

Not by itself. It can simplify administration, but repository permissions, sandboxing, branch protection, content exclusions, tool authority, human review, secrets, and incident response remain separate controls.