Managing the Escrow Release

Technology escrow releases have skyrocketed. Between 1990 and 1999, Iron Mountain processed an average of 12 escrow release per year. Since then, that figure has climbed to an average of nearly 70 releases a year.

This increase is largely due to today's economic climate and the increased number of vendor shakeouts. In addition, companies are listing more specific release "triggers" in their escrow agreements. Today, the reasons for an escrow release go beyond vendor bankruptcy. They can vary from a shift in the vendor company's corporate focus to the loss of key employees.

In light of the increase, companies should prepare for an escrow release. Following are stories of how some Iron Mountain clients have successfully prepared for and managed their escrow releases.

A Software Release
Oilsands.com, a Canadian-based community portal, received an escrow release a few short months after licensing a mission-critical application from a well-funded startup.

Oilsands had integrated third-party software into its own technology to create an e- business suite that includes the front- and back-office capabilities for small- to medium- sized companies to go online. Dozens of resellers and their customers had already licensed the technology from Oilsands and were dependent on it for their online businesses when CEO Paul Fleming's worst fears were realized – the vendor declared bankruptcy.

Fleming explained that the software was server-based, and losing the vendor's support would likely have caused severe operational and financial losses. But Fleming had set up a software escrow account with Iron Mountain to protect his company in such an event.

The technology escrow enabled Oilsands to secure the source code for the technology and keep systems operating for itself, its resellers and the resellers' customers, Fleming said.

"If we had lost the technology, we'd have had to leave town," Fleming joked. "But, fortunately, with the source code at hand, we were able to keep the technology running."

After Oilsands received the source code, Fleming had the foresight to hire a number of experienced programmers from the bankrupt software company who had worked closely with the technology to help Oilsands maintain it in-house.

A Hardware Release
In the case of software developer and systems integrator Comverse Inc. of Wakefield, Mass., the collapse of a hardware vendor could have led to a loss of tens of thousands of dollars in redesigning an already existing product. However, according to Brian Heffernan, assistant general counsel at Comverse, its vendor had been required to escrow with Iron Mountain the build plans, technical specifications and other documentation needed to create the hardware.

"Comverse doesn't manufacture the hardware that it sells. We depend on hardware vendors to furnish us with baseboards, components and related materials that we integrate into the enhanced service systems that we develop and sell to our own customers," said Heffernan.

When one of its board manufacturers filed for bankruptcy and announced its intention to sell its business to a company with which Comverse had no prior experience or relationship, Comverse elected to quickly shift its business to a different hardware vendor that it preferred. Fortunately, Comverse had an escrow in place that allowed for a "demand release," which enabled the company to gain immediate access to the build plans for its boards and to provide those plans to its chosen hardware vendor in a timely fashion.

The downfall of Comverse's vendor resulted from significant cutbacks within the high- tech industry, which led to a drop in demand for the vendor's products. Comverse, whose business was still thriving and which was reliant on the vendor's technology and know- how to produce the hardware, was unexpectedly left without the source of supply that it needed.

"We had a good relationship with our vendor and had little reason to discontinue working with them," said Heffernan. "But companies must prepare for the unexpected. They need to be in a position in which they can continue their business and serve their own customers or clients without interruption, even if their technology vendors disappear."

A Case for Verification
Since the escrow agent is not responsible for the validity of the escrow deposit, there is a risk that what is actually deposited in escrow is not exactly what the licensee expects it to be.

David Kristick, director of operations for the E-470 Public Highway Authority in Colorado, experienced a close call that illustrates the importance of verifying and updating escrow deposit materials. Kristick had secured in escrow third-party software that allowed for electronic toll collection. When the software licensor became unable to support the software, Kristick requested a release of the source code from Iron Mountain. Pursuant to the terms of the escrow agreement, Iron Mountain released the source code to Kristick, but what Kristick received wasn't exactly what he was expecting.

"What we received out of escrow was an old version of the software," said Kristick. "Not the version we were currently using."

"Fortunately, we were able to use the released source code as a benchmark from which to build the software we needed," said Kristick.

In that sense, the source code release worked out for E-470. But things could have turned out differently had the organization not had the time and resources to build upon the old code.

Iron Mountain's verification testing services can help to ensure that in the event of a release, the licensee will receive exactly what it expects. These tests can validate the accuracy of the source code in escrow and ensure that all information needed to replicate the original development environment is identified and documented.

In E-470's case, it may have been just as important to demand more frequent updates to the deposit.