How can DevOps help to improve Software Escrow procedures?
A very interesting question. On the assumption that the goal of a Software Escrow process is to allow for a 3rd Party to take over or nominate an additional party to fulfil the responsibility of the software vendor, I would suggest the following elements of a DevOps operating model that would support software escrow:


Infrastructure-as-code - effectively documenting through an executable specification of dependant infrastructure, stored and versioned in source control provides the environments that the source code is developed in.  Unlike static documentation in text files because it is executed on a regular basis by the software vendor to build their own environments it does not go out of date of suffer from "bit rot".  This will always hold the most value when the entire development pipeline is built and maintained in source control applying Infrastructure-as-code principals.
Continuous Integration - the goal of continuous integration is to execute a set of steps that integrate the solution on a regular basis, ideally upon each change.  Typically this means upon check-in and push to a central repository a set of tests are executed that validates the process.  From a software escrow perspective I would expect this to also push a working version to a secondary "backup" repository owned and operated by the 3rd parties.  It is important to note that this does need to be both legally and financially "unlinked" from the software vendor.
Continuous Deployment - the goal of continuous deployment is to deliver software in a working state on a frequent basis.  In this sense the 3rd party is just another deployment target to deploy the outputs to, albeit probably not actively spinning up infrastructure on the 3rd parties fabric.


Some other considerations to bring into the equation are:


the move from static documentation to infrastructure as code significantly reduces the toil involved in updating documentation that describes how to install, configure and recover software.
don't forget secrets management, such as X.509 Certificates, symmetric keys, passwords and licence keys, these could be stored in source control however this does have it's own drawbacks.  


From a tools perspective this will depend very much upon the development environment, I don't believe there are any tools specific to software escrow however:


.NET Development


GitHub or BitBucket for source control
AppVeyor, TeamCity or Jenkins for the build and test elements of the pipeline.
Ansible, Puppet or Chef for the configuration management elements of the pipeline.
ProGet for the package management elements of the pipeline
Octopus Deploy for the deployment aspects of the pipeline

Java Development, and to some extend Open Source platforms


CircleCI, TravisCI, TeamCity or Jenkins for the build and test elements of the pipeline.
Ansible, Puppet or Chef for the configuration management elements of the pipeline.
JFrog Artifactory or Sonartype Nexus for the package management elements of the pipeline
Capistrano for the deployment aspects of the pipeline



At the end of the day if you are able to employ Infrastructure-as-code, Continuous Integration and Continuous Deployment principles to a software package it can be used to fulfil your obligations under a Software Escrow contract.