Jira and GitHub consolidation across acquired software companies

What breaks when acquired engineering tools are merged?#

Jira and GitHub consolidation after an acquisition most often breaks the connections between records, not the records themselves. Issues still arrive in the new site and repositories still clone, but commit messages point at issue keys that changed, migrated comments lose their authors, and remote links point at a site that is about to be deleted.

Those connections are what make engineering history useful: an issue linked to the commits that fixed it, the pull request where the fix was reviewed and the release it shipped in. A portfolio CTO consolidating several acquired companies is really deciding whether that chain survives the move.

Three consolidation patterns and their link risk#

The three consolidation patterns for acquired engineering tools are federated, grouped and fully merged, and each carries a different risk to the links between issues, commits and reviews. Software groups usually choose by weighing license savings and shared workflows against migration effort.

Jira: keys, users, fields and change history#

Jira migrations hold their value when project keys, user mappings, custom fields and change history survive. Check key collisions first: if two acquired companies both used a key such as OPS, one project must take a new key, and every commit message, branch name and runbook that cites the old keys will point at the wrong issue.

Keep a mapping table of old to new keys, and store the original key in a field on each migrated issue so old references stay searchable. Map departed users to inactive accounts or placeholders instead of dropping their authorship, because who reported, reviewed and resolved an issue is part of what the history shows. List Marketplace apps per site, since test management or time tracking data follows the app vendor's own export route.

CSV is a checking tool, not a history-preserving migration route. Atlassian supports exporting up to 10,000 work items at a time with the asynchronous CSV export in Jira Cloud and recommends batching larger sets, which suits counts and spot checks. Backup and site migration routes are the ones designed to carry comments, attachments and change history; Atlassian Backup and Restore, for example, requires a Premium or Enterprise plan and keeps backups in Atlassian storage for 30 days.

GitHub: organizations, repositories and review history#

GitHub consolidation keeps review history intact when repositories move as whole units with their issues and pull requests, rather than being re-pushed as bare git history. A plain push preserves commits but leaves pull-request reviews, review comments and issue threads behind in the old organization.

Confirm which route your plans support. GitHub documents an export path that builds a migration archive from a GitHub.com organization for import into GitHub Enterprise Server; it requires owner permissions and a token with the repo and admin:org scopes, and locking a repository during migration blocks all writes. Teams moving between GitHub.com organizations should check GitHub's current documentation for their options.

Commit email addresses decide whether old commits still attribute to the right people. Collect every address each company's engineers used, including personal addresses on early commits, and map them before cutover. Where an acquired company used GitLab, note that GitLab says project exports do not include every item, and that after import or export only the latest diff version and latest pipeline in merge requests are visible.

The consolidation checklist, run per acquired company#

The consolidation checklist keeps links testable at each stage. Run it separately for each acquired company rather than once for the whole group, so a problem in one migration does not stall the others.

• 1Inventory sites, projects, repositories, Marketplace apps and integrations.
• 2Take a full backup or export of the source and record counts by project and repository.
• 3Resolve key collisions and build old-to-new mapping tables for keys and repository names.
• 4Map users and commit email addresses, including departed staff, to accounts or placeholders.
• 5Add a source-company field or label to every migrated project and repository.
• 6Freeze writes in the source, migrate, then reconnect the Jira and GitHub integration so development links resolve.
• 7Verify counts, then trace sample issues to their commits, pull requests and reviews.
• 8Keep the source read-only until verification is signed off, then decommission.

Decommissioning starts vendor deletion clocks#

Decommissioning the old Atlassian site or GitHub organization starts vendor deletion clocks, so it belongs at the end of the plan, not at the start of a cost-saving push. Atlassian says that after a cancelled subscription period ends, the site stays accessible for 15 more days and is then deactivated, with data retained for 60 days on Free, Standard, Premium or Enterprise plans before permanent deletion.

On GitHub, organization owners can restore deleted repositories within 90 days of deletion, but restoring does not bring back team permissions, and repositories in an active fork network cannot be restored directly. Treat both windows as emergency recovery, not as an archive plan.

Illustrative: three acquired companies, one engineering home#

Illustrative: a fictional vertical software holding group owns three acquired companies. One uses Jira Cloud and GitHub, one runs a self-managed Jira server with Bitbucket, and one uses GitLab with its built-in issue tracker. The portfolio CTO chooses the grouped pattern: one Jira Cloud site with projects per company and one GitHub enterprise with an organization per company.

Two companies both used the key SUP for support escalations, so one is renamed and each issue keeps its original key in a field. Bitbucket and GitLab repositories move with their pull-request and merge-request history where the tools allow, and the team records which items arrived only partly. Every project and repository carries a source-company label, and the old systems stay read-only until sampled issues trace cleanly to commits and reviews.

When the group later reviews which records could be licensed, it can show for each repository which company wrote it and which agreements apply, because that label survived the move.

Why connected histories matter after consolidation#

Connected engineering histories matter after consolidation because issue threads, commits and code reviews linked to each other show how real software problems were diagnosed and fixed, which is the kind of record AI developers look for when they license engineering work. Disconnected exports of the same material are harder to verify and less useful.

SourceX assesses such records with the SourceX Enterprise Data Value Framework, in which human-generated signal, domain expertise, recency and data cleanliness raise value, while preparation cost lowers net value; a clean consolidation keeps preparation cost down. Rights still follow the acquired entity that created the records, so the source-company label feeds the provenance section of the SourceX Evidence Packet.