A vendor outage is annoying. A vendor disappearing is a business event. The difference is not how long the downtime lasts — it is whether you can get your data and your domain back.
Here is the checklist I would run against any tool that holds customer conversations.
1. Can you export everything, in a format you can read?
Not "we support export" — ask for a sample file. Three questions:
- Does it include message bodies or only metadata?
- Does it preserve attachments, or just filenames?
- Does it preserve threading (which message answered which)?
A CSV of ticket titles is not an export. If the demo cannot produce a zip with bodies, attachment files and thread structure, assume you cannot leave.
2. Is your domain yours, independently?
The single most common failure: the domain's nameservers are hosted inside the same infrastructure as the product. When that box dies, DNS dies, so mail bounces and you cannot even re-point the domain to a new host — you have no reachable nameserver to edit.
Check in 30 seconds:
dig +short NS yourdomain.com
for ns in $(dig +short NS yourdomain.com); do echo "$ns -> $(dig +short A $ns)"; done
If all nameservers share one IP, that IP is a single point of failure for your entire company, not just the product.
3. Can you still read your mail if the tool is down?
Support mail usually lands in the tool. If mail delivery depends on the tool's MX records, an outage means customers get bounces — and you find out days later from a customer who gave up.
Keeping MX at an independent provider (or at least a provider you control separately) means mail keeps arriving while the app is broken.
4. What is your break-glass path?
Write it down, once, on one page:
- Where the origin IP is recorded (not only in DNS)
- Who can change nameservers, and where that login lives
- The last known-good export, and its date
- Which channel you use to tell customers something is down
I have watched teams spend the first four hours of an outage looking for credentials. That is not a technical problem; it is a documentation problem.
5. Does the contract survive the vendor?
Ask for:
- A stated export format and how long after cancellation it stays available
- Notice period for shutdown or migration
- Data deletion timeline, and confirmation they will not delete on day one
If none of that is in writing, you are relying on the vendor's goodwill at the exact moment they are least able to provide it.
6. Self-hosting is a spectrum, not a binary
Some teams need the whole stack on their own hardware. Most just need the data to be portable:
| Level | What you run | What you keep |
|---|---|---|
| Cloud | Everything | Export + domain + mail DNS |
| Hybrid | App in cloud, data exports nightly | Database + attachments |
| Self-hosted | App, database and storage | Everything, including DNS |
The middle option is underrated. You keep the convenience and remove the lock-in.
7. Test the restore, not the backup
A backup you have never restored is a hope. Once a quarter: export from the tool, import into a scratch environment, open a two-year-old thread, check one attachment opens.
Ten minutes, and it converts an untested assumption into a fact.
We build Onsites AI as a shared inbox with a Docker Compose deployment: app, database and queue on your own hardware, mail through any provider you like. The self-hosting notes are deliberately boring — they list what to prepare before the first install, including the parts above that decide whether a bad day becomes a lost quarter.
Top comments (0)