When your tool is withdrawn

It will happen

Products in this field are launched, acquired, merged and closed at a pace that has surprised even the people running them. Models are retired on published schedules. Features are removed. Companies pivot. Over a working life with these tools, something you rely on will be withdrawn, probably more than once.

This is not a reason to avoid them. It is a reason to know what the notice looks like and what to do in the first hour.

Reading a deprecation notice properly

Four things, and they are usually all in the notice:

The shutdown date. The hard one, after which it stops working.

The recommended successor. Take this as a suggestion, not an instruction. The successor is chosen for the provider’s convenience and is better on their benchmarks; whether it is better on your work is your question.

What happens to your data. Whether it is migrated, exported for you, or deleted. Sometimes there is a separate, shorter deadline for downloading it, and missing that one is the expensive mistake.

Whether pricing changes. Successors are frequently priced differently, occasionally much more.

The first hour

1. Export everything. Before anything else, because the data deadline is often earlier than the shutdown and never later.
2. Put both dates in the calendar, with a reminder a fortnight before each.
3. Run your twelve prompts on the successor. You will know within an hour whether this is a migration or a search.
4. Check the price in your own currency at your own volume.

Only then decide whether to follow the recommendation or to treat this as the moment to reconsider.

Migrating a prompt to a different model

When you do move, expect your prompts to need work, and expect the cause to be the same each time: the old model inferred something the new one does not.

A prompt that has been tuned over months accumulates implicit expectations: a length you never specified because it always did that, a format it fell into, an assumption about your domain. The new model has different defaults and the prompt no longer carries enough.

The fix is to make the implicit explicit. Take three outputs you liked from the old tool, and write down what they had in common that your prompt does not say. Add those as instructions. This resolves most migration regressions and takes about twenty minutes.

The notice you did not receive

Not every withdrawal comes with an announcement to you. Deprecation notices go to the account email of whoever created the key or the subscription, which in a small team is often somebody who has moved on, and consumer products sometimes retire a feature with a line in a changelog nobody reads.

Two cheap protections. Make sure the billing and account email is one that several people read, or at least one you still check. And put a five-minute item in the six-month review to open the changelog and the model list for anything you depend on, which catches the notice you were never sent.

When the successor is worse

Sometimes it is, for your particular work. Then you have three options, and it is worth knowing all three exist:

• A different provider. Your prompt file tells you within an hour who else can do it.
• An open model, hosted or local, which cannot be deprecated because you hold the file.
• Doing it differently. Occasionally the honest answer is that the workflow depended on something specific that has gone, and the task goes back to being done another way.

Migrating the rest of the setup

Beyond prompts, four things need moving and each takes minutes rather than hours if you know they exist: the reference documents you had uploaded, the connectors and permissions you had granted, any scheduled or automated jobs pointing at the old endpoint, and the API keys, which should be revoked at the old provider rather than left active on a dormant account.

That last one is the step people skip. A forgotten key on an abandoned account is a live credential nobody is watching, and revoking it as part of the migration costs twenty seconds while noticing it two years later costs considerably more.

The lesson underneath

Anything you build on a hosted product is built on something somebody else can withdraw. That is a normal condition of using services and not a reason for alarm, but it should shape how much you build.

A saved prompt in your own file survives anything. A workflow assembled from one company’s projects, memory, connectors and integrations does not. When you find yourself deep in the second, it is worth asking what the first hour would look like if the notice arrived tomorrow, and whether the answer is acceptable.