The Exit Drill: rehearse a support switch every quarter

The Exit Drill: a quarterly, timed rehearsal of exporting your support data and importing it into a credible alternative.

The most expensive moment to discover you are locked into a support platform is the moment after you have decided to leave. Teams that have never tested their exit find that a migration they expected to take two weeks routinely takes two to three months, not because switching is inherently hard, but because every friction point surfaces for the first time at the worst possible moment. The Exit Drill changes the math. A quarterly, timed rehearsal of exporting your data and standing up an alternative turns a three-month emergency into a sub-72-hour execution. The key output is a single KPI, time-to-exit (TTE), which measures your real switching cost and identifies exactly what to fix before the next quarter arrives.

I have been evaluating and implementing support software for over a decade, and the pattern is consistent: the teams that migrate smoothly are the ones who had run the numbers before the decision was forced. They knew their export format. They had tested their integrations. TTE sat on their ops dashboard alongside CSAT and first-contact resolution. The teams that struggled had scored their lock-in risk once, on a spreadsheet, two years before, and never updated it. The Exit Drill is the practice that separates those two outcomes.

What exactly is the Exit Drill?

The Exit Drill is a quarterly, timed rehearsal of switching your support platform. You do three things in sequence and you measure how long each step takes.

First, export everything: tickets from the past 12 months, your full knowledge base, all contacts, macros, canned responses, and SLA configurations. Second, import that export into a free trial of a credible alternative, the realistic backup platform for your team size and use case. Third, record the elapsed time and document every blocker you encountered.

That is the full drill. It takes two to four hours of an operations person's time per quarter. The output is a number, your time-to-exit (TTE) in hours, and a short blockers log that becomes the input to next quarter's preparation work.

The name borrows from a concept in fire safety: EDITH, Exit Drills In The Home. Fire safety agencies like the Sonoma County Fire District promote practiced exit rehearsals on the basis that "from the time a fire starts, you have only 4 minutes to reach safety." The logic translates directly. You do not want the first time you test your evacuation route to be the actual emergency. The same principle applies when a support vendor relationship deteriorates or a pricing change forces the decision. Rehearse before the alarm sounds.

The Forbes Tech Council made this argument precisely in August 2026: exit readiness should function as a reliability objective, not a one-time risk score. A reliability objective implies a target and a regular measurement cycle. The Exit Drill operationalizes both. You set a TTE target appropriate to your team size, measure against it each quarter, and work the blockers list until you hit the target consistently.

The distinction between a one-time risk score and a recurring reliability objective matters operationally. A risk score tells you where you stood on the day you measured it. A reliability objective tells you where you stand today and holds you accountable to the trend. Support teams already apply this logic to uptime, CSAT, and first-contact resolution. Apply it to exit readiness and the same accountability structure follows.

The drill requires no vendor cooperation. You use the self-serve data export that every enterprise platform provides and the free trial that most credible alternatives offer. You do not notify your current vendor. This is intentional: a rehearsal that requires the cooperation of the system you are rehearsing to exit is not measuring real exit readiness.

One scope clarification: the Exit Drill is not a full migration rehearsal. You are not configuring the alternative for production use or training agents on a new interface. You are testing whether your data can move cleanly and quickly. The migration itself, if it comes, will require more work. The drill tells you precisely how much more and where the obstacles are, before you are committed to a timeline.

How to run the Exit Drill in four steps

The drill fits inside a single work session for one operations person. Here is the exact sequence.

Step 1: Export your full dataset. Navigate to your platform's data export or admin panel and request the following, in order of importance: ticket history for the past 12 months including internal notes and attachments; the full knowledge base with category structure and attached media; the complete contact list with custom fields and tags; macros, canned responses, and response templates; and SLA configurations and business hours settings. Note the export format for each category, whether CSV, JSON, XML, or proprietary, and record explicitly what is excluded. Items excluded from the default export are migration costs you will need to price separately.

Step 2: Stand up a free trial. Most enterprise support platforms offer 14-day trials with no credit card required. Freshdesk, Help Scout, Front, and Zoho Desk are all realistic evaluation candidates depending on your team size and use case. Do not configure the trial from scratch. Instead, attempt to import the export from Step 1 using the alternative platform's import tool or API. The import process is the test. Observe which fields map automatically, which require manual mapping, and which fail or disappear entirely.

Step 3: Time everything and log blockers. Start a simple log when you initiate the export request and stop it when the alternative platform has imported data that a support agent could realistically work from. Log every blocker specifically: field mapping failures, knowledge base images that now return 404 because they were hosted on the old platform's CDN, ticket IDs that did not carry over, API credentials that need updating, and any step requiring more than 15 minutes of troubleshooting. Each blocker on this list is a project for the next quarter.

Step 4: Update your TTE estimate and vendor scorecard. Record the TTE alongside the prior quarter's number. A TTE that increased means something changed: a new integration, a platform update that altered the export format, or higher data volume. A TTE that decreased means your prior quarter's preparation work was effective. Update your integration dependency map to reflect anything the drill revealed. Share the TTE and blockers log with whoever negotiates your vendor contracts.

The most common blockers, in order of frequency:

• Proprietary export formats that require vendor-specific tools to read, not standard CSV or JSON parsers
• Knowledge base images stored as blob URLs or hosted on the platform's CDN, inaccessible after an export
• Custom fields that appear in the platform UI but are omitted from the bulk export by default
• Ticket IDs that are platform-internal and do not match any external reference system
• Conversation threads that export as flat files, losing the parent-child reply structure
• Automation rules written in platform-specific syntax with no equivalent import path on the alternative

Each of these is fixable before a migration. None is fixable quickly under deadline pressure. The drill finds them on a Tuesday afternoon in a non-crisis quarter. That is its purpose.

What will make exit readiness harder in the next 12 to 24 months?

Two trends are compounding vendor lock-in in support software, and both are accelerating into 2027.

The first is AI data entanglement. Platforms that train custom AI models on your ticket data to power deflection bots, suggestion engines, or agent-assist features are creating a category of lock-in that a data export alone does not resolve. Your tickets travel with you when you export. Your trained model does not. The custom AI behavior the platform has built from your conversation history, your product vocabulary, and your resolution patterns stays inside the vendor's infrastructure. Rebuilding that model on a new platform requires months of fresh data accumulation and retraining cycles.

I would review the AI data terms in your current contract now. Specifically: does the vendor claim any license over the AI model trained on your data? Does the platform offer a model export alongside the data export? If the answer to the second question is no, your actual TTE for full capability parity is longer than your drill number suggests. Factor that gap into your risk assessment separately from the data portability test.

The second trend is integration depth. Modern support stacks connect the help desk to CRM, billing, product analytics, authentication providers, and workflow automation. Each connection is a thread you will need to cut and re-tie during a migration. Point-to-point integrations, where the help desk is hardcoded as the data source in another system, are the most expensive to unwind. The Exit Drill surfaces these threads while they are still manageable, before a new integration makes the web denser.

Princeton's Responsible AI workshop, held in September 2026, now includes avoiding vendor lock-in as a core setup principle for teams building on AI tools. The framing applies directly to support platforms: the more deeply an AI system is trained on data inside a single vendor's environment, the higher the switching cost for the entire stack, not just the one tool. This concern is not theoretical. Spain's Data Protection Agency reported the first personal data breach caused by an AI agent in September 2026, a signal of how quickly AI-adjacent systems are becoming both more embedded in workflows and more scrutinized by regulators.

A practical implication for the Exit Drill: starting in 2027, a complete exit readiness posture will require two parallel exercises. The first is the standard drill: data portability testing measured in TTE hours. The second is an AI capability gap assessment, a separate exercise that documents which AI behaviors are platform-specific and estimates the ramp time to rebuild them elsewhere. Teams that build both exercises into their quarterly calendar now will be best positioned when the question becomes regulatory rather than purely operational.

Time-to-exit: the KPI your support stack is missing

Time-to-exit (TTE) is the number of hours from "we have decided to switch" to "the alternative is live with full historical data accessible to agents." Most support teams have never calculated it. Here is how I benchmark it by team profile.

The benchmark I use by team size: a support team of 10 to 25 agents handling under 5,000 tickets per month should target a TTE under 72 hours. Teams with 25 to 100 agents or more than four active integrations should target under two weeks. If you are above those thresholds, the drill is not only a readiness exercise; it is a diagnostic pointing to specific technical debt with a cost you can now quantify, as of September 2026.

The negotiation implication is significant and often underused. Vendors know, broadly, how sticky their platform is. A support director who comes to renewal with a documented TTE under 72 hours is negotiating from a fundamentally different position than one who has never measured it. You do not need to announce the number. Your posture in the conversation, the willingness to discuss alternatives without anxiety, the specific questions about export formats and migration assistance SLAs, signals that switching is operationally feasible. Vendors price retention accordingly.

I have observed this pattern directly. A team that ran three consecutive quarterly drills brought their TTE from eleven weeks down to six days. At renewal, they asked for a 20 percent price reduction and received 14 percent, with an added migration assistance clause written into the new contract. They did not threaten to leave. They simply demonstrated, through the questions they asked and the contract language they knew to request, that the switching cost was manageable. That leverage came entirely from the drill practice.

TTE should be reported quarterly in the same rhythm as the drill that produces it. Treat a rising TTE as a leading indicator: something changed in the platform or integration stack that is increasing your switching cost, and you want to identify it before the trend becomes a migration emergency. For teams that want to cross-reference lock-in risk more broadly, the lock-in risk scoring framework provides a complementary 0-to-100 assessment covering contract terms, data portability, and integration depth. TTE is one empirical input to that score, and the drill gives you the data to make the portability dimension accurate.