Splitting Jira, Zendesk and Slack history when you sell a product line

Start with a product scope, not a tool list#

A product-line split starts with a written scope of what belongs to the product being sold. Without one, each tool admin draws their own line, and the buyer receives a Jira project from one definition and a Zendesk brand from another.

The scope names customers, code repositories, teams and a cutoff date. It then becomes the test for every item in Jira, Zendesk and Slack: does it belong to the sold product, to the retained business, or to both? Items in the third bucket are where splits go wrong, so list them early and resolve each one in the purchase agreement.

Jira: projects, shared epics and export limits#

Jira splits cleanly when the product had its own projects and messily when teams shared them. List every project, board, filter and automation tied to the product, then find issues in shared projects by the components, labels or fix versions that identify the sold product.

Export routes depend on volume. Atlassian supports exporting up to 10,000 work items at a time through asynchronous CSV export and advises breaking larger sets into JQL batches, such as one batch per date range. Jira Cloud's backup manager keeps only one backup file at a time and captures the whole site, so it rarely suits a partial handover.

Agree how cross-project links, attachments and user accounts will be handled. Issues linked to retained projects lose context in the buyer's copy unless the linked summaries are exported with them.

Zendesk: brands, groups and multi-brand tickets#

Zendesk splits most easily when the product ran as its own brand, with its own help center, groups and macros. Tickets can then be selected by brand; where a brand was shared, use the organization, a product field or tags to decide ownership, and flag tickets that touched both products.

Check export access before the deal timeline is fixed. Zendesk's account export tools are not available on Team plans, though every plan can export through the REST API, and exports must be enabled by contacting Zendesk support. For accounts with more than 200,000 tickets, Zendesk recommends JSON export.

Help center articles, macros, triggers and SLA policies are product knowledge, not just configuration. Include them in the scope so the buyer's support team does not start from an empty account.

Slack: channels, DMs and API terms#

Slack history splits by channel, and the product's own channels are usually easy to find; the hard part is decisions made in company-wide channels and direct messages. Owners and admins on every Slack plan can export public channels, while exports that include private channels and DMs require Business+ or Enterprise and an application by an owner.

Exports by conversation type or by member are listed only for Enterprise, and an export contains links to files rather than the files themselves, so plan a separate file retrieval if attachments matter. Read Slack's API terms before hiring a third-party migration tool: they bar outside applications from bulk exporting message and file data unless an additional agreement allows it.

Per-tool split checklist#

A per-tool split checklist turns the product scope into concrete objects in each system. Use it in the working sessions between the seller's admins and the buyer's integration lead.

Decision rules for shared items#

Shared items need a default rule so the working team is not renegotiating each epic, ticket and channel. Agree the defaults in the purchase agreement or its data schedule, then handle exceptions one by one.

Transition services and the archive question#

A transition services agreement often keeps the buyer on the seller's tools for a period after closing. That buys time, but it also means the seller's admins can see the buyer's live data, so the agreement should state who can see what and when access ends.

Both sides usually keep a read-only archive of shared history. The seller needs it for legal holds, warranty claims and tax questions; the buyer needs the history behind the product it bought. The purchase agreement should say who may use each archive and for what, including whether either side may license it later.

When a split archive is later considered for licensing, SourceX starts the Rights step of the SourceX five-step transaction with one question: which side holds the right to each record under the purchase agreement? Only that side can approve a package, and the SourceX Evidence Packet records the chain of title along with the privacy record.

• 1Freeze the scope and the list of shared items.
• 2Export the buyer's copy and reconcile record counts against the source.
• 3Export the seller's archive of shared items.
• 4Move users and remove cross-access at the end of the transition period.
• 5Record what was split, how, and where each archive lives.

Illustrative: a fleet maintenance module sold to a vertical acquirer#

Illustrative: a fictional B2B software company sells its fleet maintenance module to a vertical software acquirer. The module shared one Jira site, one Zendesk account with two brands and a single Slack workspace with the core product.

The CTO's team defines the scope by customer list and repository. Jira issues are selected by component and exported in date-range batches; tickets on the module's brand go to the buyer, and multi-brand tickets go to both sides as copies. The module's Slack channels are exported, and decisions found in general channels are summarized in a handover document rather than copied wholesale.

At the end of the transition period, cross-access is removed. Each company keeps an archive of the shared history, and the purchase agreement records that either may use its archive internally and, after a rights review, for licensing.