It is an uncomfortable question to ask a supplier. It is also a very good one, and we would rather answer it early than be asked it during a bad month.
Companies close. People retire. Relationships end. Suppliers get acquired. Sometimes a customer simply decides somebody else is a better fit. A well-built system should survive all of that.
Your code should be yours
Custom software developed for a customer should not be held hostage by access to the developer.
The source belongs in a repository you can reach. Dependencies and build instructions should be recorded. Credentials should not exist only in somebody's password manager.
If the relationship ends, another competent team should be able to obtain the source and start understanding it — without negotiating a rescue operation first.
Your data matters more than the application
Software can usually be rebuilt. Historical business data frequently cannot.
You should know where your data is stored, how it is backed up, and how it can be exported in a form something else can read. A proprietary export that only the original supplier's software understands is not much of an exit plan.
Standard stacks reduce the hostage problem
Using common operating systems, databases, languages and protocols is not only an engineering preference. It expands the number of people capable of taking over.
A well-known relational database on Linux is boring in exactly the right way, and so is a documented application behind a standard web server. There are thousands of competent engineers who can pick those up, and that is what gives you options.
Infrastructure should be transferable too
Documentation has to cover more than source code. Another operator needs to know how the application is deployed, what it depends on, how DNS is configured, where the certificates come from, what the backup schedule is and how monitoring works.
Infrastructure as code helps. A pile of it that nobody understands is not documentation, it is a second system to reverse-engineer.
Exit plans improve the current relationship
Designing for departure sounds pessimistic. In practice it produces healthier systems while everybody is still happily working together.
Repositories stay organised. Credentials get handled properly. Deployments become repeatable. Documentation exists. Proprietary shortcuts become harder to justify.
We would obviously prefer customers to stay because the relationship works. We would not want anybody to stay because leaving had been made impossible.