Blog · IT & TSA

The institutional memory moves with the team.

TSA Jira and Confluence separation is the work of moving the Newco's projects, spaces, automations, and integrations out of the seller's Atlassian estate into the Newco's own. Engineering, product, and operations teams live inside Jira and Confluence. The Newco's TSA exit strategy has to put the Atlassian estate in the wave order with the same care given to the directory and the source code repositories because the institutional memory of how things were built sits inside ticket history and page archives. The buyer that stages a clean cloud or data center cutover keeps the team productive. The buyer that does not finds engineers searching the seller's old instance for a year.

4 to 8 mo
Typical Migration Window
Projects
Migration Unit
7 min
Read Time
2026
Last Updated
Section 01

What the seller's Atlassian estate actually contains.

An Atlassian estate typically holds Jira projects, Jira Service Management projects, Confluence spaces, Bitbucket repositories, automation rules, custom workflows, custom fields, and a long list of marketplace apps. The seller's instance covers engineering, product, IT operations, security, finance projects, and the documentation that supports each. Some projects and spaces serve only the carved-out business. Others are shared across the seller's retained business and the Newco.

The carve-out has to address each project and space individually. A pure Newco project can be exported, imported into the destination instance, and reconfigured with relative ease. A shared project requires the issues to be split, with custom field history preserved on both sides. Confluence spaces follow the same pattern. A pure Newco space migrates cleanly. A shared space requires the page history to be analysed and split.

A pre-signing inventory of projects, spaces, repositories, marketplace apps, and the team owners on the Newco side is the first deliverable. Without it the cutover wave order is a guess. The pattern overlaps with the broader carve-out application portfolio rationalization playbook because the marketplace apps may not all be needed in the destination.

Section 02

Project history, ticket links, and the audit trail.

Ticket history is the institutional memory. A new engineer joining the Newco needs the prior tickets to understand why a feature behaves the way it does. A compliance officer needs the change ticket history to evidence the SOC 2 control. A product manager needs the historic backlog to track what was deferred and why. The Newco has to migrate ticket history with comments, attachments, status transitions, and link relationships intact.

Atlassian provides a cloud migration assistant for moves into Atlassian Cloud and several specialist tools handle moves into other configurations. The work is mechanical when the source and destination are both Atlassian. The work is heavier when the destination is a different platform such as Linear, Asana, or Azure DevOps. Where the destination is different, the migration trades off completeness against effort. Most Newcos migrate the rolling twelve months of issues fully and freeze the older history in archive on the seller's side.

Issue links are the harder problem. A ticket linked to another ticket inside the migration scope keeps the link. A ticket linked to a ticket outside scope loses the link. The carve-out plan should identify cross scope links in advance and decide which to preserve through manual remap and which to drop with a documented note.

Section 03

Confluence spaces, page history, and links.

Confluence holds the documentation that supports every team. Architecture decisions, runbooks, design specs, meeting notes, policies, and onboarding pages all live in spaces. The Newco has to migrate the relevant spaces with page history intact. The migration tool preserves page version history, attachments, and most macros. Some marketplace macros require a manual reconfiguration on the destination side.

Internal links are the second discipline. A page that links to another page inside the migration scope keeps the link. A page that links to a page outside scope produces a broken link on the destination. The migration plan should sweep cross scope links and either preserve them through external URL rewrites or break them with a documented redirect.

Permissions are the third discipline. A space that was open to all employees on the seller's side may need tighter permissions on the destination. The Newco's information classification policy should drive the permission map and the migration is the right moment to apply it. A space migrated with the seller's permissions and never reviewed is a space that exposes more than the Newco intends.

Section 04

Automations, marketplace apps, and integrations.

Jira automation rules and Confluence automations run the daily operating cadence. A rule may close a ticket if the customer does not respond within a defined window. A rule may notify a Slack channel when a release ticket transitions. A rule may sync a Confluence page when a Jira epic is updated. The Newco has to recreate every relevant rule on the destination instance and validate the trigger and action both fire as expected.

Marketplace apps are the harder problem. The seller's instance may run apps for time tracking, advanced roadmaps, structure plugins, security scanners, and dozens of others. Each app holds configuration that lives partly in the app and partly in the issue or page metadata. The Newco has to install the equivalent app on the destination, configure it, and validate the data carries through. Some apps simply do not migrate cleanly. The Newco may need to choose a different app or accept partial loss.

Integrations to Slack, Microsoft Teams, GitHub, Bitbucket, GitLab, and the seller's own systems all need to be reconfigured at cutover. Each integration holds an authentication that points at the source instance. Each has to be repointed and reauthorised on the destination side.

Section 05

Licensing, cost, and the TSA invoice.

Atlassian products are licensed by user count and product tier. The seller typically holds an enterprise contract that covers the combined business at a discount. During the TSA the seller allocates a share of the user count and the marketplace app cost to the Newco. The allocation methodology needs to be transparent. Buyers that accept an opaque allocation often pay for marketplace apps the Newco never needed.

The Newco's own Atlassian contract or destination collaboration platform is procured during the TSA period. Some Newcos stay on Atlassian Cloud at a tier that matches the user count. Some move to alternatives such as Linear and Notion, Microsoft Loop, or GitHub Issues for tracking and a separate documentation tool. The choice depends on the existing investment in workflows, the integration footprint, and the value creation plan around engineering velocity.

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

Section 06

Closing the migration and the exit.

A clean Atlassian exit closes three records. The seller's instance retains no active Newco projects, no active Newco spaces, and no active integrations into the Newco environment. The Newco's destination instance holds the relevant project history within the agreed retention window and runs every workflow the team depends on. The cutover documentation supports the broader TSA exit certificate.

Open items, typically a small set of legacy spaces or low traffic projects no one currently owns, are tracked under a short post-close services agreement with a hard end date. The seller agrees to provide read access to the archive for a defined period. After that period closes, the archive is exported to a Newco controlled store or deleted, depending on the legal hold and retention policies.

Specialist support across the collaboration workstream is part of the TSA Exit Acceleration service when the milestone is at risk. The work coordinates with the Newco's CIO or head of engineering, the seller's Atlassian administrators, and the project 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 institutional memory moves with the team.
TSA Exit Acceleration

Move the institutional memory before the team forgets.

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 →