A customer support platform becomes difficult to leave when the business can export ticket text but cannot reproduce the working system around it. Lock-in can hide in attachments, identities, custom fields, routing rules, integrations, knowledge links, automation, reporting definitions, and contract timing. Review portability before migration is urgent, while both the current system and knowledgeable staff are still available.
Define the complete support record
Inventory tickets, messages, private notes, attachments, requester and organization records, agents, teams, forms, fields, tags, status, priority, assignments, service-level timers, audit events, consent or suppression state, macros, workflows, bots, knowledge links, and integration references. For each object, name a stable identifier and relationship that must survive migration.
Ask the vendor which objects appear in exports, which remain available only through an API, which are represented only as links, and which cannot be extracted. Record format, encoding, pagination, rate limits, date filters, incremental export support, attachment behavior, and deleted or archived content. “CSV export available” is not an adequate answer when threaded replies or private notes are missing.
Inspect provider-specific workflow dependencies
NIST SP 800-146 warns that SaaS export and import formats may not be fully compatible and that customized workflows, business rules, settings, scripts, extensions, and add-ons can be provider-specific. Map every routing rule, approval, escalation, webhook, custom app, AI classifier, reporting formula, and support template that would need to be recreated.
Look for rules that are visible only in an administrator interface, apps owned by a departing consultant, scripts with no source repository, undocumented field meanings, and automations that call vendor-specific actions. Export configuration where possible and maintain a human-readable rule book. If the vendor cannot export rules, estimate reconstruction and validation work explicitly.
Test portability rather than accepting a feature label
The NIST cloud standards roadmap treats data and application portability as key to moving between cloud services and limiting vendor lock-in. Run a small test with invented tickets representing public replies, private notes, files, reassignment, merged cases, custom fields, and reopened status. Open the result independently and map it into a neutral model or sanctioned test destination.
Compare counts, relationships, timestamps, authorship, message order, permissions, and file access. Record what cannot be reconstructed. A successful download is not proof of portability when files still point to authenticated vendor URLs or IDs have no mapping outside the source platform.
Review identity, access, and continuity
Check whether sign-in, user lifecycle, groups, roles, and audit logs depend on a vendor identity service or premium plan. Determine how administrators regain access if the primary account is unavailable and how service accounts are transferred. Keep account ownership and recovery contacts under business control without weakening authentication.
Document the manual fallback for new requests during migration. Decide how dual-running tickets are reconciled, how duplicate replies are prevented, and when the system of record changes. Preserve a read-only archive only if access, retention, cost, and privacy requirements are explicit.
Calculate the real exit constraint
List notice periods, renewal date, minimum term, export windows, API entitlements, egress or professional-services fees, support charges, required plan upgrades, storage charges, and deletion schedule. Ask how long the business can download data after termination and what evidence confirms deletion. Distinguish documented contract terms from sales assurances.
Estimate staff time for extraction, transformation, configuration, testing, training, parallel operation, customer communication, and post-migration correction. A low license price can coexist with a high exit cost. Record the person who owns the exit plan and the date the assumptions were checked.
Watch for practical warning signs
High-risk signs include exports restricted to public or recent content, file links that expire with the account, undocumented schemas, no incremental export, no configuration export, strict API throttles, inaccessible audit history, proprietary identity mapping, mandatory vendor services, and no tested deletion or restore path. Another warning is operational knowledge that exists only in vendor support conversations.
Score each dependency by business impact, replacement effort, evidence quality, and time sensitivity. Do not assume an open API guarantees migration; endpoints can omit data, change by plan, or require credentials that disappear at termination.
Keep an exit-ready evidence packet
Maintain the data inventory, neutral schema, sample export, field map, workflow register, integration owners, identity plan, contract dates, cost estimate, fallback, acceptance tests, and unresolved gaps. Re-run the sample after material configuration or plan changes.
A defensible decision may still choose a vendor with lock-in. The important distinction is whether the dependency is understood, priced, reversible enough for the business, and supported by tested evidence rather than a checkbox on a procurement page.
Sources
- NIST SP 800-146: Cloud Computing Synopsis and Recommendations — National Institute of Standards and Technology
- NIST SP 500-291 Revision 2: Cloud Computing Standards Roadmap — National Institute of Standards and Technology