Imagine a business that chose a payment provider in 2018. It worked. Nobody thought about it again.
Since then, without that business making a single decision, the provider was sold to a different company, the product was given a new name, the legal entity on the contract changed, and the brand it was renamed to was itself folded into the parent company's, taking the website, the documentation and the support routes with it.
The service still works. Nothing was switched off. And yet almost everything a person in that business would need to know in order to get help has quietly changed, and nobody has looked at any of it in seven years.
That is the situation most businesses are actually in, and it is worth understanding properly, because the way it is usually described is misleading.
Discontinuation is rarely a switch being turned off
When people picture a supplier discontinuing something, they picture a date and a shutdown. Occasionally that does happen. Far more often the process looks like this:
- The vendor is acquired. Nothing changes for you except an email you skim.
- The product is renamed, or absorbed into the buyer's brand.
- A new, better product appears, which is not the one you are on. Yours is not withdrawn. It simply stops being the one they talk about.
- Documentation, portals and support move. The old links redirect, then eventually they don't.
- Years later, one specific thing you actually depend on, a plugin, an integration method, an older interface, stops being maintained. This one usually does come with a date.
Only the last step feels like an event, and by the time you reach it you are working to somebody else's deadline. The four steps before it are the ones that decide how painful that is, and none of them is dramatic enough to make anyone act.
A worked example most UK businesses will recognise
Sage Pay is the clearest illustration, partly because so many British businesses used it and partly because it demonstrates the drift rather than the shutdown.
Sage agreed to sell its payments business to Elavon in 2019. In 2020 it was rebranded as Opayo. From 2023 the Opayo brand was largely absorbed into Elavon's, with the website redirecting and the branding, correspondence and support channels moving across.
Now the part that matters, and the reason we checked rather than assuming: the gateway was not switched off. At the time of writing there is no announced end of life for it, and Elavon's own guidance describes the change as a rebrand rather than a retirement. Businesses on it are still taking payments.
So a company that did nothing at all has been moved through three ownership and branding changes and is still trading. That sounds like a happy ending, and mostly it is. The cost is subtler: their integration was built against documentation that has since moved, the support relationship is with a company they never signed up to, and nobody currently employed there chose any of it. When something does eventually need attention, all of that gets discovered at once, usually urgently.
What you are actually exposed to
It is worth being specific, because the risk is usually not the one people worry about.
Nobody knows who to ring. The contract is with an entity that has changed name, the account manager left two acquisitions ago, and the support number in your internal wiki rings out. This is the most common real cost and it always arrives at the worst moment.
Your integration was built against something that no longer exists. Not broken, just undocumented. The developer who built it worked from pages that now redirect to a marketing site. Any change becomes archaeology.
The commercial terms drifted. Contracts survive acquisitions, but pricing, tiers and add-ons get restructured around them, and renewals happen automatically. Nobody has benchmarked the rate since before the sale.
And where the system takes money, the failure mode is same-day. A CRM that misbehaves is an irritation you work around for a week. A checkout that stops authorising is revenue not arriving today, and it is why payment systems deserve more attention here than anything else on the list.
How to tell real drift from a real deadline
Most changes need noting and no action. A few need a project. The difference is usually visible if you know what to look at.
Signals that genuinely matter: a specific date given in writing. The vendor steering you towards a different product rather than an upgrade of yours. An announcement that names the exact thing you use, a plugin, an older interface, a particular integration method, rather than the product generally. Support being answered by a company whose name is not on your contract.
Signals that usually do not: a new logo. A renamed customer portal. A website redirect. A new parent company. These generate a lot of internal noise and rarely require anything.
The useful habit is simply to read the emails from the suppliers your business genuinely runs on, rather than filing them. There are usually fewer than ten such suppliers.
Moving without an outage
If you do have to move, the mechanics are well understood and the mistakes are predictable.
Run both. Do not schedule a cutover. Stand the new system up alongside the old one, send a small share of real traffic through it, and watch. For a checkout that might be one payment method or one product line for a fortnight.
Keep the old one until the new one is boring. The temptation is to cancel the old contract the day the new one goes live, which is precisely when you are most likely to need it back. Pay for an overlap. It is the cheapest insurance in the project.
Ask the data question early, because it is the one that traps people. With payments in particular: if customers have saved cards with you, those are held by your current provider in a form that is specific to them. Moving them to another provider is usually possible, but it has to be arranged deliberately between the two companies, and it is not something you can do yourself at the last minute. If nobody asks, the answer arrives as "your customers will all have to enter their card details again", which is a conversion problem nobody budgeted for. The same question applies elsewhere: can you get your data out, in a form the next system can read?
Never move at your busiest time of year. Obvious, routinely ignored.
The same shape, everywhere else
Payments make the sharpest example, but nothing above is specific to them. Accounting packages, CRMs, email platforms, booking systems and stock systems all go through the same cycle, and the questions are identical.
A worthwhile hour, once a year: list the systems the business genuinely runs on. Next to each, write who owns that company today, what your renewal date is, and what would happen if it stopped working on Friday morning. Most businesses have never written that list down, and the act of writing it is usually where the surprises turn up.
What this does not do
- It does not mean changing supplier every time one is acquired. Most acquisitions are fine, and switching has real costs and real risk. The point is to make it a decision rather than a discovery.
- It will not give you notice you were never given. Some retirements are announced with far less warning than is reasonable. Watching for them buys you weeks, not always months.
- It does not remove the work. A migration is a project. Planning it early makes it a project rather than an emergency, which is a much bigger difference than it sounds.
Where to start
Pick the system that would hurt most if it stopped this week, and answer three questions about it. Who owns that company now? When does the contract renew? If we had to move, could we get our data out, and in what form?
If any of those takes more than a few minutes to answer, that is the finding.
We have moved businesses between payment providers more than once, and we write about the ones we work with regularly: SagePay and Opayo, Stripe and PayPal. If you would like a second opinion on a system you have been told is going away, do get in touch.