Lock-in is not a feeling. It is a set of specific, documented mechanisms: a data-retrieval clause in the master subscription agreement, an API quota table in the developer docs, an automation runtime that exists nowhere outside the vendor cloud. Every fragment is public, the problem is that nobody assembles them until the week a renewal quote lands. This audit assembles them in advance. Run it with one operations owner and one engineer, and you walk into the renewal conversation knowing what leaving would actually cost, the only position from which staying is a decision rather than a default.
What is a CRM exit-readiness audit, and why run it before renewal?
A CRM exit-readiness audit is a structured review of every mechanism that would slow or block a migration off your CRM: contractual export windows, non-portable automation logic, licensing coupling, API constraints, and integration dependencies. Run it 90 to 120 days before renewal, while you still have time to act and leverage to negotiate.
The audit produces three artifacts:
- ▸An exit-cost estimate, rough line items for data, logic, and integrations.
- ▸A red-amber-green scorecard across contract, data, logic, licensing, and integrations.
- ▸A negotiation agenda, every red item is either a clause to amend or a concession to demand.
Most teams that run it end up staying on their CRM, but on better terms, because vendors price renewals against your perceived switching cost. Demonstrating a credible exit path, the approach detailed in Build the Exit Before the Renewal: The SaaS Negotiation Prototype, changes the quote.
How long do you actually have to export data after cancellation?
Commonly around 30 days, sometimes less, and only what your contract guarantees. Post-cancellation data-retrieval windows live in the master subscription agreement or terms of service, not the order form, and once the window closes vendors delete your tenant on their own schedule. Verify the exact clause for your vendor and edition before relying on it.
Three checks to run this week:
- ▸Find the clause. Search the agreement for terms like data retrieval, post-termination assistance, or return of customer data. Note the window length, the promised format, usually CSV, and whether retrieval help costs extra.
- ▸Test a full export now, while you are a customer in good standing. Standard exports commonly omit attachments, email logs, field history, and audit trails; those often require API extraction, which a cancelled account may no longer have.
- ▸Check the deletion timeline. Some contracts specify deletion after a set period; others say only that data may be deleted. If you carry regulatory retention duties, that ambiguity is your problem, not the vendor's.
For EU customers, portability and switching obligations for data processing services strengthen your hand over time, see EU Data Act, September 2026: Access-by-Design and Cloud Switching Obligations, but your contract language still decides the specific case.
Which parts of your CRM cannot be exported at all?
The logic layer. Automations built in proprietary builders and languages, Apex classes, Flows, workflow rules, validation formulas, custom scoring models, export as metadata definitions at best, but the runtime that executes them exists only inside the vendor. Your data is portable; your behaviour has to be re-implemented on the other side.
Inventory it honestly:
- ▸Count the automations. Every Flow, trigger, workflow rule, custom formula, and approval process is a rewrite line item. Teams are routinely surprised to find hundreds accumulated over five or more years.
- ▸Flag managed packages. Third-party packages install objects and logic you cannot inspect and cannot take with you; each one is a dependency decision, not just a rewrite.
- ▸Separate live from dead. Typically a meaningful share of automations are disabled, superseded, or firing on records nobody creates any more. Only the live ones cost money to rebuild.
This inventory is the single biggest input to any credible migration estimate, which is why it is step one in Leaving Salesforce: The Engineering Migration Runbook.
How does seat-tier coupling quietly raise your exit cost?
Seat-tier coupling means one needed capability drags every user to a higher edition, because CRM pricing bundles features by tier rather than selling them individually. The sharpest version: bulk APIs, sandboxes, and advanced admin tooling often sit in upper tiers, so the capability you need in order to leave can itself require an upgrade.
What to check:
- ▸Map features to tiers. List the capabilities your team genuinely uses that justify the current edition. Commonly it is one or two; the rest arrived in the bundle.
- ▸Check what the exit requires. In several mainstream CRMs, API allowances, full sandbox copies, and metadata tooling scale with edition. Budget a possible short-term tier bump as a migration cost, or negotiate temporary access into your termination terms.
- ▸Watch seat-minimum and ratchet clauses. Some agreements set seat floors or allow counts to rise but never fall, so shrinking usage during a phased migration does not shrink the bill.
If most seats only read data and log activity, the cheaper structural fix may be Replace the Seat, Not the Suite: The Partial-Build Pattern.
Where do API rate limits block a realistic migration?
At bulk extraction. Daily API quotas, per-call record caps, and concurrency limits mean a full pull of a multi-million-record tenant can take days or weeks at documented rates, longer once attachments are involved. Model your record counts against your edition's current limits before you commit to a cutover date.
The estimation method is worth doing on paper:
- ▸Total calls: for each object, divide the record count by the records returned per call, then sum across objects.
- ▸Extraction days: divide total calls by your daily quota, remembering the migration shares that quota with every production integration still running.
- ▸Attachments dominate. Files and email archives are commonly the slowest, most quota-hungry part of an extraction; test a representative sample before extrapolating.
Vendors publish these limits and change them, so verify against current documentation rather than third-party posts. A dry run against a sandbox takes an afternoon and turns your timeline from a guess into a measurement.
What is integration gravity, and how do you measure it?
Integration gravity is the pull exerted by everything wired into the CRM: marketing automation, support desk, billing, BI connectors, enrichment tools, telephony, and no-code scenarios. Measure it by listing every inbound and outbound connection and classifying each as re-pointable, replaceable, or rebuild-required. It usually outweighs the data migration itself.
How to measure it in practice:
- ▸Pull the connected-apps list and the API key inventory from the admin console. That is your ground truth, not the architecture diagram, which is always out of date.
- ▸Classify each connection: re-pointable (the tool has a native connector for your target), replaceable (a commodity alternative exists), or rebuild-required (custom code or a vendor-specific integration).
- ▸Count the silent dependencies. Zapier and Make scenarios, spreadsheet syncs, and one-off scripts commonly outnumber the official integrations, and nobody owns them.
High gravity does not automatically mean a full migration is wrong. Sometimes the answer is keeping the SaaS as the front-end while moving the operational core, the pattern explored in Hybrid CRM Architecture: Keep HubSpot, Build the Operational Core.
What does the full pre-renewal checklist look like?
Fifteen checks across five areas. Contract: export window, deletion timeline, non-renewal notice period, auto-renew and price-increase terms. Data: full export test, attachment and history coverage, format fidelity. Logic: automation inventory, live-versus-dead split, rewrite estimate. Licensing: tier-gated capabilities, seat floors. Integrations: connection inventory, classification, shadow dependencies. Score each red, amber, or green.
Practical mechanics:
- ▸Staff it small, one operations owner plus one engineer, about a week of part-time effort.
- ▸Time-box the estimates. You need order-of-magnitude numbers, not a project plan; for rebuild pricing context, see How Much Does It Cost to Build Custom Software in 2026?.
- ▸Write the one-pager. Reds with a cost attached become your negotiation agenda; their total becomes your credible walk-away number.
- ▸Add the security lens. The same inventory, tokens, connected apps, export paths, doubles as a threat-model input; see What a Security Firm Sees When It Threat-Models a Typical CRM Stack.
When is the answer stay, and when is it build?
Stay when your reds are contractual, windows, notice periods, price terms, because those are negotiable. Consider building when the reds are structural: logic you cannot export, integration gravity you keep feeding, and per-seat pricing scaling faster than headcount. The audit does not presume leaving; it prices the option.
The general decision framework in Build vs Buy: When to Use SaaS and When to Build Custom Software applies, with one addition: an audit that comes back deep red rarely improves by waiting, because every quarter adds automations, integrations, and records. For teams that do decide to move, the sequencing, parallel running, phased cutover, rollback points, is covered end to end in Escaping SaaS: The Complete Guide to Migrating to Custom Software. Either way, put the audit on a recurring calendar: exit readiness decays.
How TuniCyberLabs helps
We run CRM exit-readiness audits as a short fixed engagement: contract review alongside your counsel, a scripted export and API dry run, an automation and integration inventory, and a costed scorecard you can take into the renewal call. When the numbers say build, our software engineering team scopes and delivers the replacement; when they say stay, you negotiate from evidence.
If your renewal lands within the next two quarters, start now, the audit is a week of work that changes a six-figure negotiation.