Replace a retiring AI model without losing control

A planned-retirement decision and copyable migration process for Australian professional-services firms

A dated retirement notice gives a firm time to prepare, but it does not migrate its work. A replacement may produce readable drafts while omitting a required qualification, changing the output format or disrupting a review step.

The useful outcome is not “everyone switched models”. It is a recorded decision for each affected workflow: what changes, what passes testing, who approves the switch and how the next deliverable will be produced if testing fails.

This guide covers planned, dated retirement. For the broader operating model, see AI workforce orchestration for professional services. Unexpected outages belong in a separate incident procedure; firm-wide AI policy needs its own owner.

Start here

• Read the notice: identify the affected product, effective date and any conflicting source records.
• Test the work: compare representative outputs and controls against requirements agreed before testing.
• Record the decision: accept, restrict or hold the replacement, with a workable route for the next deadline.

1. Establish what is retiring—and where

A model name alone is not enough. A notice about a model in ChatGPT does not establish that an API integration using a similarly named model is affected.

Two historical OpenAI announcements illustrate the distinction.

Historical source	What it establishes	What it does not establish
29 January 2026 retirement announcement	GPT-4o, GPT-4.1, GPT-4.1 mini and o4-mini were scheduled to leave ChatGPT on 13 February 2026. The notice said there were no API changes at that time.	Current model availability, completion of a firm’s migration or retirement of a similarly named API model.
ChatGPT Release Notes, 28 May and 26 June 2026 entries	The May notice scheduled GPT-4.5 retirement in ChatGPT for 26 June 2026 and o3 for 26 August 2026, with the API unchanged. The later 26 June entry confirmed GPT-4.5 was no longer available in ChatGPT, including custom GPTs.	Successful migration of a firm’s prompts, permissions, connections or deliverables. The June confirmation does not independently verify completion of o3’s retirement.
Model Release Notes, 28 May 2026 entry	The corresponding notice gave 27 June 2026 for GPT-4.5, while agreeing on the o3 date and the ChatGPT-only/API-unaffected boundary.	Agreement between the two May notices: their GPT-4.5 dates differ by one day.

For GPT-4.5’s historical removal from ChatGPT, the later 26 June confirmation supports using that date while retaining the conflicting 27 June notice in the record. It does not provide a general rule for resolving future vendor contradictions.

Source boundary: these examples follow the source check dated 9 October 2026. They are historical product-notice evidence, not a live model catalogue or a recommendation of a currently available successor.

For a new notice, save the primary link and record:

• announcement date, stated effective date and any revision;
• named product surface—such as ChatGPT or an API;
• affected plans, accounts or other eligibility conditions stated by the vendor;
• date checked, unresolved contradictions and who will resolve them.

If a material date or scope question remains unresolved, assign an owner to obtain clarification and set a conservative internal readiness deadline. Do not present that planning deadline as the vendor’s confirmed retirement date.

2. Trace the affected workflow

Consider a hypothetical Australian professional-services firm. Each week, an operations employee uses ChatGPT to prepare client-draft material. Saved instructions and an output template guide the draft; a professional checks it against approved sources before release.

The firm also has a separate API integration for internal document summaries. A ChatGPT-only notice does not establish that this integration is affected. Its owner should check the actual API model identifier and relevant provider notices separately.

For each potentially affected workflow, record:

Dependency	What to capture
Product and account	Surface, account or workspace reference, relevant users and access observed
Model selection	Selector or configured identifier actually observed, with check date
Configuration	Prompts, saved instructions, custom GPT settings, approved tools and connections
Information	Approved sources, permitted inputs and client or matter boundaries
Deliverable	Required format, citations, qualifications and next due date
Review	Named reviewer, source visibility, approval step and retained evidence
Ownership	Migration owner, implementer and authorised decision-maker

Use account references rather than passwords or credentials in the worksheet. Keep configuration and test records in an appropriately controlled location.

Classify each dependency as confirmed affected, possibly affected or not affected on current evidence, and attach the supporting observation. Unknown visibility is a check to assign, not a reason to mark the whole firm affected—or unaffected.

3. Agree acceptance before testing a successor

A vendor-selected default is a product transition, not the firm’s acceptance decision. Confirm that the proposed option is accessible on the relevant surface and account, then agree what it must do for this workflow.

Separate mandatory controls from performance tolerances.

Mandatory controls might include preserving material facts and qualifications, maintaining information boundaries, retaining professional approval and giving reviewers enough source context to check the output.

Performance tolerances might cover correction effort, turnaround time and operating cost. Set these for the actual task; a fast, fluent sample is not proof of suitability.

Write the stop conditions before running tests. Examples include:

• information sent to an unapproved destination;
• a missing or bypassed mandatory review step;
• required users unable to access the configured workflow;
• a material error that the normal review process cannot reliably detect;
• an unresolved question about authority to use the information.

A favourable average score must not cancel out a failed mandatory control. Where confidentiality, privilege, contractual terms or professional obligations require specialist assessment, hold the affected use pending that assessment. This guide does not determine those obligations for a firm.

4. Run a repeatable test

Use synthetic material or material explicitly approved for this test. Do not introduce client documents into a new account or model simply to speed up migration.

Copyable test procedure

1. Select representative cases. Cover routine work and the failure patterns that matter to the workflow.
2. Write the expected result first. Identify facts, qualifications, format and control behaviours the reviewer must see.
3. Record the setup. Capture the surface, observed model selection, configuration version, tools, date and authorised input location.
4. Run the proposed workflow. Where the existing workflow remains available and authorised, run the same cases through it for comparison. Its output is a baseline—not the source of truth.
5. Review against approved sources and criteria. Record omissions, unsupported additions, corrections, control failures and elapsed time. Include reviewer effort and cost where relevant.
6. Retest changes. After revising prompts or configuration, rerun failed cases and enough previously passing cases to check that the fix has not caused another problem.
7. Submit the evidence for a decision. Do not treat a developer’s successful demonstration as the owner’s approval.

If the retiring model is already unavailable, record that limitation. Use approved source material, templates and suitably authorised historical examples where available; do not invent a baseline.

Starter test set

Adapt this set to the workflow. It is not a universal sample size or a guarantee of reliability.

Test case	Expected behaviour
Routine draft with complete sources	Preserves material facts, follows the template and includes required citations or qualifications
Missing material information	Identifies the gap rather than inventing a fact or completing an unsupported conclusion
Conflicting sources	Preserves the conflict and routes the affected decision to the designated owner
Request outside scope or information permissions	Stops or escalates according to the firm’s rules; does not widen access to complete the task
Draft requiring professional approval	Reaches the required reviewer with usable source context and cannot bypass the agreed release step
Replacement unavailable or output rejected during rehearsal	Work is stopped and handed to the named alternative-process owner

For variable outputs, agree an appropriate repeat-testing approach before acceptance. One successful response does not establish consistent performance.

Copy one record per test:

Test ID and purpose:
Authorised input/source location:
Expected facts, qualifications, format and control behaviour:
Surface/account reference and observed model selection:
Configuration version and run date:
Observed result and output location:
Corrections, omissions or control failures:
Elapsed time, reviewer effort and relevant cost:
Pass/fail against each criterion:
Reviewer and date:
Retest required / evidence location:

5. Choose an outcome—not just a model

Decision	When to use it	What to record
Accept	The defined workflow meets its agreed criteria and controls	Approved scope, evidence, approver and cutover date
Restrict	A clearly bounded subset passes, and excluded work can be kept out	Allowed tasks and users, enforceable exclusions and a route for excluded work
Hold	A mandatory criterion fails or material evidence remains unresolved	Failed criterion, owner, next review date and handling of due work
Use approved manual handling	The firm can continue without the proposed model-assisted step	Delivery owner, available capacity, required review and deadline implications

Restriction is not permission to overlook a failed control. If the passing subset cannot be separated reliably, hold the affected workflow.

Hypothetical example: the firm’s proposed ChatGPT replacement produces readable drafts but omits a required qualification in two synthetic conflicting-source tests. The reviewer records the failures. The owner holds model-assisted drafting and assigns the next draft to an approved manual process with professional review. The implementer revises the configuration and retests before the next decision date.

This is an illustration, not evidence of a real deployment or an available successor.

6. Cut over with a route for due work

Work backwards from both the confirmed retirement date and the next affected deliverable. Leave time for testing, corrections, staff instructions and a failed first attempt. Record the timezone where a deadline depends on it; do not invent an effective hour if the notice gives only a date.

Before the switch

• [ ] The affected workflow and approved scope are recorded.
• [ ] Test evidence meets the agreed criteria; unresolved limitations are explicit.
• [ ] The authorised owner has recorded the decision.
• [ ] The implementer has a dated configuration-change plan.
• [ ] Staff know what to select, what not to use and where to report differences.
• [ ] In-progress drafts have an assigned route and reviewer.
• [ ] An approved alternative has an owner, capacity assessment and deadline plan.

At the switch

• [ ] Record the actual account, selector or identifier observed, configuration changed, implementer and time.
• [ ] Run a bounded verification check with authorised material, including the review hand-off.
• [ ] If a stop condition occurs, stop the affected model-assisted work and invoke the recorded alternative.
• [ ] Check an early production output under the required human-review process before client release.

After the switch

• [ ] Review access problems, corrections, omissions and reviewer effort for a defined period.
• [ ] Compare observations with the agreed tolerances.
• [ ] Record whether to continue, restrict or hold, with a next review date.

Recovery is not a promise to return to a retired model. That option may no longer exist. The plan must identify an approved alternative workflow or manual process that can handle the work.

If that alternative cannot meet a deadline, escalate the capacity and client-impact decision to the authorised person before the deadline is missed. Do not quietly reduce review or use an unapproved model to keep the timetable.

Unexpected live failures should follow the firm’s separate incident procedure.

Copyable migration decision record

Workflow and migration owner:
Notice link(s), source-check date and unresolved contradictions:
Product surface and affected eligibility:
Announcement / effective / revised dates:
Dependency classification and supporting observation:
Account reference, observed selector/identifier and configuration:
Next affected deliverable and internal readiness deadline:

Proposed successor and observed access:
Mandatory acceptance criteria:
Performance tolerances and stop conditions:
Test plan, reviewer and evidence location:
Failures, limitations and retest results:

Decision: accept / restrict / hold / approved manual handling
Approved scope and exclusions:
Authorised decision-maker and date:
Cutover implementer, date/time/timezone and verification record:
Staff instructions and in-progress work handling:

Alternative process and trigger:
Alternative owner, capacity and deadline implications:
Monitoring period, review owner and next decision date:

Decision rule: switch only when the affected dependency is understood, the successor is accessible on the right surface, representative authorised tests meet the agreed criteria, human approval remains intact and a feasible alternative is assigned. Otherwise, record the gap and hold or use approved manual handling.

For the wider responsibilities around people, information and approvals, return to AI workforce orchestration for professional services.