An ABA scheduling vendor exit data plan defines how the practice will preserve service continuity, retrieve usable schedule data and history, move required functions, restrict access, reconcile connected systems, and verify vendor deletion. It covers records, versions, logs, messages, exports, integrations, credentials, retention, contracts, cutover, rollback, and unresolved work. The plan begins before termination so deadlines and vendor limits do not control the practice's only recovery path.

Begin before notice

Maintain an exit plan during the relationship. Record contract deadlines, export rights, formats, fees, assistance, retention, deletion, access termination, subprocessors, dispute handling, and contacts. Test available exports periodically. Waiting until termination can leave too little time to correct missing fields, retrieve historical versions, or build a safe continuity workflow.

Inventory vendor-held functions

List source scheduling, recurring series, availability, waitlists, assignments, notifications, calendars, APIs, webhooks, mobile offline data, reports, audit logs, access administration, archives, backups, and support records. Name internal owner, vendor owner, users, integrations, and consequence of loss. Identify any practice procedure that exists only inside the vendor tool.

Inventory data and metadata

For each record class, capture fields, stable IDs, relationships, versions, time semantics, status definitions, attachments, correction history, source and destination links, formats, volume, date range, and sensitivity. Include audit and delivery evidence needed to interpret actions. A flat appointment export without series, versions, or code definitions may preserve rows while losing meaning.

Preserve clinical ownership

The BACB Ethics Code supports continuity, documentation, confidentiality, and qualified accountability for covered people. The exit may transfer clinician-authored evidence while leaving interpretation and correction with qualified roles. Protect access to current safety, health, communication, and supervision information needed for ongoing services.

Plan effective communication

DOJ effective-communication guidance informs suitable aids and services for covered entities. Tell clients, caregivers, and staff about relevant schedule, portal, message, or contact changes through usable channels. Preserve interpreter, relay, alternate-format, and supported communication routes. A technically successful cutover can still disrupt care when people cannot reach or understand the replacement workflow.

Classify security responsibilities

Determine entity, data, vendor, and subprocessor scope. For HIPAA covered entities and business associates, the HHS Security Rule overview frames safeguards for ePHI. Keep access, encryption, transmission, logging, incident response, retention, backup, and deletion controlled through the transition. Contract end should not create an unmonitored gap between systems.

Define the target operating model

Name the replacement source, temporary continuity process, owners, roles, integrations, communication channels, archives, reporting, support, and escalation. Decide which functions migrate, change, pause, or retire. Confirm staff and clinical readiness. Avoid reproducing a defective vendor workflow merely to simplify field mapping. Document intentional differences and user impact.

Build an ID and field crosswalk

Map organization, client, staff, visit, series, service, site, authorization, notification, audit, and external IDs with issuer and scope. Map fields, statuses, time zones, nulls, defaults, and historical definitions. Preserve vendor IDs for reverse lookup. Test collisions and unmatched values. Require an owner for every lossy transformation and unsupported field.

A fictional exit inventory

Aspen Shore ABA identifies 52 required vendor data sets and functions. Forty-four have an accepted export, owner, target, retention decision, and test. Three exports lack version history, two APIs have no replacement, one audit file is unreadable, one subprocessor is unresolved, and one client channel lacks an accessible transition. Exit readiness is 44 of 52, or 84.6%.

Build the exit register

Use exit ID, contract milestones, record or function, owner, vendor contact, source, fields, IDs, format, volume, date range, target, mapping, access, retention, hold, export attempt, validation, dependency, continuity, cutover, communication, deletion, evidence, issue, and closure. Keep all required items in the register, including retired functions and unresolved vendor limitations.

Validate exports

Request early test exports and compare counts, date ranges, relationships, versions, status meanings, special characters, time zones, attachments, logs, and readable formats. Reconcile source totals with files and target imports. Test large and incremental exports. Record extraction time and limits. A successful download does not establish completeness or usability.

Exercise continuity

Simulate vendor unavailability during an active day. Confirm approved rosters, current client-specific safety and communication information, staff assignment, supervision, contact routes, downtime documentation, and change control are available. Define which visits can proceed and who decides. Account for every scheduled event, temporary record, message, and later reconciliation. Avoid improvising a parallel system during the actual cutover.

Migrate in controlled waves

Use a locked cohort with clear source and target versions. Import, validate, and reconcile before expanding. Include active, future, canceled, recurring, corrected, archived, cross-zone, and access-dependent cases. Keep the source read-only where appropriate during final transfer. Set stop conditions for wrong identity, missing history, inaccessible workflow, or unexplained count difference.

Control cutover

Name command, clinical, operations, technical, privacy, vendor, and communication owners. Set final-change deadline, queue treatment, source freeze, export, import, validation, user access, message routing, and rollback or compensating path. Protect changes arriving during the window. Record every manual decision. Keep the old system available only under the approved restricted role and period.

Reconcile every downstream path

Compare target schedules with clinical records, portals, mobile apps, calendars, messages, payroll, billing, reports, archives, and integrations. Match counts and identities, then inspect representative meaning. Resolve duplicates, gaps, stale views, and open work. Communicate current facts. Close migration cohorts only after accepted disposition for every required record and function.

Verify access removal and deletion

After acceptance and applicable holds, remove users, service accounts, API keys, webhooks, calendar grants, support access, and old integrations. Obtain and assess vendor deletion or retention evidence, including subprocessors and backup limits. Preserve contract and verification records. Test that retired credentials and URLs no longer provide access. Keep unresolved copies assigned and protected.

Measure exit completion

Report items due, exported, validated, mapped, migrated, continuity-tested, reconciled, access-removed, deletion-verified, vendor-pending, and unresolved. Track count differences, oldest issue, manual corrections, user support, and post-cutover incidents. Pair percentages with critical gaps. Final acceptance should name limitations and remaining owners rather than relying on a contract termination date.

Transfer open work deliberately

Inventory future visits, pending changes, unresolved conflicts, failed messages, unacknowledged calendar events, incomplete documentation links, authorization holds, vendor tickets, incidents, access requests, and correction queues. Assign each item a source snapshot, owner, target workflow, due date, and accepted disposition. Decide which work will complete in the old system, move to the new system, or remain in a controlled external register. Freeze status changes during the final handoff or reconcile both versions afterward. Tell staff where each work type belongs and prevent duplicate action across tools. Sample items from every queue after cutover and verify their history and next step are usable. Open work often carries more operational risk than static historical rows, so its transfer deserves a separate acceptance decision. Keep the final queue totals and oldest items in the executive cutover record.

Related resources

Sources