Our Software Vendor Disappeared: What Should We Do?

What problem does this solve?

A vendor rarely announces that it is gone. Tickets stop being answered, the account manager's number goes to voicemail, an invoice bounces back, or a small development shop quietly closes when its founder takes a job elsewhere. Meanwhile the software keeps running: it books warehouse movements, issues permits, prints invoices, holds customer records or feeds a regulator's report. Nothing appears broken, which is exactly why organisations lose weeks before treating the situation seriously. The clock that matters is not the support contract - it is the next certificate renewal, the next expired credit card on a cloud account, or the next password rotation nobody can perform.

The real exposure is almost never the code. It is custody. In hundreds of small and mid-sized deployments the pattern repeats: the domain is registered in the vendor's registrar account, DNS is hosted there too, the cloud tenant sits under the vendor's billing agreement, the mobile app is published from the vendor's Apple and Google developer accounts, the source repository is a private project in the vendor's organisation, third-party licences and API keys were bought in the vendor's name, and the only administrator on the production database is a person you cannot reach. Each of those is a single point of failure that no amount of paying the invoice can undo once the account holder stops responding.

The second exposure is knowledge. Undocumented scheduled jobs, hard-coded configuration, a build process that only ran on one laptop, integrations whose credentials were exchanged by email years ago. And the third is legal ambiguity: many contracts describe a service but never assign intellectual property, name an escrow agent or define an exit plan, so ownership has to be argued rather than exercised. Under pressure, organisations then make the two most expensive choices available - an immediate rewrite from scratch, or paying whatever is asked to whoever claims to hold the keys - before establishing what they already control.

How the solution works

Handle it as an incident with two parallel tracks. The custody track answers a single question - who is the owner of record for every account, asset and dataset the system depends on - and then moves each one into your organisation's name, with your billing, your administrators and your recovery contacts. The knowledge track answers a different question - how does this thing actually work - and rebuilds a runbook from what is observable: running processes, configuration files, database schema, network calls, logs and the application itself. Neither track waits for the vendor, and neither waits for a lawyer. Legal action remains available afterwards and is stronger when you already hold the evidence and the backups.

Only after those two tracks produce a picture should the strategic decision be made: take the existing system over and keep it, complete it, replace it with a packaged product, or retire it. Deciding first and investigating later is what turns a recoverable situation into a rewrite. When Swedish Technology can help: we run the access recovery and the technical audit as one engagement, take custody of code and data, and can operate and maintain the system afterwards through our outsourcing teams - or hand everything to your own staff with documentation in English and Arabic.

1. 1
   Declare (trigger) Treat the silence as an incident: name one accountable owner inside your organisation, freeze all non-essential changes and releases, and stop any credential rotation until you know what depends on it. Record the last confirmed contact with the vendor and any written notice received.
2. 2
   Inventory (capture) Build the access and asset register: domains, DNS zones, TLS certificates, cloud and hosting tenants, servers and containers, source repositories, CI pipelines, app-store developer accounts, databases, object storage, backups, third-party licences, API keys, payment gateways, SMS and email-sending accounts. For each one record the account holder, billing card, admin users, renewal date and recovery email or phone.
3. 3
   Assess (processing) Score every item on two axes - can we still administer it today, and what breaks if it lapses. That produces a short list of genuine emergencies (usually certificates, domain renewals, a card on a cloud account, a single admin identity) separate from the larger backlog.
4. 4
   Recover custody (integration) Work through the emergencies using each provider's documented ownership or transfer process: registrar transfer or account recovery, cloud account and billing transfer, repository transfer, app transfer on the app stores, licence reassignment. Where an account cannot be recovered, build a parallel one and plan a controlled migration onto it.
5. 5
   Preserve and stabilise (action) Take a complete, restorable copy of everything - database dumps, uploaded files, configuration, source code, build artefacts - into storage you own, then prove the restore works. Add basic monitoring and alerting so the next failure is discovered by you and not by a customer. Apply only the security fixes needed to close obvious exposure.
6. 6
   Document and decide (reporting) Produce a runbook (how to deploy, restore, rotate secrets and contact each provider), a risk register and a written recommendation with effort ranges for take-over, completion, replacement or retirement. This is the document your board or procurement committee needs.

Reference architecture

It helps to think of the system as six layers of custody rather than as software. A vendor exit only hurts where a layer is still held by someone else.

Deployment options: Recovery work runs wherever the system already lives - a UAE-region cloud, your own datacentre, or an air-gapped network. Independent backups are always placed in storage owned and paid for by your organisation, not by any supplier, including us.

Key capabilities

Integrations

The systems below are the ones where custody is usually contested. Direction here means which way control and data have to move during recovery.

Industry use cases

Implementation approach

1. 1
   Hour 0 - incident declaration Name an internal owner, freeze releases and configuration changes, and open a single log of actions and evidence (emails, tickets, invoices, last contact).
2. 2
   Day 1 - access and asset register Interview staff, read invoices and card statements, check WHOIS and DNS, list every login anyone has, and mark each asset as controlled, uncertain or lost.
3. 3
   Day 1-2 - emergency list Identify what expires or fails within 30 days and fix those first: renewals, certificates, payment methods, single-admin accounts, expiring API keys.
4. 4
   Day 2-3 - preserve Take full database, file and configuration copies into storage you own; verify a restore in an isolated environment; capture running configuration and scheduled jobs before anything is changed.
5. 5
   Week 1-2 - custody transfer Execute provider-specific ownership transfers, create your own accounts where transfer is impossible, rotate secrets in a planned order and revoke vendor identities once dependencies are known.
6. 6
   Week 2-4 - technical audit Assess code quality, dependencies and end-of-life components, security exposure, data model and integrations; produce the runbook and risk register.
7. 7
   Week 3-5 - decision and plan Written options with effort ranges: take over and maintain, complete the missing scope, replace with a packaged product, or retire. Include a rollback position for each.
8. 8
   Ongoing - operate or hand over Either an interim support arrangement while the decision is executed, or knowledge transfer sessions and documentation hand-over to your own team.

Security & deployment

A vendor exit is a security event as much as an availability one. Former staff of the vendor may still hold administrator accounts, VPN profiles, API keys and copies of production data, and their monitoring may be the only thing watching your logs. The safe order is: inventory identities first, then remove or disable them in a controlled sequence with a rollback path, then rotate shared secrets, then re-issue signing and encryption keys, and only then close down old accounts. Rotate in the wrong order and you lock yourself out of a system nobody knows how to rebuild. Align the target state with recognised guidance - NIST Cybersecurity Framework 2.0 for governance and recovery functions, ISO/IEC 27001 for supplier and access controls - and keep an evidence trail of every change for audit.

Limitations & prerequisites

• If the vendor is the registered account holder and cannot be reached, some providers will only act on identity evidence, a court order or a documented dispute process - recovery timelines then depend on them, not on us.
• Source code that was never escrowed, committed or deployed in readable form may not be recoverable; what can be reconstructed from deployed artefacts, configuration and the database is always less than the original project.
• Data export quality is limited by how the vendor modelled the data. Poorly normalised or partially undocumented schemas require interpretation, and some derived data cannot be reproduced.
• We are engineers, not a law firm. We prepare technical evidence and act on your instructions; ownership of intellectual property and contractual remedies are legal questions for your counsel.
• Rotating credentials and removing vendor accounts can break undocumented automation; some short outages during stabilisation are realistic and should be planned rather than promised away.
• Mobile app transfers depend on each store's eligibility rules and on the vendor's cooperation; where transfer is blocked, a re-publish means a new listing and losing installed-base continuity.
• An assessment can tell you what a system is worth keeping; it cannot make an obsolete or unlicensed product supportable if its underlying platform is already out of support.

Four realistic options after a vendor disappears

Compare on continuity risk and total effort, not on which option feels most decisive. Most organisations take over first and decide the long-term path afterwards.

The options are sequential, not exclusive: stabilise and take over now, then run the replacement decision as a normal project with a working system behind you.

FAQ

Related topics & solutions

• Emergency Software Vendor Takeover: How It Works
• Unfinished Software Project Rescue
• Failed ERP Implementation Rescue (Odoo, SAP, Oracle)
• Outsourcing Services
• SAIF ÔÇô Cybersecurity
• Document Management & Correspondence System
• Oracle E-Business Suite
• Contact Us