Blog · IT & TSA

The customer never feels the carve-out at all.

TSA Zendesk support separation is the work of moving the Newco's tickets, queues, agents, and integrations out of the seller's Zendesk instance into the Newco's own. Customer support is the most directly observable side of any carve-out. The Newco's TSA exit strategy has to put Zendesk in the wave order with the same care given to the order to cash flow because every dropped reply is a churned customer waiting to happen. The buyer that stages a clean instance cutover keeps the customer experience continuous. The buyer that does not finds support tickets reopening on the seller's side weeks after Day One.

3 to 6 mo
Typical Migration Window
Tickets
Migration Unit
7 min
Read Time
2026
Last Updated
Section 01

What the seller's Zendesk instance actually contains.

A Zendesk instance contains tickets, end users, organisations, agents, groups, brands, triggers, automations, macros, business rules, knowledge base articles, and a long list of integrations to email, telephony, chat, and the back office. The seller's instance typically holds support history for the combined business across multiple brands. Some brands are clearly Newco. Others belong to the retained business. A meaningful share of tickets reference cross brand customer relationships that the carve-out has to disentangle.

The carve-out has to address each brand and each queue individually. A brand that serves only Newco customers can be exported, imported into the Newco's instance, and stood up under the Newco's account with relative ease. A shared brand requires the customer record to be split. The work has to be planned with the support operations owner because business logic sits inside automations, triggers, and SLA policies in ways that are not always visible from the metadata.

A pre-signing inventory of brands, queues, agents, integrations, and ticket volume is the first deliverable. Without it the cutover wave order is a guess and the support manager has no baseline. The pattern overlaps with the broader Day One customer and vendor communication playbook.

Section 02

Ticket history, customer record, and continuity.

Every customer support relationship lives in the ticket history. A new agent picking up a ticket needs the prior conversation to provide a coherent reply. The Newco has to migrate ticket history to the destination instance or the customer experience drops. Zendesk supports a structured export through the API, and several specialist migration tools handle the bulk transfer. The work is mechanical. The decisions are not.

The first decision is the cutoff. Most Newcos migrate the rolling twelve months of ticket history and leave older tickets in archive. The seller retains read access to the archive for a defined period under the TSA. The second decision is the open ticket disposition. Open tickets at cutover have to be reassigned to a Newco agent on the destination instance with the original requester intact. A reassignment that loses the original requester is a reassignment that breaks the conversation thread.

The customer record itself moves alongside. Every end user in scope, every organisation, and every relationship between them is exported and imported. Where the customer is shared between the seller and the Newco, the carve-out preserves the relationship on both sides with a clear primary contact for each.

Section 03

Triggers, automations, and SLA policies.

Triggers, automations, and macros run the day to day support operation. A trigger reroutes a ticket based on subject. An automation closes the ticket if the customer does not respond. A macro sends a templated reply with the right tone. The seller's instance typically holds dozens or hundreds of these rules built up over years. The Newco has to recreate the relevant ones in the destination instance before the first ticket lands.

Service level agreements are the highest sensitivity item. Customer contracts often promise specific response and resolution times. The destination instance has to enforce the same SLA targets, with the same business hours, the same priority logic, and the same escalation paths. A missed SLA at the start of the new instance produces a service credit claim and a difficult customer conversation. The cutover plan should include SLA validation against a sample of tickets in the parallel running window.

Knowledge base articles move alongside. The Newco's branded help centre has to launch with the relevant articles in place, the right URL pattern, and redirects from the seller's old paths where the Newco controls the domain. The pattern overlaps with the broader Day One customer communications playbook.

Section 04

Integrations to CRM, telephony, and the back office.

Zendesk rarely runs alone. The instance integrates with Salesforce or HubSpot for the customer record, with a telephony platform for inbound calls, with a chat platform for live messaging, with the order management system for status lookups, and with several third-party applications from the marketplace. Each integration holds a configuration that points at the seller's tenant. Each has to be repointed at the Newco's destination on cutover.

The sequencing matters. If the Newco's CRM carve-out completes before the Zendesk cutover, the integration can be reconfigured during parallel running. If the Zendesk cutover completes first, the integration continues pointing at the seller's CRM temporarily and is reconfigured later. Most Newcos prefer the first sequence because it reduces the number of cutovers that affect the same customer record. Telephony is the harder problem because phone numbers carry brand recognition and the porting timeline is set by the carrier, not the Newco.

Email channels are a special case. The Newco's support email address either changes at cutover or persists with redirection. Where the address changes, customer communication has to flag the new address well in advance. Where the address persists, the DNS record has to be updated to route the address into the destination instance.

Section 05

Licensing, cost, and the TSA invoice.

Zendesk is licensed by agent seat and feature tier. The seller typically holds an enterprise contract that covers the combined support organisation at a discount. During the TSA the seller allocates a share of the agent count and the feature cost to the Newco. The allocation methodology needs to be transparent. Buyers that accept an opaque allocation often pay for features they do not use.

The Newco's own Zendesk contract or destination support platform is procured during the TSA period. Some Newcos stay on Zendesk in their own instance. Some move to alternatives such as Freshdesk, Intercom, Salesforce Service Cloud, or HubSpot Service Hub. The choice depends on the existing automation library, the integration requirements, and the value creation plan around customer experience.

When the cutover completes the seller's invoice should drop to zero on the support tooling line. The pattern overlaps with the broader TSA invoice validation process playbook.

Section 06

Closing the migration and the exit.

A clean Zendesk exit closes three records. The seller's instance retains no active Newco tickets, no active Newco brands, and no active integrations into the Newco environment. The Newco's destination instance holds the full ticket history within the agreed retention window and serves every customer with the right SLA. The cutover documentation supports the broader TSA exit certificate.

Open items, typically a small set of tickets that reopen post cutover from older customer threads, are handled under a short post-close services agreement with a hard end date. The seller agrees to forward any reopened ticket to the Newco for a defined period. After that period closes, the seller declines and the customer is directed to the Newco contact channel.

Specialist support across the support workstream is part of the TSA Exit Acceleration service when the milestone is at risk. The work coordinates with the Newco's chief customer officer or head of support, the seller's support operations team, and the integration owners on both sides.

Related Reading

More on vendor and platform separation.

Free Download

Get the buyer-side TSA Exit Playbook.

The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.

No spam. Unsubscribe in one click. · Read the overview first →

The customer never feels the carve-out at all.
TSA Exit Acceleration

Move support cleanly or the customer notices.

Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.

White paper

The TSA Exit Playbook

Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.

Read the playbook →
The Day One Letter

Get buyer-side TSA intelligence every two weeks

One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.

Subscribe to The Day One Letter →
White paper

The Collaboration & Productivity Separation Playbook

Treat the email-domain and tenant split as a project, not a switch. Rushed cutovers lose mail, files and identity links you cannot get back.

Read the playbook →