Before you sign: how you will get your data back from a provider

Before signing with a provider, I would ask for a sample of what you will receive when the service ends. A table of contacts? Orders with their identifiers? Attachments too, and the link between each order and its customer? “The data is yours” expresses an intention, but it does not answer those questions.

In a hypothetical scenario, you change tools and receive a CSV containing names and totals. The documents remain in the old system, and there is no key linking them. You have a file, although you still cannot carry on working. You can detect that problem earlier: test an export and check what it lets you reconstruct.

Define what will be delivered and how it will be checked

I would separate three things in the agreement: access during the service, delivery at the end and use of the tool afterwards. For delivery, I would specify the datasets, formats, attachments, field documentation and relationships needed. Also the deadline, any cost and who confirms that delivery is complete.

Under my contract, the client's business data held in their own systems stays there and is not affected by termination. When the solution requires storing client data in my infrastructure, it is kept in an isolated container exclusive to that client, separate from the processing layer, with the client's own access throughout the contract term.

When the contract ends, for any reason, I deliver all of the client's data held in that container within a maximum of 15 calendar days, in CSV or JSON format. This delivery does not include workflows, code, prompts or architecture; their licence to use ends with the contract.

CSV and JSON can be useful formats. Their names do not guarantee that they include historical records or that the next program will import them without adjustments. I would ask for a test with fictitious data: open the export, locate an order and retrieve its customer and documents. If something is missing, it should be listed as an exclusion before you sign up.

I would also check who administers the domain, email and infrastructure accounts. I would prefer accounts controlled by your business, with permissions delegated to the provider where possible. Keeping every password in a shared document is no substitute for defining access, recovery and revocation.

The GDPR has a specific scope

For a business in Spain, if the provider processes personal data on your behalf as a processor, Article 28 of the GDPR requires that processing to be governed. Paragraph 3(g) provides for personal data to be returned or deleted when the service ends, at the controller’s choice, and for copies to be deleted unless applicable law requires retention.

That does not make the GDPR a general ownership rule for all business data. Nor does it replace an exit agreement. Portability under Article 20 is an individual’s right concerning certain personal data, subject to its conditions; it is not a business’s right to receive the whole application or any file it wants.

I would specify how backups and retention obligations are handled, rather than promise that everything will disappear immediately. Access to personal data must remain restricted to authorised people during the transition.

Taking your data does not give you every right to the code

A licence to use the software, a possible transfer of rights and delivery of the code are separate matters. In Articles 43 and 45, Spain’s Intellectual Property Law sets the scope of transfers of exploitation rights and requires them to be put in writing. It does not justify concluding that every mechanism always belongs to the provider, or that paying for development automatically transfers all rights to it.

I would ask the contract to identify what you can continue using when the service ends and any third-party dependencies. You may retain your data and still need another tool to work with it. That transition takes time and needs someone responsible for it.

These are questions to prepare for reviewing a technology contract, not a legal assessment of your situation. Before signing, it is worth checking the exit arrangements with whoever will implement the migration and with a professional who can review the applicable terms.

Sources

If you want to clarify what a technical exit from your system would require, you can discuss it with me through Let’s talk.

Get in touch