"What if you disappear?" It is a good question. Ask it of everyone.

Article 6 of Field Notes, a series on what we learned selling an offline SAP access-risk tool.

Every small vendor gets this question, and most of us answer it badly. The bad answer is a story about commitment and determination, which nobody buys, because the founder of every failed company said the same thing sincerely.

I want to make a different argument. The question is a good one. What is wrong is that it gets asked of exactly one category of vendor, and it gets asked in a form that assumes the answer is obvious for everyone else.

Software mostly disappears while the vendor is doing fine

Bankruptcy is the rare case. The common case is a healthy company deciding that a product is no longer worth carrying, and it happens on a scale nobody in a procurement process seems to price in.

In this market right now, organisations are migrating off a commercial SoD product because it is being wound down. Not because the vendor failed. Because a viable company made a portfolio decision. Anyone who has worked in enterprise software for a decade has lived through the same thing in half a dozen categories:

The product is sunset and customers are directed to a successor with different capabilities, a different data model and a new licence.
The vendor is acquired, and the roadmap for whichever product overlaps with the acquirer's quietly stops. Support continues, development does not.
The product moves to a new platform or a new generation, and the migration becomes your project, on their timeline, in their release window.
Support for the version you actually run ends while you are mid-programme, so an upgrade you did not plan becomes mandatory.
The on-premise edition is retired in favour of the hosted one, which is a different architecture, a different security review, and often a different answer to the question in article one.
Renewal arrives with a large increase and no realistic exit, because the process around it was built on their platform.

None of these require the vendor to cease existing. Every one produces the outcome the buyer was worried about, which is that the thing they depend on stops being available on terms they control. Several of them are more likely at a large vendor than at a small one, because portfolio rationalisation is something only a portfolio can do to you.

I have never once been asked, in a competitive evaluation, what my product roadmap commitment is compared to the incumbent's sunset history. The size of the vendor is treated as answering the question. It does not answer it. It changes which failure mode applies.

Availability is not a solved problem either

The implicit comparison is against a hosted service with an uptime commitment. Those commitments are real and mostly honoured, and they are also smaller than people assume.

A 99.9% availability target permits roughly nine hours of unavailability a year, and that is before planned maintenance windows, which are typically excluded from the calculation entirely. The relevant question is not the annual percentage. It is whether the unavailable window can land on the Thursday before your quarter-end sign-off, and the answer is that it can.

Then there is the breach case. A hosted access-risk platform holds authorization data for many organisations, which makes it a considerably more attractive target than any single customer's environment. If that platform is compromised, your map of who can do what in your ERP is part of someone else's incident. You will find out when they tell you, you will manage a disclosure you did not cause, and you will have no ability to act until they act.

I am not claiming this makes hosted platforms a bad choice. They are the right choice for continuous monitoring and for workflow, as I said in article two, and their operational maturity is generally higher than a small vendor's. I am claiming that "large vendor" and "no continuity risk" are different statements, and the evaluation process usually treats them as the same one.

What is actually different about a local tool

Break the worry into four risks, because they have different answers and bundling them is what produces bad conversations.

Operational continuity. For a hosted service, vendor problems become your problems immediately and synchronously. Their outage is your outage. For software running on your own hardware, the two are decoupled. Whatever happens to us on a given Tuesday, the analysis you scheduled still runs.

Data access. This is the one where the asymmetry is largest and it is worth being blunt. If a hosted vendor ceases operating, your access to your historical analysis, your ruleset customisations, your mitigation records, and your audit evidence depends on a data return clause that almost nobody has tested. If we cease operating, none of that applies, because your outputs are files on your own storage in open formats and were never anywhere else. Your signed analysis logs remain verifiable with standard tooling and no vendor involvement, which means an auditor in 2031 can validate a 2026 analysis whether or not MTC exists.

Licensing. This is the one that decides whether the other three matter, because software that will not start is not continuity. By default the product checks entitlement against a licence service, carrying no business data, with a grace period if the service is unreachable. A grace period suits a bad hotel network. It does not suit a vendor that no longer exists. So the product also supports a fully offline licence with no server dependency, which air-gapped environments require anyway and which removes the dependency rather than shortening it. More on our position on this below.

Maintenance and support. Here the small vendor genuinely is more exposed, and I will not dress it up. If we stop, updates stop. That matters concretely for an SoD tool, because SAP keeps releasing transactions, Fiori apps, and authorization objects, and a ruleset that is not maintained drifts out of alignment with the systems it is analysing. Within a couple of years the analysis would be measurably less accurate.

Three of the four favour the local architecture, structurally rather than rhetorically. One does not. That is the honest ledger, and it is a much better ledger than the question assumes.

What we commit to, in plain terms

I would rather state this as a position than leave a buyer to infer it from an architecture diagram.

If MTC stops trading, the version you were licensed for keeps working on your hardware, permanently, and nothing we do or fail to do can switch it off. That is the commitment. The mechanics behind it are:

No kill switch, by design. There is no server-side flag that disables an installed copy, and the offline entitlement file has no dependency on us being reachable or being alive.
Perpetual right to the delivered version. The licence terms give you the right to keep running the version delivered during your paid term, so an expiry cannot be used as leverage and a wind-down cannot strand you mid-year.
Your data was never ours to return. Extracts, analyses, rulesets and reports are files on your storage in open formats. There is no data return clause to invoke, because there is nothing on our side to return.
Evidence that outlives us. Signed analysis logs verify with standard tooling and no vendor involvement, so an auditor in 2031 can validate a 2026 analysis whether or not this company exists.

A subscription buys you maintenance, support and everything we ship next, as described in article two. What it does not do is rent you the right to keep using what you already paid for. Those are different things and a lot of software pricing deliberately blurs them.

Ask for it in the agreement rather than trusting that the capability exists. If a vendor tells you the software keeps running and cannot put that in a contract clause, the claim is worth what it costs them, which is nothing.

The maintenance risk is the real one, so treat it seriously

Everything above keeps the tool running. None of it keeps the ruleset current, and that is the gap. The mitigations are contractual and technical, and a buyer can verify all of them:

Source code escrow with defined release conditions.
Published, open output formats so historical results stay readable by other tools.
A documented, editable ruleset the customer can maintain themselves if they have to.

That last one is the most underrated. If the rule logic is transparent and the customer can modify it, the maintenance risk becomes bounded rather than absolute, because an in-house team or another consultancy can keep it current. A ruleset you cannot see is a dependency regardless of how large the vendor is.

Ask every vendor in your evaluation the same question, in the same words, and require the same specificity in the answer.

Not "will you still exist in five years", because everyone says yes and the answer carries no information. Ask: if you stop supporting this product, what precisely do I still have, and what do I have to do about it?

Then compare the answers. For some vendors it is a migration programme to a successor product. For others it is a data return clause and a ninety day window. For a tool running on your own hardware with your own signing key, it is a shorter answer.

A buyer who chooses you after that conversation is a much more durable customer than one who was talked past a concern. And a buyer who chooses someone else after that conversation has at least made the decision with the real information, which is more than the usual process produces.

This concludes the series. The earlier articles covered data residency, why we built a desktop tool rather than a service, the difference between compliance-driven and efficiency-driven buyers, why organisations that already own SAP GRC keep evaluating additional tooling, and what happens when procurement asks an offline product for a SOC 2 report.