Changing Software Supplier Without Stopping Your Business
The relationship with whoever built your software has run its course, but switching feels too risky: the data is over there, nobody knows how it works inside, and meanwhile the company has to keep running. How to make the move, in what order, and what to secure before you announce anything.
It happens to plenty of companies: the relationship with whoever built the software has run its course. Turnaround times have stretched, answers take weeks, or the two paths have simply diverged. Switching, though, feels too risky — and so nothing moves for years.
The fear is legitimate, because the software that keeps you working can't be switched off while you are working. But the handover is an ordinary operation, done in the right order.
Only one rule really matters: prepare first, announce second. Doing it the other way round is the one genuine mistake.
Before saying anything: get the keys
While the relationship is cordial, routine requests get handled the same day. After the announcement, the same requests become slow procedures. So the first step is confirming you hold, in your company's name, four things: the domain, the hosting or space the software runs on, the app store accounts if there is an app, and administrative access.
If something is in the supplier's name, now is the moment to ask for the transfer — as routine housekeeping, announcing nothing. It is also the moment to ask the backup and export questions I covered in Source Code, Domain and Accounts.
Then: understand what you are moving
Before choosing who comes next, you need to know what exists now. Not a technical analysis: an honest list, written by the people who use it.
What the software does today, function by function, including the three things only one person uses and nobody ever remembers.
What it doesn't do and you have missed for years: that is why you are switching, and it should be written down now while you still remember.
What it talks to: invoicing, e-commerce, bank, couriers. Every connection is a piece of work for whoever comes next.
How much data is inside, and since when. Ten years of history doesn't move with the same effort as six months.
The handover: never all at once
The worst approach is switching the old one off and the new one on the same day. The approach that works is keeping both alive for a period, accepting a little duplicated work in exchange for a safety net.
In practice: move a non-critical piece first, leave the old system running read-only, work on the new one for a few weeks with the option of stepping back. Only once the new system has survived a full cycle — a month-end close, a peak season — does the old one get archived.
Archiving doesn't mean deleting: it means keeping a readable copy, even just as an export, for as long as an old document might be needed.
The three mistakes that make it painful
| Mistake | What happens | What to do instead |
|---|---|---|
| Announcing before holding the keys | Every request slows down | Secure everything in advance |
| Rebuilding it identical | You pay twice for the same software | Keep what earns its place, drop the rest |
| Migrating all the history | Costly, and it delays the start | Move live data, archive the old |
A note on the supplier you are leaving
It pays to close well. Not out of politeness, but because in the following months you will almost certainly need one question answered: where did that setting go, why does that field behave like this. A relationship closed civilly is worth those answers.
It cuts both ways too: if you are leaving because the supplier was slow, saying so plainly and without accusations is more useful than disappearing. Occasionally, once they know the reason, they propose something that makes the switch unnecessary.
If you are considering a switch and don't know where to start, tell me what you use and what stopped working: I'll tell you what to secure first, and whether rebuilding or rescuing what exists makes more sense. Often it is the second.
