Custom GPT to Plugin Portability Audit: What Transfers, Access Rebuilds, and How to Validate the Replacement

Build the portability inventory before touching the migration control

A custom-GPT-to-plugin migration is not a one-for-one copy. The useful starting point is therefore an inventory of the workflow as it exists now, not a list of hoped-for plugin features. For one hypothetical example, this section audits a custom GPT called Policy Briefing Assistant. It summarises internal policy files, uses a connected document app, applies a fixed briefing format and calls a custom action that retrieves a policy record by identifier. It is shared with editors and occasional reviewers.

The example is a planning template, not a report of a migration performed by this publication. OpenAI’s Custom GPT retirement and migration FAQ documents the intended transfer boundaries: the latest published instructions become a plugin skill; knowledge files are copied into plugin reference files; and connected apps are added as apps. The selected model, existing conversations, sharing settings and custom actions do not transfer automatically. Those statements describe planned product behaviour, not proof that migration is available for a particular account, that this example is eligible or that the resulting plugin will behave identically.

OpenAI schedules standard custom-GPT retirement for 11 December 2026. According to its retirement FAQ, an 11 February 2027 date applies only to affected Enterprise workspaces with a qualified, approved deferral, and Enterprise milestones are subject to change. The FAQ also lists 22 September 2026 as the target for the migration experience and user banner, and 1 October 2026 as the target for workspaces that opted into delayed migration banners. These targets do not guarantee availability in every account or workspace. Before relying on any date or process, the owner should inspect the current workspace notice and confirm that the migration control is actually present.

This timetable concerns retirement of the custom-GPT product object. It is distinct from OpenAI’s separately documented retirement of GPT-5.5 from ChatGPT, ChatGPT Work and Codex on 14 October 2026. A model date must not be treated as the workflow’s retirement date, and the model selected for the original GPT must not be assumed to survive migration.

To make the portability inventory concrete, begin by separating the legacy GPT’s interface elements and integrations by role. The updated plugin menu, MCP connectors and action icons are distinguished in a ChatGPT interface walkthrough, which offers a vocabulary for a Custom GPT connector and action inventory that records what the replacement must account for, without assuming any component transfers automatically.

Use three evidence states rather than a binary “migrates” column

A robust inventory separates what OpenAI documents from what the owner still has to establish. Use these three states:

1. Documented carry-over: OpenAI says the component is converted, copied or added during the planned migration. This confirms the intended treatment of the configuration object, but not behavioural equivalence.
2. Documented non-carry-over: OpenAI says the component does not transfer automatically. The owner must rebuild it, replace it, archive it or accept its loss.
3. Account-specific unknown: the official documentation does not establish the result for this GPT, workspace, user or provider account. The item needs inspection or staged verification.

The distinction matters because “copied” and “works” answer different questions. A knowledge file may be copied as a reference file while retrieval quality, formatting and source use remain unverified. A connected app may be added while the intended user still lacks provider authorisation. Conversely, a non-transferred custom action may have a viable replacement through an existing app or a custom Model Context Protocol (MCP)A protocol for connecting AI applications with tools and data sources through defined interfaces. Open glossary entry server, but the migration itself does not establish that replacement.

Decision rule: label an item “portable” only for the narrow property stated in the documentation. Record behaviour, access and outcome parity separately as unknown until reviewed. Do not upgrade a documented configuration transfer into a claim of functional equivalence.

Define the hypothetical workflow precisely

The sample Policy Briefing Assistant has the following intended journey:

1. An editor supplies a policy record identifier and asks for a briefing.
2. The assistant follows published instructions defining audience, headings, source-handling rules and prohibited speculation.
3. It consults uploaded editorial standards and terminology files.
4. It can use a connected document app to locate permitted supporting material.
5. A custom action submits the record identifier to an internal service and retrieves current record fields.
6. The assistant returns a structured briefing, noting absent information rather than inventing it.
7. Editors can use the GPT; reviewers have narrower needs and may only inspect generated material.

This definition reveals that the workflow is not a single prompt. It combines guidance, static references, live data, an action, model-dependent execution, access controls and user habits. The inventory must preserve those distinctions. Treating the whole object as “the GPT” would conceal several documented losses.

A practical inventory record should identify an accountable owner, the workspace containing the GPT, the latest published version, each dependency, intended users, data sensitivity, evidence source, transfer classification, replacement owner and verification status. Do not put credentials, access tokens, private customer records or other secrets into the inventory’s prompts or sample cases. Use synthetic identifiers and sanitised examples until an authorised test environment and data-handling procedure have been approved.

Baseline inventory for Policy Briefing Assistant

The table is the baseline, not the acceptance result. A row is complete only when it contains evidence specific enough for another maintainer to inspect. “Has files” is inadequate; “Editorial Standard.pdf, revision 8, owned by Editorial Operations, containing mandatory briefing headings” is auditable. “Uses an app” is also inadequate; identify the provider, intended source boundaries, user group and required read or write operation.

1. Capture the latest published instructions, not the editor draft

OpenAI’s FAQ says migration uses the latest published version. Drafts and unpublished edits do not transfer. Publishing is a version-state requirement for migration; it does not mean the GPT has been shared publicly. The owner should therefore distinguish four things that are often conflated: the text visible in the editor, the latest saved draft, the latest published configuration and the audience with whom that published GPT is shared.

For the sample GPT, suppose PBA-17 is the published version while a draft adds a new rule: “When the effective date is absent, write ‘Not supplied’ and do not infer it.” If the owner migrates without publishing the draft, the documented migration basis is PBA-17, not the unpublished change. The audit must not state that the missing-date rule transferred merely because it was visible to the creator in an editor.

Use this procedure:

1. Open the GPT in the owner workspace and identify its current publication state.
2. Copy the latest published instructions into a controlled configuration record. Preserve headings, ordering and explicit decision rules.
3. Compare them line by line with any draft. Mark every draft-only change.
4. Have the workflow owner decide whether each draft change should be published, discarded or retained for a later plugin revision.
5. Assign a local version identifier and review date. This identifier is an audit convention, not an OpenAI product field.
6. For each important instruction, write an observable expected behaviour and at least one case in which the instruction should not apply.

For example, the instruction “Use the executive briefing format for requests asking for a policy summary” should be decomposed into evidence that can later be reviewed: the output contains the required headings; missing fields are identified; and a request merely asking for a document title does not unnecessarily invoke the full briefing workflow. These are suggested checks, not guaranteed product results.

Documented carry-over: the published instructions become a plugin skill. Not documented as equivalent: identical triggering, interpretation, wording or output. OpenAI’s guidance recommends checking direct and indirect triggers, incomplete-input follow-up behaviour, non-trigger cases and edge cases. The inventory should therefore preserve the intention behind each material instruction, not only the prose.

Decision rule: do not proceed while consequential requirements exist only in an unpublished draft, old conversation or maintainer memory. Publish the approved version if appropriate, or record the requirement as a separately governed plugin change. For legal, privacy, security, financial, employment, government or similarly consequential guidance, require review by a qualified human owner rather than treating instruction transfer as approval of the content.

2. Inventory knowledge files by purpose, authority and sensitivity

The FAQ says knowledge files are copied into plugin reference files. A reference file supplies material that a skill can use; it is not the same thing as live app access or an action. File copying does not establish that the plugin will retrieve the same passage, resolve conflicting documents in the same way, reproduce citations or preserve a former response style.

For Policy Briefing Assistant, create one record per file:

Record the owner, revision date, source of authority, file format, intended audience and retention status. Flag duplicates, expired documents and conflicts before migration. Copying two contradictory files faithfully would preserve the conflict, not solve it.

A useful negative case is a question whose answer is absent from every reference file. The expected requirement might be: “State that the reference set does not establish the answer; do not manufacture a policy.” Another is a deliberately outdated term appearing only in an obsolete file. The expected requirement should specify whether the current source overrides it. These are examples of acceptance criteria, not claims about actual plugin performance.

Do not upload untrusted material merely to make the inventory comprehensive. Review files for embedded instructions, personal data, confidential material and unnecessary content before they become reference files. Keep secrets, credentials and private keys out of files and prompts. Where a file affects security, privacy, legal rights, money, employment or government services, a responsible human must confirm both its authority and the replacement’s output before use in a consequential decision.

Decision rule: classify a knowledge file as ready only if it has a named purpose, current owner, authority level and at least one expected-use case plus one absence or conflict case. A copied file with uncertain authority is a migration liability, not an accepted dependency.

3. Separate connected-app presence from usable access

OpenAI documents that connected apps are added to the migrated plugin as apps. That is narrower than saying every user remains connected. Plugin installation does not complete provider-account authorisation, grant provider scopes, alter source-system access or bypass workspace policy. Availability can depend on plan, workspace, role, region, platform and the app’s capabilities.

For the hypothetical document repository, inventory at least:

• the app and provider;
• the business purpose for using it;
• which users need it;
• whether the workflow needs search, read, write or another supported action;
• the permitted source locations;
• the relevant workspace role;
• the provider-account role;
• any action approval requirement;
• the accountable workspace and provider administrators; and
• what the workflow should do when access is absent or a source is outside scope.

For example, an editor may be permitted to search an approved policy library but not a restricted personnel folder. The migrated plugin containing the app does not prove that either source is accessible. A sensible expected negative behaviour is that a request for the restricted folder fails clearly and does not imply that no such material exists. Lack of access and lack of data are different conditions.

OpenAI’s administration guidance separates plugin installation, underlying-app availability, role access, provider authorisation and action controls. Preserve those as separate inventory fields. A single “connected: yes” field hides the most important failure modes.

Decision rule: regard an app as configured only when it appears in the intended plugin; regard it as usable only after an authorised representative of each intended user role can perform the minimum permitted operation. Regard write or external side-effect capability as a separate approval gate. Human review is mandatory before actions affecting security, privacy, money, employment, government records or other consequential matters.

4. Record the selected model as a lost dependency

The original GPT’s selected model does not carry over. OpenAI’s FAQ says Enterprise defaults apply where relevant. Consequently, “uses model X” belongs in the historical baseline but cannot be a migration acceptance requirement phrased as “the plugin must retain model X”. The relevant acceptance question is whether the replacement completes the required tasks under the models and controls actually available in the target workspace.

Do not infer continuity from a model picker, release note or prior conversation. OpenAI’s 6 July 2026 release note describes GPT-5.5 Instant Mini as a ChatGPT fallback after GPT-5.5 Instant or Auto rate limits; it does not appear in the model picker, and that update does not affect the API or Codex. It is not a selectable replacement target for this inventory.

For Policy Briefing Assistant, record: “Original selected model: historical configuration only; non-transferable.” Then attach task requirements such as mandatory headings, no invented dates, correct terminology and explicit failure on missing app access. This shifts validation from an unsupported model-continuity assumption to observable workflow behaviour.

Trade-off: requiring a specific old model may block migration even though the business task could be met through the workspace’s current configuration; ignoring the old model entirely may overlook behaviour changes. Preserve it as context, but make task outcomes and safety constraints the acceptance criteria.

5. Treat conversation history as non-portable operational knowledge

Existing GPT conversations do not move. This matters when users have allowed examples, corrections and workarounds to accumulate in chat history instead of updating the published instructions or reference files. Conversation history is not a substitute for maintained configuration, and the official sources assigned here do not establish a universal export or archive process.

Ask each maintainer to identify, without copying sensitive material into prompts:

• frequently reused requests;
• hard cases that prompted corrections;
• output formats users rely upon;
• known failure patterns;
• clarifying questions that are operationally necessary; and
• rules that exist only in prior conversations.

Convert only authorised and necessary examples into a sanitised review corpus. For instance, replace a real record identifier and personal details with synthetic values while preserving the structural challenge: missing effective date, conflicting category indicators or inaccessible source. Record expected characteristics rather than a single exact paragraph unless exact wording is genuinely required.

Decision rule: if the workflow depends on facts or corrections found only in old chats, migration is not ready. Move approved rules into the published instructions or governed reference material, and retain only the minimum authorised test evidence. Consult the organisation’s privacy, records and legal owners before archiving conversations containing personal, regulated or confidential information.

6. Decompose every custom action before choosing a replacement

Custom actions do not transfer automatically. OpenAI’s skills documentation distinguishes reusable workflow guidance from live data, authentication, authorisation and actions, which require an app or MCP-backed capability. A skill-only plugin must not be described as recreating a former custom action.

For the sample record-retrieval action, inventory the contract without recording secrets:

Trigger

A user requests a briefing and supplies a syntactically valid policy record identifier.

Input

The identifier, plus only the context necessary for the authorised request.

Authorisation

The user and service must be permitted to access the requested record.

Output

Defined record fields, source status and any explicit missing-value indicators.

Failure cases

Malformed identifier, record not found, denied access, service unavailable and incomplete response.

Side effects

None for retrieval; any future update operation would require a separate inventory and approval path.

Then classify the replacement path:

1. Existing supported app: choose this only if its documented operations and access model cover the required capability.
2. App template: treat it as a starting point, not a ready connection or evidence of provider access.
3. Custom MCP server: consider this where live data, authentication or a controlled action needs separate technical implementation.
4. No replacement: remove or redesign the capability if no governed option meets the requirement.

The inventory should not choose among these based on naming similarity. A document-search app is not necessarily a substitute for a record-retrieval action, even if both return text. Compare required inputs, authoritative source, access rules, outputs, errors and side effects.

Decision rule: no custom action is marked portable. Mark it “replacement identified” only when an option covers its required operation and governance model; mark it “accepted” only after authorised verification. If the action can change data, spend money, communicate externally, affect employment, alter government records or create another consequential effect, require an explicit human confirmation step and specialist security, privacy and legal review.

7. Rebuild sharing from named roles, not inherited assumptions

Sharing settings do not carry over, and OpenAI says a migrated personal plugin starts private. Migration therefore does not preserve the old GPT’s audience, make the plugin public or give former users access. Publishing the source GPT for migration also does not mean it was publicly shared.

Create an access matrix before migration:

This matrix prevents a common category error: giving a reviewer broad app access merely because they previously received a link to the GPT. Plugin access, workspace role, provider authorisation and source-system permissions are separate controls.

Trade-off: restoring the old audience quickly may reduce disruption, but bulk re-sharing before access review can reproduce obsolete or excessive permissions. Start private as documented, establish the minimum roles and expand access in stages. Public directory distribution, if required, is a separate packaging, review, approval and publication process; it is not part of automatic migration.

8. Inventory user dependencies that sit outside the GPT

A user may have depended on more than the GPT’s sharing setting. Record workspace membership, role, plan, region, platform, provider account, approved data sources, supported actions and any reliance on old conversation links. OpenAI’s documentation says plugin and app capabilities can vary by plan, workspace, role, region and platform, so one successful owner view would not establish access for all intended users.

For each persona, write a dependency chain. An example for an editor is:

Workspace membership → permission to use the plugin → plugin explicitly shared → underlying app available → provider account authorised → approved policy library accessible → requested read action permitted.

A break at any stage has a different remedy. If the plugin is not shared, the plugin owner acts. If provider authorisation is missing, the user or provider administrator may need to act. If the source folder is prohibited, sharing the plugin more broadly is not a valid fix.

Include a fallback for users whose dependency cannot be restored. For example, a reviewer without authorised app access might receive a human-reviewed briefing through an approved records channel rather than being granted direct source access. This is a design option, not a product guarantee.

Decision rule: do not sign off “user access restored” from the creator’s account. Verify at least one authorised representative for every materially different role and dependency chain, while preserving least privilege.

When deciding which instructions and workflow settings to rebuild, it helps to separate intent from copied configuration. A playbook on moving to ChatGPT Work is a comparison point for preserving Custom GPT workflow configuration, although its destination is not a plugin, so a plugin replacement should document what it recreates rather than assume anything transfers.

Turn the inventory into a controlled migration record

The completed record should contain two adjacent views: the source baseline and the replacement requirement. The source baseline preserves what the published GPT contains. The replacement requirement states what the workflow must still accomplish without assuming that transferred components behave identically.

For example:

Do not put a passing status against a row merely because the migration interface reports completion. Completion can establish that a planned conversion step ran; it does not establish reference quality, app authorisation, action parity, model continuity or user access. Reserve final acceptance for the staged verification covered later in the audit.

Minimum readiness gate

The owner can classify the hypothetical GPT as inventory-ready only when all of the following are true:

• the owner workspace and applicable retirement notice have been checked;
• the intended latest published version is identified and archived;
• draft-only changes have an explicit disposition;
• every knowledge file has a purpose, owner, authority and sensitivity classification;
• every connected app has a user, provider, source and action dependency map;
• the selected model is recorded as non-transferable rather than promised;
• necessary conversation-derived cases have been sanitised and formalised, subject to applicable review;
• every custom action has a documented contract and replacement decision owner;
• sharing roles are named and will be re-established explicitly;
• user dependencies are recorded by persona rather than inferred from the creator’s access; and
• security, privacy, legal, financial, employment, government and other consequential uses have named human reviewers.

If any required item is unknown, the workflow is not ready for an evidence-based migration decision. The appropriate response is remediation, not an assumption that the plugin will fill the gap. If the migration control is absent, treat availability as unresolved and consult the current account or workspace notice; the published target dates alone are not evidence that the feature is enabled.

The central portability finding for Policy Briefing Assistant is therefore deliberately narrow. Its latest published instructions, knowledge files and connected apps have documented migration destinations: a skill, reference files and apps respectively. Its model selection, conversations, sharing settings and custom action do not automatically transfer. Whether the replacement is usable remains an account-specific and workflow-specific question requiring later verification. That distinction keeps the audit grounded in OpenAI’s documented product behaviour without presenting planned migration as tested equivalence.

Run acceptance as a staged replacement review

This acceptance plan is a reproducible procedure, not a report of an executed migration. It deliberately leaves the “Expected” and “Observed” fields empty so that the owner records account-specific evidence rather than inheriting assumed results. OpenAI’s Custom GPT retirement and migration FAQ, reviewed on 1 October 2026, recommends testing familiar prompts and at least one harder case, including skill selection, instruction following, reference use, output completeness, formatting, tools and integrations. The same FAQ warns that a migrated plugin may respond differently.

The plan therefore tests capability, access and governance separately. A good answer to a familiar prompt does not prove that a reference file was used correctly. Successful installation does not prove that an intended user can authorise an app. A visible app does not establish permission to read a particular source or perform a write action. The decision rule is that every required layer must pass independently; evidence from one layer cannot compensate for a failure in another.

Freeze the candidate before collecting evidence

Start with a named release candidate rather than testing a moving configuration. Record the plugin owner, workspace, plugin version or internal revision identifier, migrated skill, reference-file set, included apps, any replacement for a former custom action, intended users and test date. Record the applicable original GPT version as well. The FAQ says migration uses the latest published version, while drafts and unpublished edits do not transfer, so an editor draft is not a valid baseline unless it is first reconciled with the published configuration.

1. Copy the approved test cases into a version-controlled or otherwise change-tracked acceptance record.
2. Assign each case an identifier, owner, risk class, required preconditions and evidence type.
3. Freeze changes to instructions, files, apps and action configuration for the duration of one test round.
4. Record defects without altering the candidate midway through the round.
5. After remediation, create a new candidate revision and rerun all affected cases plus the core regression set.

For example, “RC-02” might identify the second candidate for an internal policy-briefing plugin. Its evidence bundle could list a migrated briefing skill, three approved policy reference files, one connected document app and no action-capable integration. This is an example record structure, not a claim about a real plugin or its behaviour.

The freeze rule matters because conversational outputs can vary and product availability can depend on plan, workspace, role, region, settings and rollout. Do not quietly adjust a skill after a failed case and then retain earlier passes as if they applied to the amended candidate. Any change that could affect triggering, instructions, source use, permissions, actions or formatting creates a new testable revision.

Define acceptance states before running a prompt

Use four outcome states: pass, fail, blocked and not applicable. “Pass” means the recorded acceptance criterion was met with reviewable evidence. “Fail” means the candidate ran but breached a criterion. “Blocked” means the test could not be completed because a prerequisite such as migration availability, installation rights, provider authorisation or source access was absent. “Not applicable” is valid only when the owner has documented why the capability is outside the approved replacement scope.

Do not count a blocked case as a pass, and do not average outcomes into a portability score. A single failed high-consequence control can be more important than numerous successful low-risk prompts. The owner should classify each requirement as one of the following:

• Mandatory: the workflow cannot be released without it.
• Conditional: it must pass when a named feature, app or user group is enabled.
• Advisory: useful behaviour that may be deferred without misrepresenting the supported workflow.
• Prohibited: behaviour that the replacement must refuse, avoid or route to a human.

The release rule is: all mandatory positive cases pass; all prohibited-behaviour cases demonstrate the required refusal or escalation; no unresolved high-consequence defect remains; and every blocked mandatory case prevents release. Advisory failures may be accepted only through a dated exception naming the impact, compensating procedure, owner and expiry date.

Before accepting a plugin replacement, define whether its data handling, access model and auditability meet the retiring workflow’s operating requirements. A ChatGPT Work security article offers a governance lens through its enterprise deployment access-control checks, alongside data governance and audit compliance, which can inform your acceptance criteria.

Build a prompt corpus from real duties, not demonstrations

Create a compact corpus that represents the work users actually need. Preserve prompts independently of old GPT conversations because the FAQ says existing conversations do not move. Remove secrets, personal data and confidential source text unless the approved test environment and data-handling review expressly permit their use. Prefer synthetic or redacted fixtures for security, privacy, employment, financial, government and other consequential workflows.

Divide the corpus into six groups:

1. Familiar tasks: routine requests that exercised the original GPT’s central instructions.
2. Harder cases: longer, ambiguous, conflicting or incomplete requests that expose instruction and reasoning boundaries.
3. Reference-dependent tasks: requests that can be answered correctly only by using an approved file or source.
4. Format-bound tasks: outputs requiring a specified structure, fields, order or omission rule.
5. Tool and integration tasks: cases requiring an included app, provider access or an authorised action.
6. Negative cases: requests that should not trigger the skill, should request clarification, should refuse an unsupported action or should avoid inventing missing information.

A representative set is more useful than many near-duplicates. For the example policy-briefing workflow, familiar cases could cover summarising an approved document and producing a briefing outline. Harder cases could combine two documents with conflicting dates, omit the target audience, or ask for a conclusion unsupported by the source. Negative cases could ask the plugin to amend a government record even though no approved write-capable tool exists. These are proposed test designs, not observed product outputs.

Use a blank evidence sheet for every case

The following template keeps procedure, acceptance criteria and recorded evidence distinct. The two comparison fields remain empty here by design. A tester should populate them only while executing the approved plan.

Establish the familiar-task regression set

Select several routine tasks that collectively cover the skill’s essential instructions. Do not choose only the shortest or most polished prompts. Include the wording used by ordinary users, reasonable paraphrases and at least one indirect request that should still invoke the workflow. OpenAI’s skill-building documentation recommends testing direct and indirect triggers as well as non-trigger cases.

For each familiar task:

1. State the business purpose and the minimum useful deliverable.
2. Mark the instruction clauses that the case exercises.
3. Provide a redacted input fixture and any approved reference material.
4. Define content requirements separately from stylistic preferences.
5. List disallowed assumptions, claims or actions.
6. Run the case in a fresh conversation to avoid hidden dependence on earlier context.
7. Have a reviewer assess each criterion rather than rating the answer by general impression.

Example: a briefing workflow receives a public policy document and a request for a one-page internal summary. Mandatory criteria might require the document’s stated purpose, effective date, affected group, unresolved questions and a clear separation between source statements and analyst interpretation. Tone and sentence length may be advisory. If an effective date is mandatory, an attractive summary that omits it fails.

Use an approved tolerance where exact wording is unnecessary. Acceptance should focus on required meaning, traceability and format, not textual identity with an old response. Because the selected model does not carry over, matching the original GPT word for word is neither a documented migration promise nor a sound acceptance rule.

Make harder cases expose operational ambiguity

A harder case should test a meaningful boundary, not merely add length. Construct cases involving missing fields, inconsistent sources, ambiguous dates, multiple possible workflows, requests outside scope or instructions that conflict with user wording. The criterion should specify whether the plugin must clarify, choose an approved default, present alternatives or stop.

For example, provide two approved reference documents with different publication dates and ask for “the current rule” without identifying jurisdiction. The acceptable procedure is not to pre-write the answer. Instead, require the candidate to identify the ambiguity, avoid silently merging incompatible sources and request the missing jurisdiction or apply a documented source-precedence rule. Human reviewers must verify the source comparison; the plugin must not be the final authority for legal or government decisions.

Run harder cases after the familiar set but before release to intended users. If a remediation changes the core skill, rerun the familiar cases because a clarification rule can alter routine behaviour. The decision rule is that a hard-case fix is unacceptable if it resolves one ambiguity by weakening a mandatory familiar-task instruction.

Verify reference use and source quality independently

Knowledge files are documented as copying into plugin reference files, but that does not establish identical retrieval, interpretation, formatting or citation behaviour. Test the copied file set as a source system rather than assuming file presence proves usable knowledge.

Create at least four reference checks:

1. Positive retrieval: the relevant fact exists clearly in one approved file.
2. Source conflict: two files differ and the workflow must apply a documented precedence rule or disclose the conflict.
3. Absent answer: none of the files supports the requested claim.
4. Scope boundary: a similarly named but unapproved or unavailable source would be needed to answer.

For each file, record title, version, date, owner, authority, sensitivity and the passages used to adjudicate the case. Where citations or source labels are required, define the exact minimum: for example, document title and section heading. Do not require a page number if the file format does not support stable pagination. Conversely, do not accept a generic “according to the documents” statement when users need to distinguish authoritative policy from commentary.

Source quality must be reviewed by a person competent to judge the material. For legal, financial, employment, security, privacy, medical, government or similarly consequential work, outputs are drafts or research aids only. A qualified human must verify current authority, applicability and consequences before any decision or action.

The failure rule is strict: if the answer cannot be supported by the approved source set, the candidate should disclose the gap, ask for an authorised source or stop according to the workflow. Fluent invention is a failure even when the invented statement appears plausible.

Test format as a contract, not an aesthetic preference

Output acceptance should distinguish structural validity, required content and optional presentation. Write a checklist that another reviewer can apply without guessing. Suitable checks include required headings, field presence, ordering, maximum scope, date convention, separation of evidence and interpretation, and omission of prohibited data.

For a sample briefing format, mandatory fields might be “Issue”, “Source position”, “Operational impact”, “Open questions” and “Human review required”. The test should use a fixed fixture and check every field. It should also include an empty-data case: if there is no supported operational impact, the plugin should use an approved “not established from supplied sources” notation rather than manufacture content merely to fill the field.

A formatting defect is mandatory or advisory according to downstream use. A missing heading may be advisory for a human-readable note but mandatory if another approved process relies on that heading. Do not infer machine compatibility from visual resemblance. Where a downstream system consumes the output, validate it separately through that system’s authorised procedure; this article does not assert compatibility with any external parser or schema.

Exercise missing tools and broken prerequisites deliberately

A positive integration test alone cannot show safe failure. OpenAI’s plugin documentation separates installation from account authorisation and notes that use can depend on plan, workspace, role, region, capability and platform. Test each prerequisite independently where the organisation can do so safely.

• Plugin installed, underlying app unavailable.
• App available, provider account not authorised.
• Provider authorised, requested source outside the user’s provider permissions.
• Read access available, write action unavailable.
• Action available but approval not granted.
• Feature available to the owner but not to an intended member role.
• Required capability unavailable on an intended platform.

For each state, ask for the dependent task and inspect both the response and the relevant authorised system record. The candidate must not claim that it read data or completed an action when the prerequisite was absent. A clear limitation message passes only if it accurately reflects the tested state and directs the user to an approved next step.

Do not place passwords, access tokens, private keys, authentication cookies or other secrets in prompts or screenshots. Use the provider’s supported authorisation path and redact identifiers from evidence. If troubleshooting requires sensitive logs, follow the organisation’s approved incident and data-handling process rather than copying them into a conversation.

Prove that unsupported actions remain unsupported

Custom actions do not transfer automatically. A skill can describe a workflow, but OpenAI’s skill documentation assigns live data, authorisation and controlled actions to an app or MCP server. If no approved execution surface replaces a former action, acceptance must test an honest refusal or manual hand-off, not pretend that prose recreates execution.

Build negative cases around the original action inventory. For example, if the old GPT submitted a record to an internal service but the candidate contains only a skill and reference files, ask it to submit a sample record. The acceptance criterion should require it not to claim submission, not to invent a confirmation identifier and not to solicit credentials in the prompt. It may prepare a draft payload or explain the approved manual procedure only if that behaviour is explicitly within scope.

If an app or custom MCP server does provide a replacement action, test dry-run, approval, cancellation, denied permission, malformed input and duplicate-request handling where those behaviours are supported and safe to test. Do not perform consequential writes against production merely to prove connectivity. Use an approved test tenant, sandbox or non-destructive fixture where available; if none exists, require a human-controlled validation method and document the residual risk.

Negative cases should confirm that a replacement denies or constrains actions the original workflow should not perform, while retaining evidence for review. An enterprise administration update on proving access and preserving audit evidence offers context for documenting Model Test access evidence controls alongside policy audit logs and group administration around the replacement.

Check direct triggers, indirect triggers and non-triggers

A migrated instruction set becoming a skill does not prove that the skill will activate in the same circumstances as the original GPT. Prepare three adjacent cases with similar vocabulary:

1. A direct request naming the supported workflow.
2. An indirect request describing the same goal without its formal name.
3. An out-of-scope request sharing keywords but requiring a different workflow.

For example, “Create an internal policy briefing from this approved document” is a direct trigger. “Help the operations team understand what changes next month” may be an indirect trigger if the supplied material and context make the intended workflow clear. “Rewrite this marketing announcement in a friendlier tone” may contain policy-related terms but should not invoke the briefing workflow. Define these classifications before execution.

False activation and missed activation carry different costs. If activation could expose data or enable an action, prefer clarification over aggressive triggering. If the skill is read-only and low consequence, an organisation may tolerate a broader trigger provided the output accurately states its scope. Record this trade-off as an explicit owner decision rather than adjusting the criterion after seeing results.

Test intended-user installation from a clean state

The migrated personal plugin starts private because sharing settings do not carry over. Keep it private during owner testing. Publishing the source GPT for migration is not the same as public sharing, and migration does not automatically restore access for former users.

After owner acceptance, select representative intended users by role, workspace status, provider entitlement and platform. Do not use the owner account as a proxy for everyone. Each participant should begin from a documented clean state and follow the organisation’s approved installation route.

Installation acceptance is not complete until the user runs one familiar task, one reference-dependent task and one applicable integration case. If platform differences matter, repeat this subset on every supported platform used by the target group. Do not advertise unsupported platforms merely because the owner’s platform works.

Require separate approval for consequential actions

Any test involving money, account changes, employment decisions, security controls, personal data, legal status, healthcare, government services or other consequential effects requires a named human reviewer and an approved non-production method wherever possible. The plugin must not be the sole decision-maker or final approver.

The test record should distinguish recommendation, draft, approval request and completed action. For example, producing a draft access-change request is not the same as changing access. The acceptance criterion should state which stage is permitted. If the approved workflow stops at a draft, any claim that the account was changed is a failure.

Where an action requires confirmation, test cancellation and denial as well as approval. Saved approval settings, where available, must not be treated as overriding provider restrictions, workspace policy or safety protections. A human reviewer should inspect the intended target, scope and consequence immediately before authorising a consequential write.

Use owner sign-off as an evidence decision

The accountable owner should not sign merely because testers report that the replacement “looks fine”. The sign-off packet should contain the frozen candidate identifier, scope, required cases, completed evidence, defects, blocked cases, exceptions, access matrix, privacy and security review status, intended-user results, rollback plan and retirement deadline relevant to the workspace notice.

Assign at least these responsibilities:

• Workflow owner: confirms that mandatory business functions and exclusions are accurate.
• Technical maintainer: confirms the candidate revision, included surfaces and defect remediation.
• Data or source owner: confirms reference authority, permitted use and retention requirements.
• Workspace administrator: confirms the intended sharing, roles and applicable workspace controls.
• Risk reviewer: reviews privacy, security, legal or other consequential implications where relevant.
• Release owner: makes the proceed, remediate, defer or retire decision.

One person may hold more than one role in a small organisation, but the record should still show which judgement that person made. For high-consequence workflows, use independent review where organisational policy requires it.

Preview privately and retain a practical rollback path

Keep the candidate private by default through configuration review, owner tests and limited intended-user preview. Expand sharing only after the previous stage passes. Public distribution, if needed, is a separate governance and publication decision; migration itself does not make the plugin public or restore the former GPT’s audience.

A preview group should be small enough to contain defects but representative enough to expose role and authorisation differences. Give participants the supported scope, known limitations, feedback route and instruction not to use the preview for consequential production decisions. Monitor defect reports by case identifier rather than relying on informal impressions.

Define rollback before preview. The FAQ says the original GPT remains usable until its applicable retirement date, but after migration it becomes read-only, cannot be deleted by its creator and later becomes inaccessible at retirement. Consequently, rollback is not an indefinite promise to reverse the migration. Before migration, preserve the published configuration, redacted test corpus, reference-file inventory, action specifications, user list and operational hand-off. During the remaining overlap period, rollback may mean withdrawing plugin sharing and temporarily directing authorised users to the still-available original GPT. After retirement, rollback must instead mean reverting to an approved manual process, another validated system or suspension of the workflow.

The release owner should choose one of four decisions:

1. Proceed: all mandatory and negative gates pass, required reviews are complete and rollback is viable.
2. Remediate: keep private, correct specified defects and run a new frozen candidate through affected tests.
3. Defer: delay release where an applicable, approved organisational timetable permits it; a target date or requested exception is not itself evidence of an approved deferral.
4. Retire the workflow: do not release a replacement when mandatory capability, access, source quality or risk controls cannot be established.

The final decision rule is conservative: uncertainty about a mandatory capability is a block, not an assumed pass. A polished answer cannot offset missing source authority, absent action controls or unintended access. Conversely, a documented difference from the old GPT is not automatically a failure if the replacement’s approved requirements are met and users are clearly told what changed.

Close the review without erasing unresolved evidence

After sign-off, retain the acceptance record according to the organisation’s approved retention policy. Preserve failed and blocked cases alongside passes; removing them would hide the basis for exceptions and future regression tests. Record the release revision, sharing scope, support owner, known limitations and the next review trigger.

Review triggers should include a skill change, replacement or addition of a reference file, app or MCP configuration change, provider-permission change, expansion to a new user role or platform, altered output contract, material workspace-policy change, or an updated OpenAI notice affecting the migration or retirement timetable. Because availability and controls can change, check the current account or workspace notice immediately before migration and release rather than relying solely on information reviewed on 1 October 2026.

For routine maintenance, rerun the smallest set that fully covers the changed component plus the familiar-task core and relevant negative cases. For example, replacing a policy reference file requires source-positive, source-conflict and absent-answer checks, as well as familiar outputs that depend on that file. Altering an action surface requires permission, denial, approval, cancellation and no-false-success cases. Changing sharing requires intended-user and unshared-user checks.

Acceptance ends only when the owner can state, with attached evidence, what the replacement supports, what it deliberately does not support, who can use it, which sources and actions require separate access, and what happens if it fails. That is a narrower claim than behavioural identity with the custom GPT, but it is the defensible basis for a controlled replacement.