Software-as-a-service (SaaS) has increasingly become the most popular deployment method for many enterprise level applications. There are many benefits including:
- Rapid deployment
- Cost savings, both in purchase and support
- Regular upgrades
- Reduced need for internal support
This article isn’t about debating the pros and cons of SaaS as a model, but will focus on the issues about data access and governance. Also it is coming from the perspective of the IT Garbageman where we have to clean up after as SaaS engagement is wound down, but there are fundamental issues about data governance that are at the core of the challenges we face.
Why the Divorce Analogy?
Like a marriage a SaaS relationship begins with a postive relationship characterized by:
- Enthusiasm
- Collaboration
- Long-term partnership
In contrast the end of a SaaS relationship primarily consists of negative aspects such as:
- Antagonism
- Contractual obligated actions only
- Short-term thinking
Regrettably many personal partnerships come to an end and often they end acrimoniously, whereas software relationships will always eventually end. For the client a key requirement is to secure their data stored in the vendor application. And just like in many divorces when you need something valuable from the other party be prepared to pay the price…
The “Warm and Fluffy” Vendor
Currently the majority of the applicaions that my team deal with are on premise deployments but this will shift over time to SaaS applications, and even with this relatively limited number of retirements we have already encountered some extreme positions taken by vendors. Examples include (my paraphrasing):
- “Our other clients just use a read-only version of our application. It’s a bargain at $200k/year”
- “Sure the data is yours, but the data structure is our IP. You can’t have it”
- “We’ll give you a part of the database, but after we have deleted the IP from the application which will stop the front end from working. You’ll get a flat file from the application but won’t be able to test it for completeness or accuracy”
- “All of our other clients are OK with this – why aren’t you?”
- “Can’t you just print some reports?”
- Vendor account manager: “Sorry, I’d be happy to give you documentation on the data structure but I can’t. I’ve been asking for that from the support team for years but they won’t even give it to us”
- “The contract says we can shut the application down on the last day of this month and that date isn’t changing” (the contract actually allowed an automatic 90 day extension)
- “There are only a couple of people who can answer your questions and they are busy working with other clients”
Fundamentally it is in the vendor’s best interest to stretch out the relationship as long as possible. As long as the application is running they get to charge you for its use so delaying tactics financially benefit them.
Signing the Pre-Nuptual
Ideally you should plan to protect your data before signing the initial contract with the SaaS vendor. If that opportunity has passed make these arrangements as soon as possible—certainly before the vendor becomes aware that you intend to terminate the contract. It won’t be a conversation that the vendor or many business partners want to have, particularly as it may add to the cost of the deal initially. However, having these agreements in place will help you avoid significant costs, risks, and delays when the contract eventually ends.
Key points to consider are:
- Will the vendor provide the complete database in the original format?
- If not, what format will be provided and how will the vendor demonstrate accuracy and competeness?
- If not, what remedial actions will be available if at a later time the data is determined to be incomplete or inaccurate? For example if the application is critical (e.g. GxP) will the vendor commit to preserving a copy of the database to be placed in escrow?
- Will the vendor commit to providing documentation to enable the interpretation of the provided data?
- Will the vendor commit to providing the SQL or equivalent query code for 5-10 critical reports?
- Will the vendor commit to providing a specified number of professional services hours at a specified rate to support the transition?
- Will the vendor provide the production environment or equivalent for 30 days after the delivery of the data to permit completeness and accuracy testing to occur?
Relationship Already Ending?
Already planning to get out of the SaaS contract, or worse does the vendor know you are planning to exit? Now it is time for damage limitation.
What is at Risk?
First, assess the importance of the data in the application that needs to be retained. Ideally, all necessary data will already be planned for migration to the replacement application or will be manually recreated. If that’s the case, pop the champagne corks and move on to the next challenge.
If the remaining data is of low value, consider whether it’s even worth the effort to keep, or at least identify the minimal subset that is worth retaining.
For data that needs to be preserved but can be rendered to PDF, explore whether the process can be automated or if bots can be used to generate the required data in bulk. While this approach may seem cumbersome, it has the advantage of utilizing the SaaS application’s existing tools, thereby avoiding the complexities of data migration and report development (along with the associated documentation and testing).
However, more often than not, the data is of significant value and must be retained.
Does the Vendor Know or Suspect You’re Leaving?
“All’s fair in love, war and SaaS contracts”
The IT Garbageman (with apologies to John Lyly)
If the vendor is blissfully unaware that you are thinking of existing the contract then you have additional advantage. Keep in mind 99% of vendors will use leverage against you in the remaining phases of the contract so don’t feel guilty about taking advantage of the situation. Also determine how long you have before the vendor will be informed as it will affect your actions.
One strategy is to approach the vendor with a request to understand the mechanisms available for extracting substantial data in an automated fashion from the SaaS application, with creation of a corporate data lake an acceptable reason why you would be looking to do that. Ask if other clients have built data lakes in the past and get contact details to talk to them.
During these discussions, find out in what format the data will be provided and what documentation will be included to help you interpret it. DO NOT assume that receiving the complete database will suffice—I’ve personally spent weeks, alongside another Director, sifting through a database that contained confidential information (which couldn’t easily be delegated). The database appeared to have been pieced together over time from two or even three different applications, with inconsistent naming conventions for key fields.
How Long Do You Need Your Data?
The retention period for data can vary wildly from a year or two up to decades. In the event that the retention is at the lower end then it might be cost effective to negotiate a deal with the vendor for a read-only version of the application with a greatly reduced user base. Just remember that a lawsuit could easily extend the retention period so factor unplanned extensions into your calculation.
Conclusion
If you have to bring your data back in house then prepare for a potentially elongated and costly process, particularly if the vendor knows you are leaving and doesn’t have any incentive to play nice. Key considerations:
- Set business expectations on the end of the contract. Even if you can build the data migration method ahead of time then you will still need to test the migration and reports against your internal data store. Many business groups expect they can terminate the contract a couple of weeks after they cease actively using the application – this just isn’t realistic.
- Read the contract … in detail. Understand if there are terms and conditions that can work in your favor, either in reducing the cost of the contract during the data migration (e.g. reduce the number of named users) or in terms of vendor obligations to keep read-only copies available for a couple of months.
- Talk to other clients that have exited and see if they are willing to share their experiences.
