Custom GPT Retirement Update: What the October 1 Enterprise Banner Target Means—and the Dates That Still Matter

Terminology: A custom ChatGPT assistant is a configured assistant, not a separately trained model. Here, generative pre-trained transformer (GPTA family of transformer-based language models trained to generate and analyze content. Open glossary entry) names the underlying language-model family, not the custom assistant itself. OpenAI custom-GPT guidance.

Evidence checkpoints

Documented point: OpenAI lists 1 October 2026 as a target for a migration banner only in Enterprise workspaces that had already opted into delayed migration banners; it is neither a global rollout date nor the retirement date. This is a target for previously opted-in Enterprise workspaces, not proof that the banner or migration is available in another account. [official source 1]

Documented point: OpenAI lists 26 October 2026 as the planned end of new custom-GPT creation; it says drafts needed for the documented migration workflow should be published before that cutoff. The planned creation cutoff is distinct from the ability to use an existing GPT until its applicable retirement date. [official source 1]

Documented point: OpenAI’s retirement frequently asked questions (FAQ)A collection of recurring questions and concise answers about a subject. Open glossary entry says custom GPTs are scheduled to retire on 11 December 2026; existing GPTs remain usable until their applicable retirement date, subject to existing permissions. The 11 December date is the standard schedule; any different workspace-specific notice needs separate verification. [official source 1]

Documented point: OpenAI lists 11 February 2027 only for affected Enterprise workspaces with a qualified, approved deferral, not as a blanket Enterprise extension. This extension requires a qualified, approved deferral; it is not an automatic Enterprise-wide change. [official source 1]

Documented point: The selected model does not carry over; this prevents any claim that GPT-5.5, GPT-5.5 Mini, or another prior model selection persists through migration. Model continuity requires a separate selection and representative testing in the replacement environment. [official source 1]

Documented point: OpenAI dated its DevDay 2026 recap 29 September 2026 and described the broader plugin-platform announcement there. The DevDay recap is contextual platform news, not the source of the custom-GPT retirement dates; the separate official FAQ controls that timetable. [official source 1]

1 October is a delayed-banner target, not the custom-GPT retirement date

As of 1 October 2026, custom GPTs have not reached their standard retirement date. The news is narrower: OpenAI’s Custom GPT retirement and migration FAQ lists 1 October as a target for showing a migration banner in Enterprise workspaces that had already opted into delayed migration banners. It is not a worldwide release date, a migration deadline or evidence that a particular workspace can use the migration workflow.

The same FAQ, checked for this article on 1 October 2026, separates that banner target from two later milestones. OpenAI describes 26 October as the planned end of new custom-GPT creation and 11 December as the scheduled standard retirement date. It lists 11 February 2027 only for affected Enterprise workspaces that have a qualified, approved deferral. OpenAI also warns that migration availability can differ by account or workspace, that a target date does not guarantee access and that Enterprise dates are subject to change.

The timetable raises four distinct questions for creators and administrators:

1. Has OpenAI documented the transition? Yes. The FAQ describes a planned migration from custom GPTs to plugins.
2. Has a date been assigned to a cohort or event? Yes, but the status varies: some dates are targets, one is planned, one is scheduled and the later Enterprise date is conditional.
3. Does a specific account expose the migration control? The public timetable cannot answer that. The creator or administrator must check the account and workspace in which the GPT was created.
4. Is a replacement ready for its intended users? A banner or migration control does not establish this. Installation, configuration, permissions and human validation remain separate checks.

The immediate editorial distinction is therefore between notice timing, workflow availability and retirement timing. A banner communicates information to a defined workspace cohort. Workflow availability means an eligible creator can actually see and use the documented migration option. Retirement means the old GPT becomes inaccessible on its applicable retirement date. Treating those events as interchangeable could cause preparation to start too early or too late.

Keep the 1 October delayed-banner target separate from the retirement dates of individual model surfaces. OpenAI’s separate notice sets out the GPT-5.5 14 October product-surface retirement for ChatGPT, ChatGPT Work and Codex; that model deadline does not establish custom-GPT migration availability.

The date-and-status ledger

The table below preserves OpenAI’s status words rather than flattening every date into a “deadline”. Its principal source is the Custom GPT retirement and migration FAQ as checked on 1 October 2026. The 29 September platform entry comes from OpenAI’s dated DevDay 2026 recap and is included only as context for the broader plugin platform; it is not the source of the retirement schedule.

Date	Documented event and status	Who or what it applies to	What the date does not prove	Account-specific verification	Practical action	Official-source position as of 1 October 2026
11 September 2026	Enterprise preparation-notice milestone. OpenAI’s Enterprise timetable lists an administrator notice intended to help organisations prepare.	Affected Enterprise administration contexts covered by the timetable.	It does not prove that every administrator or every user received a notice. It also does not establish migration access.	Ask the workspace owner or designated administrator whether a notice arrived, where it was delivered and which workspace it named. Preserve the notice text and date for the change record rather than relying on recollection.	If the organisation has no recorded notice, inspect the relevant workspace and official FAQ rather than assuming it was excluded. Assign an owner for inventory and user communications.	Listed in the retirement FAQ; FAQ checked 1 October 2026. Workspace-specific notices remain controlling evidence for a particular organisation.
22 September 2026	Target. OpenAI lists a target for a migration experience and user banner in affected Enterprise workspaces.	The affected Enterprise cohort described by OpenAI, subject to account and workspace differences.	It does not guarantee that every Enterprise workspace received a banner, that every creator can migrate or that every user has plugin access.	Sign in to the account and workspace where each GPT was created. Check whether the documented migration option is present and whether workspace policy enables the relevant access. Record “present”, “absent” or “not authorised”; do not infer a state from the calendar.	Where access is absent, continue readiness work that does not depend on the control: identify owners, locate published GPTs, catalogue affected users and preserve the current documented configuration.	Target in the retirement FAQ, checked 1 October 2026. OpenAI says target dates are not guarantees of account-level migration access.
29 September 2026	Published platform context. OpenAI’s DevDay 2026 recap describes plugin extensions and plugin creation, submission and discovery developments.	The broader plugin-platform announcements and their plan-qualified availability, not the retirement timetable itself.	It does not prove that the recap announced custom-GPT retirement. Nor does it prove that a particular creator has the migration option, can install a replacement or can use every plugin capability on every surface.	Use the retirement FAQ for migration status. In the intended account, separately verify plan, workspace, role and plugin controls instead of treating the platform announcement as an entitlement.	Use the recap as architectural context only. Base retirement planning and dates on the retirement FAQ and account-specific notices.	OpenAI DevDay 2026 recap dated 29 September 2026; retirement facts remain sourced to the separate FAQ checked 1 October.
1 October 2026	Target for a delayed banner. OpenAI lists this date for a migration banner only in Enterprise workspaces that had already opted into delayed migration banners.	That pre-existing delayed-banner cohort, not all Enterprise workspaces and not all ChatGPT accounts.	It is not a global rollout date, migration deadline, creation freeze or retirement date. A visible banner does not guarantee that the creator has the required control or permissions. An absent banner does not move the published retirement timetable.	Confirm that the workspace actually opted into delayed migration banners. Check the banner and the creator’s migration control separately in the originating workspace. Ask an administrator whether policy or role restrictions could explain a missing control.	If the banner appears, capture its exact wording and named dates, then proceed to an inventory and access review. If it does not appear, do not wait passively: use the FAQ’s later milestones for provisional planning while seeking workspace-specific confirmation.	Narrow target in the retirement FAQ, checked on the target date. OpenAI qualifies target dates and says migration availability may differ by account or workspace.
26 October 2026	Planned creation cutoff. OpenAI calls this the planned end of creating new custom GPTs.	New custom-GPT creation under the documented transition plan. OpenAI advises creators to publish drafts needed for the documented migration workflow before this cutoff.	It is not the standard retirement date. It does not mean draft content will transfer, and it should not be represented as an unconditional date for every surface irrespective of later official changes or account notices. The FAQ says the planned freeze does not itself stop edits to existing, unmigrated GPTs.	Identify every draft and determine whether it represents a GPT the organisation genuinely intends to preserve. Verify publication status in the account and workspace where it was created. Recheck the FAQ and workspace notice before acting.	Publish only reviewed drafts needed as migration sources before the planned cutoff. Do not publish secrets, personal data or untrusted material merely to make a draft eligible. Record the approved published version because the documented workflow uses the latest published version, not unpublished edits.	Planned date in the retirement FAQ, checked 1 October 2026. Availability and Enterprise dates remain qualified by OpenAI.
11 December 2026	Scheduled standard retirement. OpenAI says custom GPTs are scheduled to retire on this date.	The standard timetable. Existing GPTs remain usable until their applicable retirement date, subject to existing access and workspace permissions.	It does not mean retirement occurred on 1 October. “Scheduled” is not a claim that the date can never change. It also does not override a qualified, approved Enterprise deferral.	Check the workspace notice for the applicable date and any changed instructions. For each GPT, confirm whether a replacement exists, who owns it and whether intended users have separately validated access.	Plan backwards from 11 December unless authoritative workspace-specific information supplies another applicable date. Leave time before retirement for publication, migration availability, configuration review, permission checks and user communication.	Scheduled standard date in the retirement FAQ, checked 1 October 2026. Account and workspace notices should be rechecked as the date approaches.
11 February 2027	Qualified, approved deferral date. OpenAI lists this date only for affected Enterprise workspaces with an approved deferral.	Eligible Enterprise workspaces that have actually received the qualification and approval; it is not a general Enterprise extension.	It does not apply merely because an organisation uses Enterprise, requested more time or has not seen a banner. It should not be used in a project plan without written account-specific confirmation.	Obtain the workspace-specific approval and verify the workspace identifier, affected population, conditions and applicable date. A general announcement or internal request is not sufficient evidence.	Until approval is confirmed, plan against the standard 11 December schedule. If approval is confirmed, use the additional period for controlled completion rather than treating it as a reason to defer ownership and inventory.	Conditional date in the retirement FAQ, checked 1 October 2026. OpenAI does not describe it as a blanket extension.

How to read “target”, “planned”, “scheduled” and “approved”

These terms do different work. A target expresses when OpenAI aims to expose an experience or notice to a described cohort, while expressly allowing account-level variation. A planned cutoff communicates intended product sequencing but still calls for a fresh documentation check before the date. A scheduled retirement date is the operative standard date readers should plan around, without presenting it as irrevocable. An approved deferral is an exception that needs affirmative, workspace-specific evidence.

A practical decision rule follows: use the public schedule for planning, but use the originating account and its workspace notice for capability and exception claims. If the FAQ says a feature is targeted but the account does not expose it, record the feature as unavailable or unconfirmed for that account. If a workspace believes it has a deferral but cannot produce approval, retain 11 December as the working retirement date. If account evidence conflicts with an old internal screenshot or message, recheck current official documentation and ask the workspace administrator to resolve the conflict.

This distinction matters because a date can be true at platform level while a capability remains unavailable at account level. OpenAI has documented the migration workflow, but the FAQ says “Migration access may become available at different times.” It also states that a target migration date does not guarantee that every account can migrate on that day. The correct status for an account with no visible migration control is therefore not “late”, “broken” or “ineligible” unless OpenAI says so; it is “not currently verified in this account”.

Why the banner is neither an entitlement nor a cutoff

A banner is a notice surface. It can tell users that a transition is coming, identify dates or direct them towards an available process. It does not, by itself, establish all the conditions required to complete that process. The migration control may be exposed at a different time, plugin access may be disabled by workspace policy, or the viewer may lack the necessary creator or administrator role. The creator must also be in the account or workspace where the GPT was created.

Nor does the banner grant access to the eventual replacement. OpenAI’s documentation distinguishes plugin availability from installation, workspace permissions, connected-app authorisation and access to data in an underlying source system. A former user of a GPT does not automatically become a user of its replacement plugin. This section does not attempt a full portability or permissions audit, but administrators should not use banner visibility as a proxy for successful deployment.

The converse is equally important: the absence of a banner on 1 October does not create a later retirement date. The published standard schedule still points to 11 December unless an authoritative update or a qualified, approved Enterprise deferral applies. Waiting for a visual notice before starting an inventory would compress the preparation period without any source-backed reason.

Use this three-part check when interpreting a banner:

1. Identify its scope. Record the workspace, account, recipient role and exact wording. A banner seen in one workspace is not evidence for another.
2. Test capability separately. In the account where the GPT was created, verify whether the documented migration option is present and whether policy allows its use. Do not invent or rely on a click path if the current interface differs.
3. Retain the applicable timetable. Treat 26 October as the planned creation cutoff and 11 December as the scheduled standard retirement unless current official or account-specific information establishes otherwise.

Example status record: “Delayed Enterprise banner visible on 1 October; migration control not yet verified for the creator; standard 11 December retirement remains the planning date.” This is a sample record, not a product-generated status or a guarantee about what any workspace will display.

Decision rule: a banner may trigger action, but it must never be recorded as proof that migration is enabled, completed or functionally equivalent. Completion requires separate evidence about the source GPT, the resulting replacement and intended-user access.

Case example: the Enterprise workspace that receives a delayed banner

Consider an Enterprise workspace that can confirm it had already opted into delayed migration banners. On 1 October, an administrator sees a banner. The correct interpretation is that the narrow target has been met for that workspace’s notice experience. It does not establish that another Enterprise workspace should see the same banner, and it does not change the later creation and retirement dates.

The administrator should first preserve the banner’s exact text, date and workspace context. This avoids converting a potentially account-specific message into a broader claim. Next, they should identify the people who own custom GPTs in that workspace and ask each owner to check the account in which the GPT was created. The owner should report whether the documented migration option is present, absent or inaccessible because of permissions.

If the control is present, the organisation still should not label the GPT “ready to migrate” merely from its presence. OpenAI says the documented workflow uses the latest published version. Drafts and unpublished edits do not transfer. A sensible notice-stage check is therefore to record the latest published version and identify whether unreviewed work exists outside it. The selected model also does not carry over, so an owner must not promise that a previous model choice—including GPT-5.5, GPT-5.5 Mini or any other selection—will persist after migration.

A concise sample register entry could read:

Example only: Workspace confirms prior delayed-banner opt-in. Banner observed 1 October 2026. Creator account located. Migration control present, but migration not yet approved internally. Latest published GPT version requires owner review. Selected model will not carry over. User access to any replacement remains unverified.

This entry separates six facts that are often collapsed: cohort eligibility, banner delivery, creator-account location, control visibility, source readiness and replacement access. It makes no claim that migration is one-click or feature-equivalent.

The practical next step depends on risk. For a low-consequence writing aid, the owner can prepare a small set of familiar prompts and one harder case for later comparison, following OpenAI’s documented advice. For a GPT used in security, privacy, financial, employment, government, healthcare or other consequential work, a qualified human must review the source material, permissions, proposed outputs and any action before deployment or reliance. Keep secrets and untrusted data out of prompts, including during readiness checks.

Decision rule: if the banner is visible but the migration control is not, the workspace has received notice but has not verified workflow availability. If both are visible but the latest published version has not been reviewed, the workflow may be available but the source is not ready. If migration is completed but intended users cannot install or access the replacement, the transition is not operationally complete.

Case example: the Enterprise workspace with no 1 October banner

Now consider an Enterprise workspace where no banner is visible on 1 October. There are several source-consistent explanations: the workspace may not have opted into delayed migration banners; the viewer may be using the wrong account or workspace; the notice may be exposed differently; or availability may vary. The official evidence does not support diagnosing the absence more precisely without account-specific information.

The first step is not to declare that OpenAI missed a universal deadline, because no universal 1 October banner promise exists. The administrator should verify whether the workspace was actually in the delayed-banner cohort. They should then check whether an earlier administrator notice was received, inspect the originating workspace for each GPT and consult the current retirement FAQ. If necessary, they should use their established support route for account-specific clarification.

The second step is to proceed with tasks that do not depend on the banner. Build a list of GPTs, creators, business owners, intended user groups and current access restrictions. For each item, record whether it is published or remains a draft. This is time-sensitive because OpenAI calls 26 October the planned end of new GPT creation and advises publishing drafts needed for the documented migration workflow before that cutoff.

Publication should not be automatic. Publishing a draft makes it the source candidate for migration, but it may also preserve incomplete or inappropriate material as the latest published version. The owner should remove secrets, exclude untrusted content, confirm that files are authorised for the intended use and obtain required human approval before publication. Publication for migration does not require an unsupported claim that the GPT must be made public; the relevant fact is that the documented workflow uses the latest published version.

A suitable sample status entry is:

Example only: No delayed migration banner observed on 1 October. Prior delayed-banner opt-in not yet confirmed. Migration control absent or unverified in creator account. Inventory and publication review proceeding against the planned 26 October creation cutoff and scheduled 11 December standard retirement date. No deferral assumed.

This wording avoids two opposite mistakes. It does not treat a missing banner as proof that the workspace is excluded from retirement, and it does not treat the account as defective merely because a targeted notice is absent. It keeps preparation tied to the documented timetable while reserving capability claims for direct account evidence.

Decision rule: when a banner is absent, continue all reversible preparation and avoid irreversible assumptions. Inventorying ownership, reviewing publication state and planning user communications are justified by the announced schedule. Claiming migration availability, publishing unreviewed content or relying on a conditional February date is not justified without further evidence.

A separate article covers an earlier, plan-specific change involving end of new Custom GPT creation on personal plans. It does not establish migration access or replacement feature parity in an Enterprise workspace; check the current official FAQ and the affected workspace before relying on a date.

A notice-and-ownership checklist for 1 October

The appropriate checklist differs by role. A creator needs evidence about the GPT’s source state; a user needs clarity about continuity and replacement access; an administrator needs a workspace-wide view of notice, ownership and exceptions. None of these roles should infer readiness from a date alone.

For a custom-GPT creator

1. Locate the originating account and workspace. OpenAI says migration must be approached from the account or workspace where the GPT was created. If the GPT appears in a user’s history or has been shared with them, that does not make them its creator.
2. Confirm ownership. Record the responsible person and a backup owner. If the listed creator has left or cannot access the workspace, escalate the ownership problem now rather than waiting for retirement.
3. Record publication state. Mark the GPT as published, draft-only or published with later unpublished edits. The distinction matters because the documented workflow uses the latest published version.
4. Review drafts before the planned cutoff. Decide whether the draft represents a GPT that should be preserved. Publish only after human review and before the planned 26 October cutoff if it is needed for the documented migration flow.
5. Check the migration control. Report its actual state in the originating account: visible and permitted, visible but blocked, or absent. Avoid asserting a reason that the account does not reveal.
6. Record non-persistence of model choice. OpenAI states that the selected model does not carry over. Do not describe any prior model selection as preserved.
7. Prepare, but do not claim, validation. Save representative prompts and one harder case for later human comparison. These are suggested examples based on OpenAI’s advice, not proof that results will match.

For a user of somebody else’s GPT

1. Identify the owner. Ask who created or maintains the GPT and which workspace governs it. Being able to use it does not confer migration authority.
2. Ask for the applicable date. The default planning date is 11 December, but an approved qualified Enterprise deferral may create a different applicable date. Request workspace-specific confirmation rather than relying on general discussion.
3. Do not assume replacement access. OpenAI says access and sharing do not automatically carry over. Ask how the replacement will be distributed and which permissions will be required.
4. Preserve necessary work outside the GPT. Existing GPT conversations do not move through the documented migration. Subject to organisational policy and data-handling requirements, identify any work product that must be retained in an approved system. Do not paste secrets or sensitive records into prompts to create an informal backup.
5. Request human-reviewed continuity guidance. For consequential uses, do not rely on a replacement until its owner and appropriate human reviewers have confirmed the permitted use, access and review process.

For an Enterprise workspace administrator

1. Verify cohort status. Determine whether the workspace opted into delayed migration banners. Without that fact, 1 October is not a meaningful expected-delivery date for the workspace.
2. Separate notice from control availability. Record banner visibility and migration-control visibility in different fields. This prevents a banner screenshot from being treated as proof that creators can migrate.
3. Build an ownership register. Include GPT name or internal identifier, originating workspace, creator, business owner, publication state, affected users and applicable retirement date. Avoid copying prompt contents or sensitive files into a general inventory.
4. Plan against the standard date. Use 11 December unless the organisation has current, affirmative evidence of an approved qualified deferral. A request, expectation or missing banner is not approval.
5. Prioritise publication decisions before 26 October. Ask owners to review draft-only GPTs and unpublished edits. Do not direct blanket publication; require a content and data review first.
6. Prepare access communications. Tell users that old-GPT access does not automatically produce replacement access. Avoid promising an installation date or unchanged behaviour before those points are verified.
7. Escalate consequential uses. Security, privacy, financial, employment, government, healthcare and other high-impact workflows require responsible human review. Migration status must not substitute for policy, professional judgement or approval.

A minimum evidence record for each workspace

An organisation does not need to wait for a full technical audit to create a defensible notice record. It does, however, need enough information to avoid confusing dates, capabilities and ownership. The following fields are a suggested method rather than an OpenAI product guarantee:

• workspace name or approved internal identifier;
• whether delayed migration banners were previously selected, with the evidence source;
• date and wording of any administrator or user notice;
• creator account and workspace for each GPT;
• responsible creator and business owner;
• latest published version date, where available;
• whether draft or unpublished changes exist;
• migration-control state observed by the authorised creator;
• working retirement date and the evidence supporting any exception;
• affected user group and named communication owner;
• human reviewer for consequential uses; and
• next verification date.

Keep this register factual. “Banner observed” is a fact; “migration available to everyone” is an inference that the banner cannot support. “Deferral requested” is a fact; “retirement moved to February” is unsupported until approval is confirmed. “Plugin created” does not establish that users can install it, reach connected systems or reproduce the old GPT’s behaviour.

Example decision sequence: if the workspace confirms delayed-banner enrolment and sees the banner, record notice delivery and test creator-level availability. If the workspace confirms enrolment but sees no banner, record the discrepancy and seek account-specific clarification while continuing preparation. If enrolment cannot be confirmed, treat 1 October as non-diagnostic and plan against the later standard milestones. In all three cases, do not wait to identify unpublished work that may need review before 26 October.

What readers can safely conclude today

As of 1 October 2026, OpenAI has published a retirement timetable and a documented migration direction, but the company’s own qualifications prevent a universal availability claim. Existing custom GPTs remain usable until their applicable retirement date, subject to existing permissions. The standard date is scheduled for 11 December; 11 February applies only to affected Enterprise workspaces with a qualified, approved deferral.

The October date should prompt verification of notices and account-level access. A workspace in the delayed-banner cohort should check whether its notice arrived and whether creators can separately access the migration workflow. A workspace outside that cohort, or one whose cohort status is unknown, should not expect the date to function as a global release promise. Both should prepare for the planned 26 October creation cutoff and the scheduled standard retirement date.

The governing rule for this stage is: dates establish planning pressure; only account evidence establishes present capability. Use the FAQ and current workspace notices to set the timetable, use the originating creator account to verify migration access, and require human review before relying on any replacement—especially where security, privacy, money, employment, government services, healthcare or other consequential decisions are involved. Never place secrets or untrusted data in prompts during inventory, migration preparation or later validation.

Three different decisions: creator, user and workspace administrator

OpenAI’s Custom GPT Retirement and Migration FAQ, as published on 1 October 2026, creates different responsibilities for three groups. A creator must preserve the correct published source and assess the replacement. A user of somebody else’s GPT must identify the owner and obtain separate access to any replacement. A workspace administrator must establish which GPTs belong to the workspace, whether migration controls are enabled, and whether intended users have the necessary plugin, app and source-system permissions.

The distinction matters because access to an existing GPT does not make someone its owner. OpenAI says migration must be performed from the account or workspace in which the GPT was created. A user who can open a shared GPT cannot assume that it appears under their own creator controls, while an administrator should not assume that every GPT used by employees was created in the Enterprise workspace.

A practical first step is to classify each relevant GPT using evidence from the signed-in product rather than memory:

1. Record the GPT’s name and current page or internal reference.
2. Record who believes they created it.
3. Verify the account or workspace in which it appears under the creator’s GPT management area.
4. Record whether the organisation owns that workspace or merely permits access to it.
5. Identify the people who use the GPT but do not control its source configuration.
6. Assign an administrator or service owner to resolve any disputed or unknown ownership.

Decision rule: treat the account or workspace in which the GPT was created as the operational source of ownership for this migration exercise. Do not treat popularity, authorship of the instructions, current employment or possession of a shared link as proof that another account can migrate it.

For example, suppose a team member designed a GPT’s instructions for a department but created the GPT in a personal ChatGPT account. The department may consider the workflow organisational, yet the documented migration path still depends on the originating account. The administrator should record that mismatch and arrange an authorised resolution before relying on the replacement. This is a hypothetical triage example, not a statement that OpenAI provides an automatic ownership-transfer mechanism.

The creator’s immediate decision: preserve the right source state

For a creator, the most time-sensitive distinction is between the GPT’s latest published version and its current draft. OpenAI says the documented workflow migrates the latest published version. Drafts and unpublished edits do not transfer. “Published” describes the source state used by the workflow; it should not be confused with making a GPT publicly discoverable.

This creates a specific risk. A creator may open a GPT, see recent instructions or files in the editor, and assume that those changes will become part of the plugin. If the changes remain unpublished, they are outside the documented migration source. The migration can therefore reflect an older operational state even though the editor displays newer work.

Creators should complete the following source-state check before OpenAI’s planned 26 October 2026 end to new custom-GPT creation:

1. Open the GPT from the account or workspace where it was created.
2. Identify the latest published version rather than relying on what is visible in an unfinished editing session.
3. Compare that version with any draft instructions, newly added files, changed examples and adjusted tools.
4. Decide which draft changes are actually approved for operational use.
5. Publish the approved state before the planned cutoff if it must be available to the documented migration workflow.
6. Keep a separate, controlled record of the approved instructions, source files and intended behaviour for later review.

Decision rule: publish only a reviewed state that the organisation is prepared to treat as the migration source. Do not publish an incomplete draft merely to meet a date. If the draft contains unapproved behaviour, stale confidential material or experimental instructions, the safer choice is to resolve those issues first and escalate any timing risk.

The trade-off is between migration readiness and configuration control. Publishing the latest work may preserve intended changes, but publishing hurried or unreviewed material can formalise errors. Leaving a draft unpublished protects the current production configuration, but the unpublished work will not enter the documented migration flow. The creator should make this trade-off explicit in the inventory rather than discovering it after migration.

A hypothetical record might read: “Latest published version contains the approved support policy and three reference files. Draft adds an unapproved escalation instruction and a replacement price list. Decision: do not publish until the policy owner and finance reviewer approve their respective changes.” This is an example of a useful control record, not a product-generated report.

Replacing a custom GPT is not a simple relabelling exercise. The guide to migrating a Custom GPT to a ChatGPT plugin covers instructions, reference files, app connections, testing and access, which are the areas a creator would need to assess.

The 26 October creation freeze does not mean editing stops

OpenAI describes 26 October 2026 as the planned end of new custom-GPT creation. The FAQ also distinguishes that creation freeze from editing existing, unmigrated GPTs: the planned freeze does not stop creators editing those existing GPTs. This distinction prevents two opposite mistakes.

The first mistake is postponing a genuinely needed new GPT until after the planned creation cutoff on the assumption that editing access also creates new GPTs. The second is rushing every existing GPT into a final state because someone interprets 26 October as an editing deadline. The official description supports neither interpretation.

Creators can triage planned work into four queues:

Work item	What the date means	Suggested action
A new GPT that does not yet exist	The planned creation freeze is directly relevant.	Decide before 26 October whether creating it is still justified, considering the announced retirement timetable.
An existing GPT with an approved unpublished draft	The latest published version, not the draft, is the documented migration source.	Publish the approved version before the planned cutoff if it is needed for migration, while continuing to check account-specific notices.
An existing, unmigrated GPT that needs maintenance	The planned creation freeze does not itself stop editing.	Continue controlled maintenance, but record which version is published and reassess the migration source after every material change.
A migrated GPT whose original has become read-only	This is a post-migration state, not the general effect of the creation freeze.	Make future approved changes in the replacement workflow rather than expecting to edit the original GPT.

Decision rule: use 26 October to govern whether a new GPT must be created and whether a required draft has been published; do not use it as a blanket “all editing ends” date. Because OpenAI labels the date planned and says account or workspace availability may differ, verify the current workspace notice before acting.

Migration changes the creator’s control over the original

OpenAI says that after migration the original GPT remains usable until its applicable retirement date but becomes read-only, and the creator cannot delete it. That is materially different from both an unmigrated editable GPT and a retired, inaccessible GPT.

A creator should therefore treat the migration action as a change-control boundary. Before starting it, complete any approved source updates, capture the version being migrated and decide how users will be told which version is authoritative. After migration, do not plan on returning to the original GPT to correct its instructions or remove it.

A suitable pre-migration procedure is:

1. Confirm that the creator is signed into the originating account or workspace.
2. Confirm that the latest published version is the intended source.
3. Record the current sharing audience and principal use cases; sharing itself will not carry over.
4. Save approved comparison prompts without including secrets, personal data or untrusted external content.
5. Identify an owner for reviewing the replacement’s instructions, files, tools and access.
6. Warn users that the original may remain available for a period even though it can no longer be edited after migration.
7. Only then use the migration control if it is actually available in that account or workspace.

Decision rule: do not migrate merely because a banner appears. Migrate when the source state is approved, a replacement owner is assigned and there is a plan to distinguish the read-only original from the replacement. A banner is a notification; it is not evidence that these operational prerequisites have been completed.

Consider a hypothetical creator who finds an obsolete instruction immediately after migration. The documented read-only state means the remediation plan should not depend on editing or deleting the original GPT. The creator should correct the replacement through its supported controls, tell affected users which version to use and record the discrepancy for review. For a security, privacy, money, employment, government or similarly consequential workflow, use a human decision-maker to assess whether use should pause until the issue is resolved.

The selected model is not part of the preserved source

OpenAI states that the selected model does not carry over. This is separate from the latest-published-version rule: publication can preserve the relevant published instructions and other documented configuration elements, but it does not preserve the GPT’s model selection.

A creator must therefore avoid describing the replacement as the same GPT running unchanged. In particular, migration does not establish that a previous choice such as GPT-5.5, GPT-5.5 Mini or any other model persists. OpenAI says Enterprise defaults apply in Enterprise workspaces, but that does not guarantee equivalent output.

The practical response is to describe requirements in observable terms rather than by inherited model name. Record what users need the workflow to do: required source use, output structure, refusal boundaries, tool invocation and escalation conditions. Then review the replacement against those requirements using non-sensitive examples.

Decision rule: if acceptance depends on a particular model selection carrying over, the documented migration does not satisfy that dependency. Reframe the acceptance test around required behaviour or hold deployment until the relevant product and workspace configuration has been verified.

For example, “the replacement must return a four-column comparison and cite only the supplied reference material” is a reviewable requirement. “The replacement will behave identically because the old GPT used a named model” is not supported by the migration FAQ. Any example output should be treated as a sample for human review, not a product guarantee.

The user of somebody else’s GPT has an access problem, not a migration task

A user who did not create the GPT generally cannot solve retirement by looking for a migration control in their own account. OpenAI says the workflow must be used in the account or workspace where the GPT was created. The user’s job is to identify the owner, preserve legitimate workflow requirements and obtain access to the replacement through the appropriate distribution and permission process.

Existing access to the original GPT does not automatically grant access to the migrated plugin. OpenAI also says sharing settings do not carry over and that a migrated personal plugin starts private. If its creator intends public distribution, a separate submission is required. In a managed workspace, installation and use may also depend on plan, role, workspace policy, app availability and source-system permissions.

A user should follow this procedure when a retirement or migration notice appears:

1. Confirm that the notice refers to custom GPT retirement or migration rather than assuming any product banner has the same meaning.
2. Record the GPT’s exact name and the workspace or account context in which it is used.
3. Identify the creator or responsible team from available organisational records.
4. Ask whether a replacement is planned, migrated, validated and approved for the user’s role.
5. Ask how access will be granted; do not assume the old shared link will redirect or confer permission.
6. Preserve only non-sensitive examples of the user’s legitimate workflow requirements.
7. Keep using the original only while it remains available and permitted, and follow the owner’s cutover instruction.

Decision rule: if the user cannot establish who owns the GPT or how the replacement will be distributed, escalate to the workspace administrator rather than creating an unofficial copy. An unofficial recreation can omit controls, use stale files or process information outside the intended workspace.

Users of a GPT built by someone else face a different access question from a model’s scheduled retirement. For a comparison point, the GPT-5.4 retirement transition guidance covers a 23 July deadline and replacement-model mappings; it does not imply that access to someone else’s custom GPT will transfer.

Hypothetical notice triage for an end user

Suppose a user sees a banner on 1 October in an Enterprise workspace that had opted into delayed migration banners. The banner is consistent with OpenAI’s target for that particular cohort, but it does not establish that the user owns any GPT, that every creator has the migration option, or that a replacement is ready. The correct action is to identify the affected GPTs and their owners, not to announce that custom GPTs have retired.

A useful hypothetical message to an internal support team would be:

Example: “I saw a custom-GPT migration notice in the Finance workspace. I use ‘Policy Assistant’, but I did not create it. Please confirm its owner, whether a replacement is planned and how authorised users will receive access. I will continue using the existing GPT only under current permissions until the owner gives a reviewed cutover instruction.”

This message separates observed evidence from assumptions. It reports the banner, names the dependency and asks for ownership and access information. It does not claim that migration is globally available or that 1 October is a deadline.

Now consider the opposite case: a user sees no banner. That absence is not evidence that the GPT is exempt from the announced transition. OpenAI says availability may differ by account or workspace, and 1 October applies only as a target for Enterprise workspaces already opted into delayed migration banners. The user should check the applicable workspace communication and owner plan rather than treating silence as cancellation.

Decision rule: a visible notice triggers ownership and readiness checks; a missing notice triggers a workspace-status check. Neither condition, by itself, determines whether a particular replacement is usable.

False alarms: what not to infer from common signals

Notice triage should reject signals that resemble migration evidence but do not prove it. The following examples are hypothetical, while the distinctions derive from OpenAI’s documentation.

Observed signal	Possible false inference	What to verify instead
A user sees a plugin directory.	“This account can migrate every GPT.”	Check the originating account for the migration option and verify workspace plugin policy separately.
A user has access to Codex through their plan.	“The replacement is installed and usable in every surface.”	Verify plugin availability, installation, role, surface and app permissions for that user.
An Enterprise user sees a 1 October banner.	“Custom GPTs retire today.”	Treat it as the delayed-banner target for the qualifying cohort; use the applicable scheduled retirement date from the workspace notice.
A creator can still edit an existing GPT after 26 October.	“The creation freeze did not happen, so all dates are irrelevant.”	Distinguish editing an existing unmigrated GPT from creating a new one.
A replacement plugin has the same name as the GPT.	“It has the same instructions, model, sharing and integrations.”	Review the latest published source, model non-transfer, replacement configuration and access separately.
A colleague used the old GPT.	“They automatically have replacement access.”	Confirm plugin distribution, workspace policy, app authorisation and source-system permission.
An administrator enables a plugin or connected app.	“Every user can read all underlying data.”	Check each user’s role, provider authorisation and permissions in the source system.
An Enterprise workspace expects more time.	“Its retirement date is automatically 11 February 2027.”	Require evidence of a qualified, approved deferral; otherwise plan against the standard scheduled date.

Decision rule: treat each signal as evidence for only the fact it directly demonstrates. Directory visibility demonstrates visibility; it does not demonstrate migration eligibility. A banner demonstrates delivery of a notice; it does not demonstrate successful migration. Installation demonstrates installation; it does not demonstrate access to an external data source.

The administrator’s first task: build an ownership register

A workspace administrator needs a broader view than either a creator or a user. The administrator must distinguish GPTs created inside the managed workspace from external or personal GPTs merely used by workspace members. Without that distinction, a migration programme can assign tasks to people who lack control over the source.

The register should contain only information needed for the transition and should not copy secrets, personal data or untrusted content into prompts. At minimum, record:

• GPT name and an internal identifier;
• originating account or workspace;
• verified creator and current business owner;
• latest published-version status;
• whether an unpublished draft contains required changes;
• intended user groups;
• whether the GPT supports a consequential process;
• current migration-control status in the originating account;
• replacement owner and review status;
• planned user-notification and cutover route;
• app or source-system owners whose approval may be required;
• the applicable retirement date and evidence for any approved deferral.

Decision rule: classify an item as migration-ready only when its origin, creator, published source and replacement owner are verified. Usage logs, employee recollection or a public link may help locate a GPT, but none of them substitutes for checking the originating account or workspace.

The administrator should also separate responsibility from technical control. A department may be accountable for the workflow while an individual creator controls the GPT. Conversely, a workspace administrator may control plugin policy but not own the source-system data. Assign both a business owner and a technical owner where those roles differ.

A three-person action matrix

Situation	Creator	User of another person’s GPT	Workspace administrator
No migration option is visible	Confirm the originating account or workspace and check whether plugin access is disabled or migration has not reached the account.	Ask the owner for status; do not assume personal migration access is required.	Check workspace notices and relevant controls without claiming a universal outage.
The latest work is still a draft	Review and publish only the approved state needed for migration.	Tell the owner which current behaviour is required, without trying to alter the source.	Track publication risk and approval ownership before the planned cutoff.
The GPT has migrated	Review the replacement and recognise that the original is read-only.	Wait for explicit replacement access and a cutover instruction.	Check distribution, policy, app access and user readiness separately.
The old GPT remains usable	Label which version is authoritative during coexistence.	Use it only under existing permissions and until the applicable retirement or controlled cutover.	Prevent the coexistence period from becoming an unowned permanent exception.
A replacement uses a connected app	Document the intended app-dependent tasks.	Authorise only approved access and report missing permissions.	Verify plugin policy, app controls, provider approval and source-system permissions as separate layers.
A workflow affects security, privacy, money, employment or government services	Provide configuration evidence, not an assurance of correctness.	Do not rely on output as the final decision.	Require an accountable human review and the organisation’s existing approval process before deployment or action.

This matrix deliberately avoids treating “migrated” as “ready”. The creator can complete the documented conversion while users still lack access, an app remains unavailable, or an administrator has not approved installation. Conversely, an administrator can enable a plugin category without proving that the creator migrated the correct published version.

User notification requires two messages, not one

OpenAI’s documentation says access and sharing do not automatically carry over. Administrators and creators should therefore separate an advance retirement notice from a replacement-access notice.

The advance notice should explain that the existing GPT remains usable until its applicable retirement date, subject to existing permissions, while stating that a replacement is being assessed. It should identify the owner, the affected workflow and where users can ask questions. It should not promise that every user will receive the same plugin access.

The replacement-access notice should be sent only after the intended route has been checked for the relevant audience. It should identify the replacement, state whether the old GPT is still temporarily available, explain how users obtain authorised access and list any known scope differences. For consequential workflows, it should also preserve the existing human approval requirement.

A hypothetical advance notice could say:

Example: “OpenAI has scheduled the standard retirement of custom GPTs for 11 December 2026. Our ‘Supplier Summary’ GPT remains available under its current permissions while its owner reviews a replacement. Do not create an unofficial copy or place supplier-confidential information into another tool. We will issue a separate access notice after the replacement and its permissions have been reviewed.”

A hypothetical replacement notice could say:

Example: “The reviewed replacement for ‘Supplier Summary’ is now available to the approved pilot group through the managed workspace. Access to the former GPT does not grant access automatically. Request access through the existing service owner, and retain human procurement review for any financial or supplier decision.”

Decision rule: do not combine “a replacement exists” with “you are authorised and ready to use it”. Send the second message only when distribution and required access have been verified for its stated audience.

How administrators should handle disputed ownership

Ownership disputes are likely where a GPT was created by a former employee, in a personal account or in a different workspace. The official migration rule makes the creation location operationally important, but it does not resolve organisational ownership, employment or intellectual-property questions. Those consequential questions require review by the appropriate human owners and advisers.

An administrator can still perform evidence-based triage:

1. Mark the GPT as “origin unverified” rather than assigning ownership by assumption.
2. Identify the current users and business process without copying sensitive conversations.
3. Ask the claimed creator to verify the originating account or workspace.
4. Identify approved source documents and requirements independently of the GPT configuration.
5. Escalate account, employment, privacy or legal questions through the organisation’s established process.
6. If a replacement must be built, treat it as a separately governed implementation rather than claiming it is the migrated original.

Decision rule: where the originating account cannot be accessed or verified, label the work as recovery or replacement planning, not migration completion. Do not ask anyone to disclose passwords, authentication tokens or other secrets to prove control.

A bounded readiness review before user cutover

This section is not a detailed portability audit, but each persona needs a minimum check before directing users to a replacement. OpenAI advises reviewing instructions, files, examples and tools and comparing familiar prompts with at least one harder case. That is an adoption check, not proof of model equivalence or a benchmark.

A creator can prepare a small review pack containing:

• one ordinary, non-sensitive prompt representing the most common legitimate task;
• one harder example involving ambiguity or multiple constraints;
• the expected output structure;
• the approved reference material that should be used;
• the tool or app action expected, if applicable;
• conditions under which the workflow should defer to a person.

The reviewer should inspect whether the replacement follows the intended instructions, uses the expected references, produces complete output in the required format and invokes only the intended tools. Any output is evidence for that example only. It is not a guarantee of future accuracy, response time, cost, token use or feature parity.

Decision rule: if the replacement fails a requirement necessary for safe operation, do not resolve the discrepancy by merely warning users that “AI can make mistakes”. Correct the configuration, narrow the permitted use or pause the cutover. Security, privacy, financial, employment, government and other consequential decisions must retain accountable human review.

What each persona should have by the end of notice triage

The creator should have a verified originating account or workspace, an approved latest published version, a record of any excluded draft changes, an assigned replacement owner and a plan for the original’s read-only state. If the migration control is absent, the creator should record that account-level fact without treating it as a contradiction of OpenAI’s announced schedule.

The user should have an identified owner, an answer about whether a replacement is planned, a clear statement that old access does not transfer automatically and a channel for requesting authorised access. Until then, the user should neither assume exemption from retirement nor create an unsanctioned substitute containing organisational data.

The workspace administrator should have an ownership register, an audience map, a list of unresolved origin cases, the applicable date for each workspace and a separation between migration status and deployment status. A qualified, approved Enterprise deferral may move the applicable date to 11 February 2027; an expectation, request or missing banner does not.

The final decision rule is status-specific: “announced” means OpenAI has documented the transition; “available” means the relevant account exposes the control; “migrated” means the documented workflow has been completed; “reviewed” means people have examined the replacement against stated requirements; and “authorised for use” means the intended user has the necessary workspace, plugin, app and source-system permissions. No one of these statuses proves the others.

Enterprise approval is a chain, not a single switch

OpenAI’s Custom GPT retirement and migration FAQ, reviewed for this article on 1 October 2026, separates the existence of a migration option from permission to deploy and use the resulting plugin. That distinction matters most in Enterprise workspaces. A creator might see Migrate to plugin but still lack permission to share or publish the replacement. An administrator might allow plugins while leaving installation unavailable to a particular role. An intended user might install the plugin yet remain unable to open a connected app or retrieve records from its underlying service.

Treat these as separate approval layers:

1. Migration availability: the relevant creator or administrator can see the documented migration option in the account or workspace where the GPT was created.
2. Workspace eligibility: plugin use is enabled under the organisation’s workspace settings and policies.
3. Role authority: the person performing the migration has the required creator or administrative permissions, while those distributing it have the relevant sharing or publishing permissions.
4. Installation permission: intended users are allowed to find or install the replacement under workspace policy.
5. Connected-app approval: any app packaged with the plugin is available and authorised for the relevant workspace and user.
6. Source-system permission: each user already has the necessary rights in the service holding the data.
7. Action permission: any supported read or write action is permitted by the applicable app, workspace and provider controls.
8. Operational acceptance: an accountable human has reviewed the replacement and approved it for its intended use.

Passing one layer does not satisfy the next. OpenAI’s plugin documentation says a plugin does not grant new access to data in a connected app. The app must be available, and the person must already have permission in the source system. Similarly, provider authorisation does not override workspace restrictions, action controls or source-system rights. The practical decision rule is therefore: do not describe a replacement as “available to users” until a named user in the intended role has passed every applicable layer.

For example, suppose a creator migrates a GPT whose instructions refer to an approved document service. The migration can create a private plugin and include the relevant app mapping, but this does not establish that a finance analyst may read a restricted folder. The analyst still needs plugin access, app availability, provider authorisation and permission to that folder. If any one of those checks fails, record the replacement as migrated but not accessible for the intended use, rather than as fully deployed.

Creator, administrator and user roles lead to different decisions

A creator’s authority centres on the GPT they created and, where enabled, the migration action. OpenAI says the person must be in the account or workspace where the GPT was created. Finding the same GPT through a link, a shared page or another workspace does not prove that the person can migrate it. If the option is absent, first verify account and workspace identity before treating the absence as a rollout problem.

A workspace administrator has a broader governance role but should not assume that administrative status supplies every content, app or source-system permission. Administrators need to determine whether plugins are enabled, which roles may use them, whether installation is allowed, and who may share or publish. OpenAI’s administrative documentation distinguishes these controls from provider authorisation and from permission inside an underlying app. The administrator’s decision is therefore whether the workspace permits the route; it is not automatically a judgement that every connected data source is suitable or accessible.

An end user has no migration task merely because they used the original GPT. The retirement FAQ says access to the old GPT does not automatically confer access to its replacement. The user may need permission to install or use the plugin, authorisation for a connected app and an existing account with appropriate source-system rights. A user-facing notice should consequently distinguish “the old GPT is scheduled to retire” from “you have been approved for the replacement”. Combining those messages would obscure an unresolved access decision.

A practical responsibility assignment can use four named owners:

• Content owner: confirms that the latest published GPT version is the intended migration source and reviews transferred instructions and reference files.
• Workspace owner: confirms role, plugin, installation, sharing and publishing settings.
• System owner: confirms that the connected app is approved and that user permissions in the source service are appropriate.
• Service approver: signs off the replacement for its defined audience and use, after documented review.

One person may hold more than one role in a small workspace, but the decisions should remain separately recorded. This prevents a creator’s content approval from being misread as an administrator’s deployment approval, or an administrator’s enablement decision from being treated as permission to expose source data.

Administrators planning a replacement for a custom GPT should establish which tools the replacement needs. The GPT-5.5-to-GPT-5.6 and Codex migration tool permissions playbook covers inventory, representative evaluations, rollback and sign-off, offering a governance lens without treating a model transition as custom GPT portability.

What Enterprise controls add to the migration question

OpenAI’s administrator guidance says that in Enterprise and Education workspaces, plugin and app defaults differ by plan and workspace. It also describes role access, action controls, provider authorisation and ChatGPT app permissions as distinct checks. That creates a materially different migration path from a personal creator simply seeing an account-level option: an Enterprise replacement may require coordinated decisions by several owners before an intended user can operate it.

OpenAI documents permission states including Always ask, Allow read actions and, where supported for an individual app, Allow all actions. These labels should not be interpreted as universal capabilities. An app might not support a particular action; another workspace restriction may still block it; the provider may require separate authorisation; and the user may lack permission in the source system. Use the narrowest setting that supports the approved task, then verify the effective result with a suitable user account.

Consider an example plugin intended to retrieve policy documents but not alter them. A suggested administrative procedure is:

1. Define the approved purpose as document retrieval and summarisation, not document modification.
2. Confirm that the relevant app is allowed for the intended role.
3. Select a read-oriented permission where the documented control and app capability support it.
4. Use a designated test account that has access only to suitable non-sensitive review material.
5. Confirm that the account can retrieve an allowed item and cannot retrieve an item outside its source-system permission.
6. Record the app, role, workspace policy and source-system group used in the check.
7. Obtain human approval before broadening access or enabling any write-capable operation.

This is a suggested control procedure, not a product guarantee or a report of testing performed for this article. Its purpose is to expose the difference between workspace enablement and actual data access. Never place passwords, access tokens, private keys, confidential records or other secrets in prompts to conduct the check. Use approved test content and the provider’s proper authentication route.

The decision rule for write capability should be stricter than for read-only use. If a plugin can create, change, submit, approve, delete or publish information, require an identified system owner and explicit human confirmation of the proposed change. “Allow all actions” is not itself evidence that unrestricted action is appropriate. For security, privacy, financial, employment, government, healthcare, legal or other consequential activity, a qualified human must review both the access design and the resulting decision or action.

A banner is evidence of a notice, not proof of every prerequisite

The 1 October 2026 entry in OpenAI’s retirement FAQ is narrowly framed. It is a target for a migration banner in Enterprise workspaces that had already opted into delayed migration banners. It is not a global rollout date, migration deadline or retirement date. OpenAI also says migration access may become available at different times and that a target migration date does not guarantee every account can migrate on that day.

When a banner appears, preserve its precise wording, date, workspace identity and intended audience. Then check what it actually establishes. A banner may tell administrators or users that a migration phase is available or approaching, but it does not by itself establish that:

• every creator in the workspace can see the migration control;
• every GPT is eligible under the documented workflow;
• plugin use and installation are enabled for every role;
• a connected app has been approved;
• users have source-system access;
• sharing or publishing has been authorised;
• the replacement preserves behaviour or model selection; or
• the workspace has an approved retirement deferral.

The operational response to a banner should be a verification sequence, not an immediate all-user announcement. First, confirm that it belongs to the expected workspace. Second, ask a nominated owner of a published GPT to check for the migration control in the originating account. Third, inspect relevant plugin and role policies. Fourth, identify the intended replacement audience and connected systems. Finally, set a review date and decision owner. Only then issue a user notice that states what is available now and what remains conditional.

For example, a defensible internal message might say: “OpenAI’s migration notice is visible in Workspace A. The platform team is checking creator eligibility, plugin policy and replacement access. Continue using the existing GPT under current permissions until we confirm a cutover date.” That sample wording is an editorial example, not an OpenAI template or guarantee. It avoids telling users that migration is complete merely because the banner has appeared.

If no banner appears in a delayed-banner workspace on 1 October, do not infer that the organisation is exempt from retirement. Verify that the workspace had opted into the delayed-banner cohort, check the account-specific notices available to administrators and consult the current retirement FAQ. Record the missing notice as an unresolved account-level status. OpenAI’s target language supports escalation and rechecking; it does not support inventing an alternative date.

Plugin installation and connected-data access must be tested separately

A replacement plugin can contain skills, apps or app templates, according to OpenAI’s plugin help documentation. A skill is an instruction-led capability; an app connects to an external service. OpenAI’s developer documentation also describes plugins that can include a Model Context Protocol (MCPA protocol for connecting AI applications with tools and data sources through defined interfaces. Open glossary entry) server, which provides controlled tools or external-service access. These components are not interchangeable, and successful migration of instructions does not prove that an old custom action has been recreated.

The retirement FAQ explicitly says GPT custom actions do not transfer through the migration workflow. Where the old GPT relied on one, a replacement might require an available app or a separately engineered MCP integration. That is a new technical and approval task. Do not tell users that an integration exists until its supported capabilities, authentication route, workspace approval and source permissions have been confirmed. Nor should a rebuilt connection be presented as equivalent merely because it reaches the same service.

A concise access check should distinguish at least four outcomes:

Observed state	What it establishes	What remains unresolved
The user can see the plugin	Discovery or visibility is available on that surface	Installation, app authorisation and source access
The user can install the plugin	Installation is permitted for that account and role	Connected-app capability and underlying data rights
The user can authorise the app	The provider’s authorisation step succeeds	Permission to specific records and permitted actions
The user can retrieve an approved record	The tested read path works for that record and identity	Other records, roles, actions and product surfaces

The decision rule is evidence-specific: approve only the role, action, source and surface actually checked. A successful read by an administrator does not establish access for an ordinary user. A successful use in ChatGPT does not establish identical capability in Codex. OpenAI’s developer documentation says ChatGPT and Codex share a plugin directory while individual capabilities may be surface-specific. Directory visibility is therefore weaker evidence than an authorised task completed by the intended role on the intended surface.

The qualified deferral requires affirmative confirmation

OpenAI lists 11 February 2027 only for affected Enterprise workspaces with a qualified, approved deferral. It is not a general Enterprise retirement date and should not be entered into a plan merely because the organisation uses an Enterprise workspace. Unless the organisation has account-specific evidence of approval, plan against the standard scheduled retirement date of 11 December 2026 while continuing to monitor official notices.

A deferral record should contain the workspace covered, the approval status, the applicable date, the named internal owner and the source of the account-specific confirmation. It should also identify any limits stated in that confirmation. Do not extend the interpretation to a second workspace, subsidiary, personal account or unrelated GPT unless the notice expressly covers it.

A qualified deferral changes the available time, not the migration contract. It does not imply that drafts will transfer, that the selected model will persist, that conversations will move, that custom actions will be recreated or that prior users will receive access to the plugin. OpenAI’s FAQ says the selected model does not carry over. This rules out assumptions that GPT-5.5, GPT-5.5 Mini or any other prior selection will remain attached to the replacement. The workspace still needs content, permission and acceptance review.

The trade-off is between additional preparation time and prolonged dependency on a retiring surface. A deferral may permit more orderly remediation, but it can also encourage teams to postpone ownership decisions. A sensible rule is to use the extra period for identified blockers with named owners and review dates; do not treat it as permission to defer discovery work. If no blocker is documented, retain the earlier internal readiness target.

Where migration is delayed in a workspace, administrators still need a controlled way to distribute any eventual replacement plugin. The playbook on enterprise plugin marketplace import and governance explains how admins and owners can import public or private GitHub marketplaces into the workspace directory, which concerns deployment control rather than showing that migration is complete.

A conditional timeline for uncertain workspace states

The following timeline uses the status words in OpenAI’s FAQ as of 1 October 2026. It is a planning method rather than a promise of account-level availability.

If the migration option is missing now

1. Confirm that the creator is signed into the account and workspace where the GPT was created.
2. Confirm that the GPT has a published version; the documented workflow uses the latest published version, not a draft.
3. Ask the workspace administrator whether plugin access or the relevant role is disabled.
4. Check the current account-specific notice and OpenAI’s retirement FAQ rather than inferring availability from the calendar.
5. Capture the date, workspace, account role and observed state, without placing confidential GPT content or credentials in a support message or prompt.
6. Assign a recheck date before 26 October and an escalation owner.

If these checks show that migration has not reached the workspace, keep preparing the source state and access plan. Do not create a fictitious migration result or announce a cutover. The decision rule is: absence of the control means “not currently actionable in this account”, not “cancelled”, “exempt” or “available elsewhere”.

If the 26 October planned creation freeze is reached

OpenAI describes 26 October 2026 as the planned end of new custom-GPT creation and advises creators to publish drafts needed for the documented migration workflow before the cutoff. If the date arrives and the workspace can no longer create a new GPT, stop relying on creation of a temporary migration source. Work from eligible existing published GPTs and confirm the current account notice. The FAQ says the planned creation freeze does not stop edits to existing, unmigrated GPTs, but unpublished edits still do not become the migration source.

The practical rule is to separate editing from publishing. If an existing GPT must reflect a required change, have its content owner review and publish the intended version before migration. Keep a record of what was approved. Do not publish sensitive material merely to meet a date, and do not add secrets, personal data or untrusted instructions to a GPT or prompt as a workaround.

If a needed draft was not published before the cutoff, record it as a migration exception. Determine whether an existing published source is acceptable, whether the capability should be rebuilt through another approved route, or whether the service should be retired. A human owner must choose among those outcomes; the migration process should not silently substitute an older published version.

If an account-specific deadline differs

Preserve the account-specific notice and compare its scope with the public FAQ. Check whether it applies to the workspace, a cohort within it, or an approved deferral. Do not overwrite the public timetable for all readers or all organisational accounts. Instead, maintain two fields: the currently documented standard schedule and the account-specific applicable date.

If the notice appears inconsistent or ambiguous, pause irreversible cutover decisions and seek clarification through the organisation’s established OpenAI support or account channel. Continue work that is useful under either date: ownership confirmation, publication-state review, access mapping and replacement acceptance planning. For a security, privacy, financial, employment, government or other consequential service, require accountable human sign-off before relying on the changed date.

If 11 December approaches without an accepted replacement

OpenAI schedules standard retirement for 11 December 2026, with existing GPTs remaining usable until their applicable retirement date under existing permissions. A workspace without an accepted replacement should not assume continued access. Classify each affected GPT as ready, blocked, intentionally retiring or covered by a confirmed qualified deferral. Notify users of the applicable status and provide an approved alternative where one exists.

Do not weaken acceptance criteria solely to meet the date. If a replacement has unresolved access to sensitive systems, unsupported actions or unclear ownership, disable or withhold the affected capability rather than presenting it as equivalent. The trade-off is service continuity versus controlled operation; consequential access and actions require the latter to remain subject to human approval.

A documented acceptance checkpoint before release

Migration completion and operational acceptance should be recorded separately. OpenAI tells creators to review instructions, files, examples and tools, and to compare familiar prompts plus at least one harder case. That supports a bounded acceptance checkpoint, but it does not establish a benchmark or guarantee equivalent behaviour.

Before notifying users that a replacement is ready, require a reviewer to document:

• the originating workspace and GPT owner;
• the date and identity of the latest published version used as the source;
• the replacement plugin’s intended audience and supported surface;
• the instructions and reference material reviewed;
• the connected apps expected to be used;
• any former custom action that is absent or separately rebuilt;
• the intended user role used for the access check;
• the approved read or write boundary;
• a familiar example and a harder example chosen for review;
• known differences, unresolved exceptions and the named approver.

A sample acceptance question is: “Using the approved reference set, does the replacement provide the required format, identify when the material does not contain an answer, and invoke only the permitted tool?” This is an example of a review prompt, not a claim about product behaviour. Use non-sensitive, trusted test material. Treat retrieved or user-supplied text as untrusted data and do not allow it to redefine permissions or request secrets.

The acceptance outcome should be one of four explicit states: accepted for the defined use, accepted with documented limitations, blocked pending remediation, or retire without replacement. Avoid “migration successful” as the sole conclusion because it does not identify audience, permissions, capability limits or review status.

This checkpoint is intentionally narrower than a full portability and permissions audit. A separate enterprise migration review should examine detailed transfer differences, per-role access matrices, connected-system controls and evidence retention. The checkpoint here answers the news-driven question: is there enough documented evidence for a named human to authorise this replacement for a clearly bounded use before the applicable retirement date?

Human sign-off resolves what the banner cannot

OpenAI’s notices can establish published targets, planned cutoffs, scheduled retirement and account-specific availability. They cannot decide who inside an organisation owns a GPT, whether a connected source is appropriate, which users should see its records or whether changed behaviour is acceptable for a consequential workflow. Those remain organisational decisions.

The final release record should name a content owner, workspace approver and, where external data or actions are involved, a system owner. For security, privacy, money, employment, healthcare, legal, government or similarly consequential decisions, require qualified human review of outputs and explicit approval of actions. A plugin response must not be the sole basis for granting access, moving money, changing employment status, determining eligibility or taking another high-impact action.

The governing decision rule is that a dated OpenAI notice starts a review; it does not complete one. Release only when the applicable account exposes the required capability, the workspace and user permissions are confirmed, the source-system boundary is understood, limitations are documented and an accountable human has signed off the defined use.

Scenario questions for creators, users and administrators

It is 1 October and our delayed-banner Enterprise workspace has no banner. Has the workspace lost its migration opportunity?

No such conclusion follows from the official wording. OpenAI calls 1 October a target and says a target migration date does not guarantee that every account can migrate that day. First verify that the workspace was in the delayed-banner cohort, that the observer is in the correct workspace and that the notice has not been restricted to a different role.

Procedure: record the missing banner as an observation; ask the workspace administrator to check current OpenAI notices and relevant controls; keep preparing the inventory and published source state; and avoid telling users that retirement happened on 1 October. Escalate through the organisation’s supported channel if the workspace expected a notice, but do not invent an eligibility explanation.

We can see a banner but not “Migrate to plugin”. Can we announce that migration is live?

Not for that creator. The banner and the account-level migration option are separate evidence. OpenAI says a missing option can mean migration is not yet available or plugin access is disabled; the creator must also be in the account or workspace where the GPT was made.

Decision rule: announce only what has been verified. “The workspace received OpenAI’s notice” is supportable if observed. “All creators can migrate now” requires account-level confirmation for the relevant population and still would not prove that replacements are configured or accessible.

My GPT has important unpublished changes. Can I wait until after 26 October?

The documented migration takes the latest published version, not drafts or unpublished edits. OpenAI says drafts needed for this workflow should be published before the planned 26 October cutoff. It also says the planned end of new creation does not stop edits to existing, unmigrated GPTs, but that distinction should not be used to assume an unpublished source will transfer later.

Procedure: compare the published version with the draft; remove secrets and material that should not become part of the source; obtain the required content, privacy and operational review; then publish the intended version before the planned cutoff if it is needed for migration. Record the version and date. The practical trade-off is between preserving the intended source promptly and allowing enough time for proper human review.

Our workflow relies on a chosen model. Will the migrated replacement retain it?

No. OpenAI’s FAQ states: “The selected model does not carry over.” That rule prevents an assumption that GPT-5.5, GPT-5.5 Mini or any other previous selection persists. This article does not establish those models’ current availability, pricing, performance, context limits or retirement status.

Procedure: list behaviours that matter without treating the old model name as an acceptance criterion; use non-sensitive representative prompts; compare completeness, format, reference use and tool behaviour; and ask a human owner to decide whether the replacement is acceptable. Different output is not automatically failure, but a workflow that depends on an unpreserved behaviour should not be released without review.

Will people who used the original GPT automatically receive the plugin?

No. OpenAI says sharing does not carry over automatically and a migrated personal plugin starts private. Access to the original GPT does not grant access to its replacement. Installation policy, role permissions, app availability, provider authorisation and the user’s source-system permissions can remain separate requirements.

Procedure: define the intended audience; choose the appropriate supported distribution route; confirm workspace policy; test installation with a representative authorised user; and separately verify that the person can access only the source data they are meant to use. Do not copy an old audience list blindly, because the replacement may have different capabilities or data connections.

The plugin directory is visible to a user. Does that prove migration and use are available?

No. OpenAI’s Codex plan guidance distinguishes directory visibility from installation and use, which can depend on plan, workspace settings, role, surface and app permissions. The retirement FAQ separately says migration access can arrive at different times.

Decision rule: treat directory visibility as evidence only that the directory is visible. Verify migration controls for the creator, installation rights for the user, and any underlying app access independently.

Our GPT has a custom action. Will migration rebuild it?

No automatic transfer is documented. OpenAI says GPT custom actions do not transfer through the migration workflow. The replacement may require an available app or technical work involving a custom MCP server, depending on the task and available account options.

Procedure: document what the old action reads, writes and returns; identify whether an approved app supplies the required capability; otherwise route the requirement to a technical and security review. Test read and write paths separately with non-sensitive examples. Do not claim parity merely because a connection exists, and require human confirmation before any consequential write, payment, employment action or government submission.

Does migration preserve old conversations?

No. OpenAI says existing GPT conversations do not move to the plugin. Treat conversation history and the replacement configuration as separate records. Do not paste sensitive historical conversations into prompts merely to recreate context.

Procedure: identify any legitimate operating instructions trapped only in conversation history; rewrite them as reviewed instructions or reference material without copying personal or confidential data unnecessarily; and keep records according to the organisation’s established process. The assigned sources do not provide a basis for making retention or legal-compliance claims.

What happens to the original after migration?

According to the FAQ, it remains usable until its applicable retirement date but becomes read-only, and the creator cannot delete it after migration. That creates a trade-off: migrating sooner may leave more time to validate the replacement, while freezing the original sooner can limit further changes to it.

Decision rule: do not start migration until the intended published source has been reviewed and the owner understands the read-only consequence. After migration, route improvements to the replacement rather than assuming the original can still be maintained.

Can an Enterprise workspace simply use 11 February as its new deadline?

No. The later date applies only to affected Enterprise workspaces with a qualified, approved deferral. Enterprise status alone is insufficient.

Procedure: ask the designated administrator to locate affirmative approval, confirm the workspace it covers and record the accountable owner. If that evidence is absent or ambiguous, continue planning against the standard scheduled 11 December date. Even with approval, use the additional time for controlled migration and validation rather than assuming compatibility.

Can the Codex command-line interface perform the migration?

The assigned OpenAI material does not establish that. The Codex command-line interface (CLIA text-based interface for running commands and tools. Open glossary entry) is a separate developer tool. Its presence does not establish custom-GPT migration access or replacement feature parity in a ChatGPT workspace.

Decision rule: use the migration workflow documented in the retirement FAQ when it is available in the correct account. Treat developer tooling as a separate technical option only where a replacement genuinely requires development and the organisation has approved that work.

Common misconceptions and the official rationale

“Custom GPTs retired on 1 October.”

Correction: 1 October is a narrowly scoped target for a migration banner in Enterprise workspaces that had already opted into delayed banners. OpenAI schedules standard retirement for 11 December. Existing GPTs remain usable until their applicable retirement date, subject to existing permissions.

Editorial rule: describe 1 October as a notice milestone, never as a completed retirement event.

“A target date is a guaranteed rollout.”

Correction: OpenAI expressly says migration access may become available at different times and that a target migration date does not guarantee every account can migrate that day.

Practical consequence: verify the option in the creator’s own account and workspace. Documentation establishes the workflow; only account observation establishes current exposure.

“The 26 October date means all editing ends.”

Correction: the FAQ describes the planned end of creating new custom GPTs and says edits to existing, unmigrated GPTs can continue. The important source-state issue is that the migration workflow uses the latest published version, not drafts or unpublished edits.

Practical consequence: prioritise publishing reviewed drafts that must become migration input; do not manufacture unnecessary new GPTs simply because a cutoff is approaching.

“Migration preserves the GPT exactly.”

Correction: the selected model does not carry over; conversations do not move; custom actions do not transfer automatically; and sharing does not follow automatically. OpenAI also warns that a migrated plugin may respond differently and recommends comparison of familiar prompts and a harder case.

Practical consequence: classify migration as source conversion followed by access and behaviour review, not as guaranteed duplication.

“Connected app approval gives everyone the underlying data.”

Correction: OpenAI’s plugin documentation says a plugin does not itself confer new data access. The connected app must be available, and the user must already have permission in the source system. Enterprise and Education controls add separate role, action, provider and workspace checks.

Practical consequence: validate plugin use and source-system entitlement independently. A failed data request may reflect a legitimate permissions boundary rather than a migration defect.

“If one user can install it, former GPT users are covered.”

Correction: original sharing does not automatically transfer, and one user’s successful installation proves nothing about another user’s role, workspace policy, app authorisation or source permissions.

Practical consequence: sample each materially different user role. Use approved test accounts or authorised participants, not borrowed credentials.

“An approved deferral removes the need to prepare.”

Correction: a deferral changes the applicable date for a qualified, approved Enterprise workspace; it does not establish feature parity, preserve drafts, transfer selected models or grant user access.

Practical consequence: use any confirmed additional time to resolve ownership, publish the intended source, replace unsupported actions and complete human-led acceptance.

“A successful simple prompt proves readiness.”

Correction: OpenAI advises checking familiar prompts and at least one harder case, along with instructions, references, completeness, format and integrations. A single response does not exercise those dimensions.

Practical consequence: choose examples representing normal use, an instruction-sensitive case and an integration-dependent case where relevant. Define acceptable results before testing and retain human sign-off. These are suggested validation examples, not reported product results.

What to put in the final readiness record

A compact record should be sufficient for another responsible person to understand the decision without relying on memory or an undated screenshot. It should include:

• the GPT name, owner, originating account or workspace, and intended audience;
• the latest published version and whether any needed draft was reviewed and published;
• the date and wording of any workspace notice, recorded separately from migration-control availability;
• whether the migration option was observed in the correct creator account;
• dependencies on knowledge files, apps, custom actions, conversation history or a selected model;
• the replacement’s distribution state and the user roles chosen for access checks;
• the applicable scheduled retirement date and the evidence for any qualified, approved deferral;
• the non-sensitive examples used for review, expected qualities and named human approver;
• open issues that block release, including unresolved source-system permissions or unsupported actions.

Worked example of a defensible status: “Published source confirmed; migration control not yet observed in the creator account; custom action requires separate technical review; standard 11 December schedule retained because no approved deferral has been evidenced.” This sample records facts and uncertainty without predicting availability.

Worked example of an indefensible status: “Enterprise migration is live and the replacement will work for everyone.” That statement merges a cohort target, an account control, functional equivalence and user access into one unsupported claim.

For security, privacy, financial, employment, government, health, legal or other consequential workflows, the final record must name the competent human reviewers and their decision. Migration documentation is not a substitute for organisational approval, professional judgement or verification of an action before it affects a person, account or system.

Useful Links

• Custom GPT retirement and migration FAQ
• Plugins in ChatGPT and Codex
• Plugins
• Admin controls, security and compliance for plugins and apps
• Using Codex with your ChatGPT plan
• DevDay 2026 recap