Put exit terms in the RFP, not the renewal
Most buyers negotiate exit terms at the worst possible moment: after they have decided to leave, or when a renewal is weeks away and switching is unrealistic. By then the vendor knows you have few options.
During an RFP, every vendor wants the deal. Put your data and exit requirements into the RFP itself, and treat them as scored requirements rather than legal cleanup for later.
What this looks like in practice:
- Include a short data and exit schedule in the RFP pack, with your preferred clauses attached.
- Ask vendors to confirm acceptance or propose redlines as part of their response.
- Weight the answers. Vendors who refuse basic portability should lose points, the same way they would for missing a core feature.
This also tells you early which vendors will be difficult to work with later.
Define the data before you claim ownership of it
A contract that says the customer owns customer data is only as good as its definition of customer data. Vague definitions are where vendors keep rights they should not have.
Split the data into categories and decide your position on each:
- Customer data: everything you or your users upload, enter or send to the service, plus any output generated from it. You should own this outright.
- Derived or processed data: reports, enriched records, configurations, workflows and models built from your data. Push for this to count as customer data. It is often the hardest thing to rebuild after a switch.
- Usage and telemetry data: logs of how your users interact with the product. Vendors usually want to keep this for security and product improvement. That is reasonable if it is limited to that purpose.
- Aggregated or de-identified data: statistics combined across customers. Vendors will want the right to use this. Accept it only if the data cannot identify you, your users or your customers, and cannot be sold as a dataset.
If the vendor uses customer data to train AI or machine learning models, address it directly. State whether that is permitted, and if so, whether you can opt out.
Ownership and license clauses to use
The ownership clause should do two jobs. It confirms that you own the data, and it limits the vendor's license to what it needs to deliver the service.
Example wording to adapt with your counsel:
Ownership. As between the parties, Customer owns all right, title and interest in Customer Data. Vendor acquires no rights in Customer Data other than the limited license granted below.
License to Vendor. Customer grants Vendor a non-exclusive, non-transferable license to process Customer Data solely to provide the Services to Customer during the Term and any Transition Period. Vendor will not sell, rent or disclose Customer Data, or use it to train models made available to other customers, without Customer's prior written consent.
Watch for these vendor redlines:
- Perpetual or irrevocable licenses to customer data. Strike them.
- Use for any lawful purpose or to improve our products without limits. Narrow the scope, or tie it to aggregated data only.
- Ownership of feedback that is broad enough to cover your data. Feedback clauses should cover suggestions about the product, not your content.
- Suspension rights that let the vendor lock you out of your data during a billing dispute. Make sure data access, or at least export, continues.
Portability: format, frequency and cost
Ownership means little if you cannot extract the data in a form another system can use. Portability terms should cover four things.
Format. Require export in a common, documented, machine-readable format such as CSV, JSON or XML, or a standard database dump. For files and documents, require the original formats. Ask for the schema or data dictionary so a new vendor can map the fields.
Completeness. The export should include records, attachments, metadata, audit logs, user lists and configuration where relevant. A table of records without its history or relationships is often not usable.
Frequency and method. Self-service export at any time through the product or an API is best. If exports need a support request, set a turnaround time, for example within 10 business days of the request.
Cost. Routine exports should be included in the subscription. For a large one-time export at exit, agree to a fee schedule now, such as a capped professional services rate. Unpriced exit services tend to get expensive once you are leaving.
Test it before you sign. Ask for a sample export from a trial or reference account and have whoever would run a migration review it.
Exit, transition assistance and deletion
Exit terms cover what happens between the day you give notice and the day the vendor holds none of your data.
Transition period. After termination or expiry, you need continued access to the service or at least to exports. A transition period of 30 to 90 days is a common range. For complex systems, negotiate an option to extend on the same pricing.
Transition assistance. For critical systems, require reasonable cooperation with you and your new vendor, including answering technical questions and supporting a data migration. Set the rate for this in advance.
Termination triggers. Make sure exit rights apply however the contract ends. That includes your termination for convenience, termination for the vendor's breach, non-renewal, and the vendor's insolvency, acquisition or discontinuation of the product.
Deletion and certification. After the transition period, the vendor should delete your data and confirm it in writing. Allow a reasonable window for backups to age out.
Return and Deletion. Within 30 days after the end of the Transition Period, Vendor will delete all Customer Data from its systems and those of its subprocessors, and provide written certification of deletion on request. Data in backups will be deleted in the ordinary course of backup rotation and will remain subject to this Agreement until deleted.
Check that deletion obligations flow down to subprocessors, and that the vendor may keep only what the law requires.
RFP questions and a post-signature checklist
Questions to include in the RFP:
- Confirm that the customer owns all customer data, including outputs and configurations.
- List every purpose for which you use customer data beyond providing the service.
- Do you use customer data to train models? Can customers opt out?
- What export formats do you support, and is export self-service or by request?
- What does a full export include? Provide a sample and the data dictionary.
- What are your fees for exports and transition assistance at exit?
- How long after termination can we access or export our data?
- How do you delete data, including from backups and subprocessors, and do you certify deletion?
- What happens to customer data if you are acquired or discontinue the product?
After signature, keep the terms working:
- Record the export method, transition period and deletion timeline in your contract register.
- Run a test export once a year and keep a recent copy for critical systems.
- Recheck the terms when the vendor changes ownership, subprocessors or its product.
- Set a notice reminder well before the renewal date so an exit is a real option.
- When you exit, request the deletion certificate and file it with the contract.
Let pingpong run it for you
pingpong drafts the RFP, finds and invites vendors, collects proposals through a private portal, scores them with five AI models and flags the gotchas above. It drafts every negotiation message for your approval, then keeps watching the market so you renegotiate before renewal. $100 for the first month, then $799 a month.
Common questions
Should we let vendors use our data in aggregated form?
Usually yes, with conditions. Allow it only for data that cannot identify you, your users or your customers, and only for internal purposes such as benchmarking or product improvement. Prohibit selling or licensing the aggregated data as a standalone dataset.
How long should the post-termination transition period be?
Thirty to 90 days is a common range for most software contracts. Systems with large data volumes or complex integrations may need longer, so negotiate an extension option at the same pricing. What matters most is that the period is long enough to run and verify a full migration.
What if a vendor refuses to include exit terms?
Treat it as a risk factor in your scoring, not a legal detail. Ask what they will accept, for example self-service export and a deletion commitment, even if they refuse transition assistance. If they will not commit to basic portability, factor the cost of being locked in into your decision.