Four Things to Ask Before You Need to Leave

You can find out whether you could change software supplier without knowing anything technical.

Ask for four things to be demonstrated while you watch: that someone other than your current supplier can deploy a change, that the accounts are in your name, that the credentials can be changed without breaking anything, and that the knowledge is written down. If any of those demonstrations is improvised rather than routine, you have your answer - and you have it while you are still on good terms, which is the cheapest moment to have it.

What is already published, and who wrote it

The framework for this is not ours and it would be dishonest to present it as though it were.

A consulting firm publishes a guide on what they call a zero-trust handover, and it is the best thing we found on the subject. It sets out six points - account ownership, least-privilege access, secrets management, credential rotation, auditability, and documentation - and closes with a test sharper than anything in our own notes: rotate every credential, remove every vendor account, then confirm two things - the system still runs, and the vendor cannot get back in.

It also makes the timing argument we would have made. Exit capability, it says, is a buying decision rather than an IT detail, and it should be settled before anything is built, while you still have room to negotiate. That is correct and it is theirs.

So what is left to add? One thing, and it is about audience rather than ideas.

That guide is written for mid-market buyers - organisations with someone technical in the room. Its test assumes a reader who can rotate credentials and reason about least privilege. Meanwhile the SME-facing material we found on the same question is about SaaS platforms and explicitly leaves custom software out.

Between those two sits a business running bespoke software with no IT function, which is most of the businesses we work with. Everything below is that guide’s argument, translated into things you can ask for and check without technical skill.

Where dependency actually lives

Briefly, because this list is established rather than ours. The published material names the points well: shared administrator logins, credentials held only by the supplier, domains and hosting sitting in the supplier’s own accounts, deployment access nobody else has, and - the one that catches people - architecture and behaviour that exists only in individuals’ heads and was never written down.

That last one is not malice. It is the ordinary consequence of a small team building something quickly for a client who did not ask for documentation.

The version you can run without technical skill

The rotate-and-confirm test is the right test. You just cannot perform it yourself, and you should not try - rotating production credentials without knowing what depends on them is a way to cause the outage you were trying to insure against.

What you can do is commission it and watch. Four demonstrations, requested in a normal email, performed on a call while you observe.

One: someone else deploys. Ask for a trivial change - a label, a colour - to be made and released to the live system by someone who has not worked on it, following only the written instructions. This is the single most revealing request on the list, because it tests documentation, access and deployment at once.

Two: the accounts are yours. Ask to log in to hosting, the domain registrar, and any third-party service, using your own identity rather than a shared login. Not a screenshot - you, logging in, while they watch.

Three: credentials can be changed. Ask what would happen if every password and key were changed tomorrow, and who would need to be involved. You are not asking them to do it. You are listening for whether the answer is a short list or a long pause.

Four: the knowledge is written down. Ask where the deployment instructions, the architecture notes and the known-issues list live, and read one of them. If understanding it requires the author to talk you through it, it is not documentation.

What a good answer and an improvised one sound like

Demonstration	Routine sounds like	Improvised sounds like
Someone else deploys	It happens on the call, from the written steps, in minutes	”We’d need to set that up for you first” - or it is done by the person who built it, from memory
Accounts in your name	You log in yourself; your name is on the account and the invoice	A shared login is emailed to you, or the account is in an individual’s personal name
Credentials can be changed	A short, confident list of what would need updating	Hesitation, or “we’d have to work out what that would break”
Knowledge written down	You read a document and follow it unaided	A call is offered instead of a document, or the document turns out to be a list of headings

You are not assessing the technology. You are watching whether the answer is rehearsed or invented, and that distinction is legible to anyone regardless of background.

Why to do this while everyone is happy

Almost everything written about leaving a supplier is written for people who are already leaving, which is the worst moment to start.

Run this while the relationship is good and three things are true. The supplier has every incentive to look organised, because they want the next piece of work. Nothing you ask reads as a threat, because there is no dispute to read it against. And anything missing gets fixed as ordinary housekeeping rather than as a negotiation, usually at no cost, because it is a morning’s work for someone already on the project.

Run it during a dispute and all three reverse. The same four requests become adversarial, the answers become careful, and the missing pieces acquire a price.

We would go further: this is worth doing annually, in the same spirit as checking your insurance. Nothing about it implies you intend to leave, and a supplier who treats the question as an accusation has told you something useful for free.

The one to fix first

If all four demonstrations are improvised, fixing them at once is a project nobody has time for. Fix them in this order.

Accounts first, because it is the only one that can become genuinely irrecoverable. A domain in a former contractor’s personal registrar account, attached to an email address nobody can access, is the failure mode that ends with lawyers or with a new domain. Everything else can be reconstructed with effort; this one occasionally cannot.

Documentation second, because it is the slowest to fix and the cheapest to fix now. Nobody writes deployment instructions retrospectively with much enthusiasm, and the people who could write them are the people currently busy on your work.

Deployment third. If someone else can follow the documentation, this largely follows from it.

Credential rotation last, not because it is unimportant but because it is the one that most needs technical help, and by the time the first three pass it is usually a much smaller job than it looked.

What we do by default

For our own work the answer is that these four demonstrations should never be a request, because the conditions are set up at the start - accounts in the client’s name, code in a repository they administer, deployment documented well enough that someone else can follow it.

We do this because it costs nothing at the beginning and a great deal to retrofit, and because a client who cannot leave is not a client who stayed. It also means we are describing a standard we have to meet, which is the point of writing it down.

What this audit cannot tell you

Three limitations worth stating.

It cannot tell you whether the software is any good. Every demonstration above could pass on a system that is badly built; portability and quality are separate questions.

It cannot replace the full test. A supplier who passes all four demonstrations may still hold a dependency nobody thought to check - the published rotate-and-confirm test exists precisely because watching is weaker than doing. If you have access to someone technical, use their version rather than ours.

And it cannot fix a contract. If the agreement licenses the software to you rather than assigning it, no amount of account custody changes what you are entitled to. That is a separate question, it needs a solicitor, and it is worth settling before the next piece of work rather than after.

What to do this week

Send one email asking for the four demonstrations, framed as routine - because it is. Something like: we’re tidying up our records and want to check we could keep things running if you were unavailable for a while; could we do a short call and walk through these four?

Then watch. Note which ones were routine and which were improvised. Fix the improvised ones now, while fixing them is free, and put a note in the calendar to do the same next year.

FAQ

Is asking for this insulting to a supplier we like? It should not be, and how it lands is informative. Framed as continuity housekeeping - what happens if you are unavailable - it is an ordinary business question. A supplier who is organised finds it easy; one who bristles has told you something you needed to know.

We already signed and built - is it too late? No, just more expensive than it would have been. Most of the four are recoverable at any point: accounts can be transferred, documentation can be written, access can be granted. What gets harder is the standing to ask, which is why doing it while the relationship is good matters.

Do we need source-code escrow? Possibly, but it answers a narrower question than people think - it covers a supplier failing, not a supplier you simply want to leave. If the four demonstrations above already pass, escrow adds less than it appears to. It is a specialist arrangement and worth advice of its own.

What if our supplier is one person? Then this matters more, not less, and the fourth demonstration - is the knowledge written down - is the one to press hardest. A single freelancer who documents well is more replaceable than an agency that does not.

Notes

• Live result set retrieved 2026-08-24 (en, GB proxy) via requests req_f5973cc54f50 and req_2a5e3b4547f5, both at zero budget. Two pages opened and read in full; a third returned HTTP 404 and was not read. See research/live-result-set.md.
• The framework on this page is not ours. The six-point handover checklist, the rotate-and-confirm test, the named dependency points, and the argument that exit capability is decided at commissioning are all published by another consultancy, credited in the second section. We recommend their version to anyone who has technical help available.
• What this page adds is narrower: an audience intersection - bespoke software, owner-operated business, no IT function, which the pages we opened do not serve - and a version of the test that can be commissioned and watched rather than performed. The four demonstrations are our adaptation of their test, described as we use them.
• The healthy-relationship posture and the annual cadence are our framing. No client outcome, success rate, or story about a supplier disappearing is claimed, and none is invented.
• Escrow, cloud lock-in and SaaS switching all appear in the wider result set and none was opened; nothing here draws on them. Escrow is named in the FAQ only to bound it.
• No AI-assistant answer baseline was collected - the probe was unavailable on 2026-08-24.
• Autocomplete returned no suggestions and no People-Also-Ask questions were returned, so this page makes no claim about what owners search for.