OpenAI shipped GPT-5.6 on July 9. Anthropic shipped Claude Opus 5 fifteen days later. If you run enterprise AI, your engineering team is currently in some version of the same conversation: should we migrate? The trap most teams fall into is treating that as a technical question. It isn’t. It’s a contract question, and the frequency of model launches means you’re about to have this conversation every quarter, not every year. Here’s the framework I use to answer it.
On July 9, OpenAI shipped GPT-5.6, a family of models including Sol, Terra, and Luna.
Fifteen days later, on July 24, Anthropic shipped Claude Opus 5, positioned as “near-flagship intelligence at half the cost” of previous flagship tiers.
If your team runs enterprise AI in any meaningful way, some version of the same conversation is happening at your company right now: should we migrate? Your engineers are excited about the new capabilities. Your product manager wants the benchmarks. Someone on your team is probably running a proof-of-concept on one of them this week to see what it can do.
That is the wrong first question.
The right first question is not “is the new model better?” It’s “is the new model a contract-safe drop-in for the model our customers signed off on?”
I wrote a piece a few weeks ago called “The model changed. The contract didn’t” about our Opus 4.8 upgrade. The core argument: in regulated-industry AI, the model is one variable in your production stack. Everything else, the evals, the policy layer, the audit trail, the customer contract, should be stable when the model changes.
That argument is about to get tested twice in the span of fifteen days by two different frontier labs. And if the frequency I’m seeing continues, the “should we migrate” conversation is going to happen every quarter for the rest of 2026 and probably 2027.
Here’s the framework I use to answer it.
“Is the new model better?” is a research question. “Is the new model a contract-safe drop-in?” is a migration question. Answering the wrong one is what turns a routine model swap into a war room.
Four questions to ask before you migrate
Question 1: Does the new model pass every eval in our current customer contract?
Not “does it pass our internal evals.” Not “does it pass most of them.” Does it pass every eval the customer signed off on when they contracted us.
If the answer is “we haven’t run them yet,” you are not ready to migrate. Not to Opus 5. Not to GPT-5.6. Not to anything.
If the answer is “it passes most but not all,” you are also not ready. In regulated industries, “most” is not a pass. It is a specific delta that needs to be raised with the customer before the model swap happens.
If the answer is “it passes all of them, and the pass margins are wider than the previous model,” you are one green light closer.
Question 2: Does the new model’s behavior drift trigger a customer notification obligation?
Every enterprise AI contract I’ve written or reviewed in the last 18 months has some form of change-notification clause. Sometimes it’s explicit. Sometimes it’s buried in the compliance appendix. Sometimes it’s only implicit, but the customer’s compliance officer will invoke it the first time they notice a difference.
Before you migrate, someone on your team needs to have read the contract, identified the notification obligations, and produced a specific written answer to “does this migration trigger any of them.” If the answer is yes, you are running a notification-and-approval process, not a technical migration. Those are different projects.
Question 3: Do we have a rollback plan if we discover drift after ship?
If Opus 5 or GPT-5.6 exhibits a behavior in production that your evals didn’t catch, what happens? Do you roll back in four hours or four weeks?
The answer depends on architecture decisions you made months ago. Model version pinned in configuration? Rollback is minutes. Model version referenced in fifteen places across the codebase? Rollback is a project. If you don’t know which category you’re in, the migration is not safe.
Question 4: Who owns the response if a customer catches drift before you do?
The eval-incident disclosures Anthropic and OpenAI both published these past two weeks made this question urgent for enterprise operators. The answer needs to be a named human, not “the on-call team.” That human needs to have the authority to pause the agent, the context to understand the incident, and the customer’s compliance officer already in their phone.
If you can’t name that person, on both sides, the migration doesn’t happen yet.
What today’s Claudeforce announcement changes about this framework
A few hours before I sent this, Salesforce and Anthropic announced Claudeforce, an expanded strategic partnership branded as “The #1 AI Meets the #1 AI CRM.” The launch product, Salesforce in Claude, is a plugin with 37 prebuilt sales skills that runs Claude inside Salesforce workflows. Underneath it is AIforce, Salesforce’s “trusted enterprise harness” that brings Claude to Salesforce data. September beta. Both companies are now strategic customers of each other.
Claudeforce doesn’t overturn the four questions above. But for any team running enterprise AI on top of Salesforce infrastructure, it adds a fifth conditional one:
Question 5: If we’re deployed on Salesforce, does our model migration now need to coordinate with Salesforce’s AIforce harness?
This is a new class of governance question that didn’t exist yesterday. When a foundational SaaS vendor introduces its own AI trust layer, any downstream vendor running on top of it inherits an additional set of policy dependencies. Your policy layer and AIforce may agree, disagree, or overlap on specific decisions. Model migrations that change any of that, even subtly, become coordination events, not internal engineering events.
The four questions above still hold. The fifth is a filter: if you run any part of your AI stack inside Salesforce, add the AIforce-coordination question to your pre-migration checklist by Friday. And keep watching, when Microsoft, ServiceNow, and Workday inevitably follow with their own trust harnesses, the same question multiplies.
Model launches are becoming quarterly events. If your migration playbook is annual, you’re about to run it four times in a row without ever finishing it.
The bigger pattern
Two frontier model launches in fifteen days. That’s not going to be unusual for the rest of this year or next. Somewhere between four and eight frontier model launches per year is the new baseline.
Which means the migration question is now a quarterly operational question, not an annual strategic one.
If your team runs the migration decision the way you ran it in 2023, big meeting, technical benchmarks, executive alignment, launch date on a calendar, you don’t have a process. You have an event. And the frequency of frontier model launches has already made that event structurally impossible to keep up with.
The teams that will win the next 24 months of enterprise AI are the ones who turn the migration decision into a repeatable operational process with the four questions above at its core. Every model launch runs through the same four checks. Every eval suite is ready to fire same-day. Every customer is notified on the same template. Every rollback plan is tested quarterly whether or not you use it.
That’s what turns a war room into a Monday morning meeting.
The Builder’s Takeaways
1. Turn migration into a repeatable process, not an event. Same four questions. Same eval-rerun playbook. Same customer notification template. Same rollback protocol. Every model launch. If your migration playbook is a one-off document each time, you’re about to run it 6–8 times in the next 12 months and the fatigue will start showing by Q3.
2. Pin your model version in configuration, not in code. The single most valuable architectural decision for the age of quarterly model launches: your model version should live in one place, configurable at deploy time, rollback-able in under 30 minutes. If it’s referenced in fifteen places across your codebase, migration is a project every time. If it lives in a config, migration is a two-line change.
3. Notify your customer before the migration, not after. The number of enterprise AI relationships I’ve seen quietly deteriorate because a vendor changed the underlying model without telling the customer is not small. Your contract almost certainly has a notification clause. Your customer almost certainly will notice the behavior difference. Notifying them before the migration turns a compliance risk into a partnership signal.
Final statement
GPT-5.6 shipped July 9.
Opus 5 shipped July 24.
By September, there will be another one. By December, probably two more.
The teams that treat every migration as a technical decision will spend the rest of the year in war rooms. The teams that treat migration as a contract decision, run through the same four checks each time, will treat every new model launch as a Monday morning meeting.
The model is going to keep changing.
The contract still shouldn’t.