Patricia Sagastume

Profile page

About Patricia Sagastume

  • Email:
  • Nice Name: patricia-sagastume
  • Website:
  • Registered On :2008-09-28 01:35:35
  • Logged in as: Patricia Sagastume

Patricia Sagastume Posts

Check out this great article from the Software Advice team .  It is a good summary of the forces keeping installed software around as cloud computing continues to emerge.  I too believe installed software will stick around.  In many instances it is a better fit for enterprises.  I have worked with EscrowTech over 13 years and witnessed the emergence of cloud computing.  In the cloud environment the vendor is exposed to additional inherent financial and business risks than with traditional “installed” Software.

One example – The SaaS user no longer obtains “ownership” or access to their unique customer data.  In traditional software this customer database resides on the user’s computer not in the cloud on the SaaS vendor’s servers.  Recently I received a call from a SaaS user who had been using a CRM SaaS solution for the past five years.  The SaaS user decided it was time to move to a more robust software solution from a different software vendor.  According to the SaaS user the current SaaS vendor held their customer data “hostage.”  Because the SaaS user no longer agreed to pay the SaaS vendor, the SaaS vendor was unwilling to release their customer data to them.  The SaaS user was forced to either stick with an unsuitable SaaS solution or move to a new solution and lose access to their customer data.  The SaaS user ended up suffering the loss of losing customer data and migrated to a new SaaS solution.  We set up a SaaS escrow with the new SaaS vendor to protect the SaaS user from experiencing this same situation again.

Recently this question was posted on Quora:

What kind of legal assurances (IP related) do SaaS startups have to give (early) enterprise customers?

Suppose there is Startup X that provides some software as a service in the cloud. And there’s an API which other service providers can use to build services on top of X’s services. Now suppose there is Startup Y which is providing some solution to end customers while using X’s services under the covers. What is the norm for the kinds of assurances that Y can expect from X in terms of IP.

Specifically, Y is worried about being locked into using X’s services without much of an alternative (because this service is not yet a commodity). So Y’s concerns are:
1. What if X suddenly increases the prices of the service?
2. What if X goes out of business?
3. What if some VC wants to invest in Y, but is worried about the risk associated with the use of X’s service – and insists that he cannot fund Y unless Y is able to acquire the IP of X (or something to that effect)?

What kinds of protections is it reasonable for Y to demand? What kind of assurances does it make sense for X to provide? I’m assuming this is not an uncommon situation – is there an industry “standard” in this area?

(Note: I am not talking about SLAs (service level agreements), or outages, and support and things like that. I am talking about the entire service being withdrawn, or prices being increased by 5X, or other such issues.

Also, I have a rough idea of how these issues are handled when either X or Y or both are big, established companies. My question has to do with the specific case where both X and Y are small, early-stage startups.)

If you were Y, what kind of assurances would you ask for? If you were X, how would you deal with a Y?

I took this to Jon Christiansen, Senior Partner of TechLaw Ventures and General Counsel of EscrowTech International, Inc.  Below is his response:

The questions are good, and often not even asked when going into a transaction like this (or most any kind of SaaS or IT outsourcing arrangement.  Here are my brief answers as a long time practicing computer law attorney and as General Counsel for EscrowTech.

Your Question #1 “What if X suddenly increases the prices of the services?”

Y should insist on long term price protection in the contract with X – e.g., Fixed pricing, capped pricing, price increased tied to a CPI or PPI index, and MFN pricing.  Also, be constantly aware of alternatives to X (i.e., competitors of X) to whom Y can go, but Y should be careful not to be locked in to X for a long contract term.

Your Question #2 “What if X goes out of business?”

This question could be asked even more broadly.  What if the service is not available from X for any of a variety of reasons.  I will ignore physical disasters because that was excluded from the question.  A small company can simply go out of business and for all practical purposes disappear.  There may be a bankruptcy petition filed by or against the company.  In a bankruptcy, the trustee will likely reject the contract between X and Y as an executory contract and deny service (and access) to Y.  There may be a contract dispute between X and Y, leading X to claim breach and suddenly terminate the contract.  The termination may be rightful or wrongful, but in either case Y will be hurt.  Even if the termination is wrongful (e.g., Y didn’t breach), X may be substantially shielded by limitations of liability that give Y little or no monetary relief for damages suffered (e.g., loss of business or profits) because of the wrongful termination by X.  X may simply decide to end service to Y for any of a variety of business reasons (e.g., the business is not profitable, there is a relationship problem, or X wants to go with a different API or business model that is not acceptable to Y) and the contract may allow termination or a decision not to renew.  I call these financial and legal disasters (as opposed to physical disasters usually addressed through a disaster recovery plan of X).  For these legal disasters, the disaster recovery plan does not good.  The best solution is a SaaS or cloud escrow that has a third party (e.g., a company like EscrowTech – obviously I am biased) implement and maintain a mirrored solution (servers, software, continuously updated data, etc.) in place in a hot, warm or cold state that can be turned on in the event of one these legal disasters.  X should grant a license to use the software and any needed materials, development environment, intellectual property, etc.  The grant should occur upfront, and not later.  A license that is granted prior to the filing of a bankruptcy petition can be retained if the contract is rejected by a trustee in bankruptcy under Section 365(n) of the Bankruptcy Code (a post-petition license cannot be retained).  Even though the service by X stops, the service can be continued by the third party for Y (and other customers of X if they are also beneficiaries under the escrow).  Any of the legal disasters (not just bankruptcy) or an excessive price increase (you mentioned 5X) could be a trigger that allows the third party (escrow company) to make the mirrored solution available to Y.

Y could itself act as the escrow company for itself and have the mirrored solution on its own servers.  But Y may not have the capability or resources to do so.  Also, X may object to having customers hold X’s valuable software, intellectual property, etc.  X may not want multiple clients to have its proprietary solution.  Consolidating the solution with one SaaS escrow company would be better from X’s perspective than distributing the solution to multiple customers who might not take the same precautions as a SaaS escrow company.

A “storage” escrow may be sufficient in some cases in lieu of a full SaaS escrow.  In other words software (including source code), development environment, configuration files, build instructions, etc. could be held in escrow, but this is far less protective of Y than the SaaS escrow described above that has a mirrored solution ready (or nearly ready) to go in the even of a trigger.

None of this is “standard” because usually companies like X ignore the risk.  But increasingly more companies like Y and their investors are giving attention to this issue and protecting themselves.

For more information on SaaS escrows go to or see the video at

Question #3 “What is some VC wants to invest in Y, but is worried about the risk….?”

The VC should be worried and refuse to invest unless Y takes the precautions described above.

Click here for original question from Quora

When a SaaS customer adopts a SaaS solution over a traditional software license the customer may no longer have possession and control over its data residing on the servers and storage devices of the SaaS vendor.The customer, as a subscriber to the SaaS solution service, is vulnerable to inherent risks of the cloud and a SaaS business relationship.

SaaS customers are faced with the reality of these risks:

  • Sudden temporary or long term loss of access to SaaS services, applications and data due to legal and financial disasters such as SaaS vendor bankruptcy, insolvency, business discontinuation, contract termination, legal disputes, litigation, and deteriorating business relationships.
  • Their own SaaS data being corrupted or lost by the SaaS vendor.
  • The need to comply with internal policies and external regulations that are not met by the current SaaS vendor’s practices and capabilities.

A traditional SaaS storage escrow can provide assurance to the SaaS customer that it will have access to the SaaS application (source code and object code) and SaaS data if a release condition should ever arise.In this type of escrow, the SaaS application, build environment, implementation instructions, and any other desired materials are stored in escrow along with timely deposits of the customer’s SaaS data.Upon the occurrence of a contractually-agreed-upon release condition, the deposits materials (e.g., the SaaS application and SaaS data) will be released to the SaaS customer.The SaaS customer is then able to install and use the SaaS application to assist it in continuing operations that were dependent on the vendor’s SaaS solution.The SaaS customer will also be able to recover and use its data from the escrow.

In instances where immediate or prompt access to the SaaS solution is required, only a complete SaaS data center escrow is sufficient.In a SaaS data center escrow, the SaaS application and data are hosted on servers and storage devices at an Escrow Data Center.The SaaS application is continually populated with the customer’s SaaS data.In effect, a mirror of the SaaS solution is held at the Escrow Data Center.If a release condition occurs, the mirrored SaaS solution can be brought online for access and use by the customer.The SaaS customer is then able to continue operations without losing access to a functioning SaaS solution and its SaaS data.

There are significant motivators for software users to transition from traditional software licenses to SaaS solutions accessed over the Internet. In many instances the risks described above have inhibited some customers from adopting a SaaS solution. SaaS escrows can eliminate or substantially mitigate those risks for customers. SaaS vendors can also benefit from the adoption of SaaS escrows because these escrows proactively alleviate the concerns of prospective customers. By proactively protect the interests of customers when a SaaS vendor escrows its SaaS solution, the SaaS vendor provides a more reliable solution and addresses what may be the unspoken reservations of a prospective customer.

To learn more about EscrowTech’s various levels of SaaS Escrow solutions watch