Traditionally, when we were dealing with small software vendors, we had their source code in escrow in case they may close down. Now, with SaaS solution, it's different. We're paying not only for a software but for a service as well. After some research on the web, I found out a few things related to Escrow as a Service kind of provider. Has anyone ever thought of using such a service to insure business continuity in case of a vendor (might be startups or fintechs) going out of business?

4.3k views5 Comments

Sort By:

Oldest

Director of IT in Healthcare and Biotecha year ago

Business Continuity is going to be very difficult if a SaaS provider closes its doors and turns off its applications. For some important apps from smaller companies, we've been able to insert contractual clauses regarding our ability to download data for 30-45 days after any business closing, knock-on-wood but we haven't needed to test that in bankruptcy court yet. However we're not expecting the application to be running any longer after we get the data back, nor do we expect to be able to obtain the application or any escrow company do to the same. Ideally we'd get advance notice of SaaS closure and we'd find a replacement to migrate the data. The best worst case is that the application is down for a bit as we download the data and find someplace to put it. And of course the worst-worst case is that we don't get the data back.

But I've seen a few industry cases where the bankruptcy judge has allowed customers a small window to download data, and made the SaaS company provide services for just a little bit longer.

Due to the architecture, experience, and mix of many client data, I don't think the escrow company concept will work well for SaaS applications.

Retired - Former Executive Advisor, CEO / CIO in Manufacturinga year ago

A big problem here is that even if your contract includes downloading data and escrowed software, how long will it be before you will gain access to it after the company closes the doors? I suggest with SaaS we need to approach this using Business Continuity and Disaster Recovery plans based on delays likely to be encountered.

Head of Product and Engineering in Finance (non-banking)8 months ago

As others have pointed out, business continuity will be difficult with SaaS products. Most if not all good products are designed with product stickiness in mind and customer data is big part of the strategy. Best recommendation is to probably look for leading prominent SaaS vendors as these vendors will be in business for long.

Please join or sign in to view more content.

By joining the Peer Community, you'll get:

Peer Discussions and Polls
One-Minute Insights
Connect with like-minded individuals

Director of Operations7 months ago

An option you can try is to obtain ownership of the IP (for internal purposes only) if the SaaS company stops doing business and the IP is not acquired by a 3rd party taking over contract obligations. This may buy you time to look for a solid alternative.

VP of Technology7 months ago

I have given this topic a lot of thought.

There is often a fine line between innovation and enormous risk. A start-up with a new, bleeding edge technology, may offer a solution with extraordinary benefit, but you have no way of knowing if that new company can weather the storm of continued operation, competition or general existence.

Also, among start-ups and established companies alike, there is the acquisition/buy-out problem. Many companies will buy smaller companies, simply for their customer base and then shut down the Products/Solutions the smaller company offered. Business/Product/Solution acquisitions and buy-outs are often a play to force the hand of customers to move to a new product/solution. I'm not sure this should even be legal without some form of Escrow to the benefit of user/subscriber base.

I also believe there is a SBOM discussion that relates to this topic. Knowing exactly what is being bundled with a Product/Solution is equally important. The companies/organizations behind supporting/included frameworks, modules, and plugins could be equally subject to failure.

There is lots to consider here.