Old SVN, Perforce or TFVC history: is it worth converting?

When is legacy version control history worth converting?#

Legacy version control history is worth converting when it answers questions people still ask: why a module behaves the way it does, who wrote a disputed component, or what changed before a customer incident. It is also worth converting if the company may license engineering records, because commit history with real messages is part of what makes code records useful to AI developers.

If the old code is fully retired and nobody needs its history, a verified, read-only dump of the original repository is cheaper and safer than a conversion. The worst option is the common one: a tip-only import into Git followed by decommissioning the old server.

What old history contains that a snapshot does not#

Old history contains the sequence of decisions behind the code: commit messages explaining intent, authorship, the order of changes, branch and merge points, and references to bug IDs from trackers that may also have been retired. A snapshot keeps the result and drops every one of those.

In TFVC, changesets are often linked to work items in Azure DevOps Server or Team Foundation Server, and Perforce teams may keep review records in a separate review tool. Inventory those links before conversion, because the converted repository will not carry them unless you add references on purpose.

Old history also settles ownership questions. When an acquirer, an investor or a licensee asks who wrote a component and when, the original commits with real authors are the evidence; a snapshot dated on migration day says nothing about origin.

Conversion steps that keep authors, dates and messages#

Conversion steps that preserve history follow the same pattern for SVN, Perforce and TFVC, even though the tools differ. Common open-source choices include git svn and svn2git for Subversion, git-p4 for Perforce, and git-tfs for TFVC.

Some built-in or hosted import paths bring over only recent history or only one branch, so confirm what a tool keeps on a small test repository before running it on the main one. Record the tool, its version and every option used, because a reviewer may later need to reproduce or explain the result.

• 1Inventory every repository, depot or collection, with its layout and size.
• 2Freeze commits and take a verified backup or dump of the original.
• 3Build an author map from every username to a real name and email, including departed staff.
• 4Map the layout: trunk, branches and tags in SVN; depot paths and streams in Perforce; branch folders in TFVC.
• 5Run the conversion with the original revision or changelist number written into each commit message.
• 6Move large binaries to Git LFS or exclude them, and record what was excluded.
• 7Validate: compare revision and commit counts, spot-check authors and dates, and diff the final tree against the original tip.
• 8Keep the original dump read-only and save the conversion settings beside it.

Problems that break a conversion#

Problems that break conversions usually come from how the old repository was used rather than from the tool. Non-standard SVN layouts, branches created by copying subfolders, Perforce integrations between unrelated paths and TFVC branches created partway through history all confuse automated mapping.

Shared accounts are the other common issue. If a build user or a generic team login made commits, the author map cannot assign them to a person, so record them as a named service account rather than guessing.

Encoding and line-ending differences cause quieter damage. Old commit messages in legacy character sets, or files whose line endings changed between platforms, can make validation diffs noisy, so settle the rules before the full run.

Checks before history leaves engineering#

Checks before history leaves engineering focus on what years of commits can hide: credentials, third-party code, customer-specific work and personal data in test fixtures. Run them on the full converted history, not just the latest tree, because a password removed years ago is still in every earlier commit.

• 1Secret scanning across every commit, not only the current tree; if you use Gitleaks, note that its maintainer has declared it feature complete, with security patches only from here on.
• 2TruffleHog covers Git history as well and can test whether a credential still works by logging in with it, which needs care when the target systems belong to others.
• 3Third-party and vendored code, including licensed SDKs that cannot be redistributed.
• 4Branches or folders written for a specific customer under a services agreement.
• 5Contractor contributions without signed IP assignments.
• 6Real customer or employee data copied into fixtures or sample files.

Illustrative: a warehouse software vendor retires its Perforce server#

Illustrative: a fictional warehouse management software vendor moved to GitHub years ago with a tip-only import. The old Perforce server still runs on a virtual machine that IT wants to retire, and only one senior engineer remembers how to log in.

The CTO chooses a full conversion of the main depot and release branches. The team builds an author map from Perforce user records and old staff lists, writes changelist numbers into commit messages, and stores the result as an archived repository beside the current one.

A secret scan finds old database passwords, which are confirmed rotated and recorded, and a vendored barcode SDK is flagged for exclusion. The Perforce checkpoint is kept read-only, and the converted history is added to the company's data inventory.

How SourceX evaluates legacy version control history#

SourceX evaluates legacy history with the SourceX Enterprise Data Value Framework. Human-generated signal and domain expertise rise when commit messages explain intent and reference issues, data cleanliness rises with a reliable author map, recency is lower for old history, and rights depend on who owns each contribution.

The first look relies on descriptions of the repositories, not the code itself. If converted history moves into a package, the provenance section of the SourceX Evidence Packet records the conversion steps and exclusions, so a buyer can see how the Git history relates to the original system.