The email is usually polite and apologetic. The founder is retiring, or the business is winding down, or it has been sold and your product is not part of the plan. Support will end on a date that feels uncomfortably close.
If your operations depend on that software, this is a serious moment. It is also a manageable one, provided you treat the remaining weeks as an asset and use them deliberately.
The handover window is the most valuable thing you have
When a software developer has gone out of business, or is about to, the code is only part of what you stand to lose. The bigger loss is context: why things were built the way they were, which parts are fragile, what runs on a schedule in the background, and which workarounds keep everything ticking over.
While the outgoing supplier is still around, that knowledge is available. Once they have gone, it largely is not. So the question is not "who will support us after the closing date?" It is "how do we get everything out of the next few weeks that we will need later?"
That reframe matters because it changes what you do first. Choosing a new supplier can wait a little. Capturing access and knowledge cannot.
What to secure before the closing date
Work through this list with the outgoing supplier as early as you can. Most closing suppliers want to leave clients in good shape, so ask clearly and in writing.
Source code and history. Get the full code repository transferred to an account your business owns, including its history, not just a zip file of the latest version.
Ownership of the code. Check your contract for who owns the intellectual property. If it is unclear, ask for a written assignment to your company before they close. Take legal advice on the wording.
Hosting and cloud accounts. Find out where the system runs and whose account it is. If it sits in the supplier's own account, agree a plan to move it into yours.
Domains, certificates and DNS. Confirm who controls each domain and SSL certificate, and transfer anything registered in the supplier's name.
Credentials and secrets. Get a documented list of admin logins, database access, API keys and third-party accounts, then rotate them once the transfer is complete.
Third-party licences. Identify any paid components or services that are licensed to the supplier rather than to you. These can quietly stop working after the supplier closes.
Backups. Make sure recent backups exist in a location you control, and ask for a test restore.
Knowledge transfer. Book recorded walkthroughs with the people who know the system best. Ask about deployments, scheduled jobs, known bugs, unfinished work and anything they would worry about if they were in your position.
If time is short, put source code, hosting access and domains first. Those three are the hardest to recover later.
Look hard at unfinished work
Closing suppliers often leave something half done: an upgrade started but not finished, a migration planned but not begun. These are easy to overlook in the rush, and they can be the most expensive part of what you inherit.
A partially upgraded system can be harder to maintain than one that was never touched. Ask the supplier for an honest account of where any in-flight work stands, what remains and what they would do next.
A real example
We recently worked with a manufacturer in the south east of England whose long-standing software supplier announced it was closing, with only a short window for handover. Rather than rush straight into a long contract, we ran a short paid discovery first.
That covered a system audit, a knowledge transfer plan to make the most of the supplier's remaining time, and a handover risk assessment so the client could see what mattered most. The system also had a half-finished AngularJS upgrade, so we produced a migration roadmap to turn that into a planned piece of legacy software modernisation rather than an open-ended problem. With that groundwork done, we took the system on under a 12-month care arrangement.
The order is the useful part. Understand first, then commit.
Choosing who takes it on
When you speak to potential new suppliers, a few questions will tell you a lot:
Do they regularly take over software projects they did not build, or do they mostly want to rebuild?
Will they assess the system before quoting for ongoing support?
Who exactly will work on your system, and what happens if that person is away?
Will you own everything, including code, accounts and documentation, if you later move on?
How do they handle work that goes beyond what was agreed?
A supplier who proposes a full rewrite before they have looked at the code is telling you something about their priorities. Sometimes modernisation is the right answer, but it should follow from evidence, not be the starting assumption.
How Scaffold can help
Taking on systems that others built is a specialism for us, and we are used to working within tight handover windows. Our fixed-price Health Check reviews your code, hosting, security and risks and tells you what level of care the system needs; you keep the report whether or not you continue with us. From there, Scaffold Care gives you a named team, one fixed monthly price with anything extra agreed before the work is done, and full ownership of your code, accounts and documentation.
Book a Health Check while your current supplier is still around to help.
