Gemini Code Assist ends new sales: plan renewals and migration

What did Google confirm?

The October 9 release notes announce the sales change. The subscription transition page gives the specific existing-contract and renewal rules. Purchase eligibility, a renewal window and a contract end date are separate fields.

Identify the actual subscription before applying a rule

These rules concern Google Cloud Standard and Enterprise subscriptions. Do not group personal editions and Google AI plans into the same billing record merely because their names contain Gemini. The release notes also describe an earlier June 18 change involving individual tiers; that is background, not a new October 9 event.

Google points future agentic coding assistance toward Antigravity in Gemini Enterprise editions. This does not establish automatic contract conversion, identical pricing, or new permissions for every old seat. Ask the contract channel to confirm the applicable edition and entitlement.

Build a verifiable contract and tooling inventory

1. 1
   Have the authorized owner consult the actual subscription and contract. Record edition, billing account, monthly or annual term, contract end and next renewal. A sample date is not your deadline.
2. 2
   List allocated licenses and planned hires. Ask separate questions about a new subscription and adding licenses to an existing one. Keep written confirmation from the contract channel.
3. 3
   Inventory editor extensions, CLI entry points, organization configuration and important coding tasks. Use actual tool names and versions instead of one generic AI-assistant label.
4. 4
   Assign a pilot owner, acceptance tasks and a fallback. Support requests should contain necessary contract or error details, without repository secrets or credentials in public feedback.

An annual-contract case shows why dates stay separate

This is an original fictional planning case, not Google contract advice. Team A’s annual agreement lists February 15, 2027 as its end date, and two developers are expected in early February. Its owner needs separate answers for existing support and extra licenses, rather than one broad question about whether the assistant still works.

Accept the real workflow, beyond successful sign-in

Editorial recommendation: start with a low-risk reproducible coding task, such as documenting a function’s boundaries and running existing checks. Keep the task, input version, proposed patch, execution results and human judgment. Signing in establishes access, not successful migration of organization settings and daily work.

Use the model-update task evaluation workflow for acceptance criteria. For broader office work, the traceable cross-app deliverable pilot offers a checking approach; those capabilities do not imply Code Assist contracts convert automatically.

Renewing monthly through year-end does not permit midyear expansion

In this invented planning case, a team has 12 assigned monthly licenses and expects three hires on July 1, 2027. Its owner sees the December 31, 2027 monthly renewal window and schedules migration for autumn. But the official additional-license window ends January 31. The separate monthly renewal deadline does not cover that expansion need.

The problem is how the three newcomers will obtain an organization-approved workflow, not merely whether the existing 12 can sign in. Have the contract owner confirm the agreement, staffing arrangements and replacement entitlements. The sunset notice does not establish whether existing seats may be reassigned, how a replacement is priced or whether configurations carry over. An illustrative case is also no reason to purchase unapproved spare seats.

Separate continuity for current staff from onboarding new staff. The former depends on contract and support terms; the latter needs a replacement entry point, identity, organizational access and successful work tasks. They may use different cutover dates. If the organization cannot maintain two environments, move the joint pilot earlier rather than discovering on a new hire’s first day that the instructions describe only the old extension.

Plan backward from the first affected task, not the final renewal

These are editorial internal checkpoints, not Google delivery promises: by January 8, confirm the contract and entry points needed by the three hires; by January 15, have a pilot user complete a small repair with existing tests in an authorized sample repository; by January 22, have another person reproduce it and decide on adoption. January 31 is the official action boundary to compare against, not a simultaneous start date for the team’s research. Replace these dates with a plan appropriate to your agreement.

Suppose January 15 sign-in succeeds and the IDE edits files, but the CLI cannot use organizational authorization. Record a failed required workflow and route the access or product-entry issue to its owner. Removing the CLI step from acceptance does not complete migration, and the old subscription cannot be assumed to grant new-product rights. If unresolved by January 22, revise approved onboarding arrangements or cutover timing while retaining a workable path within the existing contract’s supported scope.

Hand over instructions, actual product identities, accepted tasks and unsupported steps together. The announcement establishes sales and renewal rules; migration completion requires the next person to complete their work. Use the fixed-case model-migration method for coding acceptance, while keeping this planning example separate from an executed enterprise pilot.

Put distinct checkpoints into the purchasing plan

Keep the contract end alongside the official action cutoffs in an owner-maintained checklist. This article uses the October 9 sources; reopen them before purchasing or renewing. It makes no prediction about refunds, pricing, regional availability or automatic migration, and reports no enterprise-account trial.