What changes for you
A service your product depends on has written to say that the version you use will be switched off. It may take your customers’ payments, book their deliveries or supply the data a screen is built on. The date is fixed by someone else, and the notice has been sitting in an inbox while the roadmap carries on.
Notices like this are easy to put off. Nothing is broken yet, the work is invisible to customers when it goes well, and nobody on the team wants to give up a feature for it. The pressure only grows as the date comes closer, and the date does not move.
Your product is moved to the replacement the provider offers. The old connection is taken out and the new one is put in its place. The aim is that your users see only the change you chose to tell them about, such as a new step the provider now asks for.
For you, the change is that a date set by someone else stops hanging over the roadmap. Your team can keep its attention on the features it planned, and the retirement notice becomes a piece of work you can see and follow.
Every change lands in your own code repository, where your engineers can read it, and the code we write for you belongs to you.
What you decide
You decide what the replacement should look like from your users’ side. A provider’s new version sometimes changes what a customer sees, such as a different confirmation step at checkout or a new field on a delivery form. Whether to match the old experience as closely as possible or to take the chance to improve it is your call.
You decide what your users are told. Some changes are worth a short note to customers; others need none. You know which of your customers will care, and how they prefer to hear about it.
You decide what happens to the parts of the old connection that nobody uses any more. They can go with the move, or be left for a later piece of work.
You decide whether this is also the moment to look at the provider itself. A retirement notice is sometimes the prompt to ask whether you still want that service at all. We would rather hear that question early than discover it late.
You decide what ships. Nothing reaches your users without your approval.
What you see along the way
You see the move take shape in your repository, as small changes your team can read and approve. A choice that is yours, such as whether to keep or change a screen the provider’s new version affects, reaches you with the question and a link.
You see the old connection leave your code as well as the new one arrive, so your engineers know what remains and what has gone.
What it costs you in time
A first conversation about the notice you have received, the date in it and what the service does for your product today. After that, some time from whoever holds the account with the provider. They may need to switch something on, request new access or answer a question only the account holder can. It also helps to hear from whoever answers your customers, since they know which parts of the connection people would miss first.
What if you want to stop
The changes you approved before stopping stay in your repository. If the move is only partly done, your team can see which parts already use the replacement and which still use the old version, because every change was one you read and approved. Your code and your product stay yours to take anywhere.
Starting small
We have not moved a customer’s product off a retiring integration yet, and we will not suggest otherwise. A sensible first piece is one connection: the one named in the notice you have now. Every engagement is tailored to your product and your goals. It starts with a conversation, with no obligation.
