Test Management Tool Migration Plan: Keep the History

Migrations don't stall on the export

Getting the data out is the easy part. Every test tool exports to CSV, and the file lands in minutes. Yet test-tool migrations routinely drag on for a quarter, and it's almost never the export that stalled them.

They stall in the middle, for a boring reason. The run history, the attachments, and the custom fields didn't survive the CSV. Nobody decided in advance what to do about that. So the team keeps the old tool running "just until we sort out the history," the new tool fills up in parallel, and six months later you're paying for two systems and trusting neither.

The fix isn't a cleverer exporter. It's a decision made before you export anything: what are you willing to lose, and what has to survive? Answer that first and a migration is a fortnight of focused work. Skip it and you get the quarter-long saga. This is the plan for the fortnight version.

What a CSV carries — and silently drops

A CSV is a flat grid: rows and columns, text only. It carries the parts of a test case that fit that shape — title, steps, expected result, priority — and it carries them well. The trouble is everything that doesn't fit a grid, which it drops without a word of warning.

• Run history. A CSV has nowhere to put "this case ran forty times over two years with these results." The execution record — the thing that shows a test actually ran against what shipped — simply isn't in the file.
• Attachments. Screenshots, logs, and files aren't text, so they don't travel in a text export.
• Custom fields that don't line up with a column you mapped.
• Hierarchy. Folders and suites flatten into a list.
• Links. The relationships from case to requirement and case to defect — the traceability — don't survive as links.

The dangerous word there is "silently." The export succeeds, the cases show up in the new tool, and everything looks fine. The losses only surface months later, when someone asks for run history that no longer exists or a requirement link that's now a dead reference.

Decide first: which history do you actually need?

Before you export a single row, answer one question for each of those dropped things: do you need it live in the new tool, or do you just need to be able to read it somewhere?

That distinction saves migrations. Take run history — the honest answer for most teams is that you don't need two years of old executions live in the new system. You need them readable for a while, in case an audit or an investigation asks. And "readable" has a much cheaper answer than "migrated": keep the old system in read-only mode, or hold an exported archive, and point people there for history.

So decide per data type, deliberately. Cases: migrate them, they're the working asset. Run history: usually archive read-only rather than force it through a CSV that can't hold it. Attachments: migrate the ones tied to active cases, archive the rest. Links: rebuild the ones that matter, let the stale ones go. Making these calls up front is the entire difference between a clean cutover and a stall.

Field and status mapping

Map every field and every status from the old tool to the new one before you import — on paper, as a table. This is dull and it is the step that prevents the worst slow-motion damage.

The classic trap is an unmapped status. Say the old tool had a "Blocked" status and the new one doesn't. If you haven't decided where "Blocked" goes, those cases arrive with an empty or wrong status — and nobody notices, because the import "worked." Months later a release report is subtly wrong, or a filter misses a batch of cases, and you trace it back to a status that never had a home.

The same applies to priorities and every custom field. Build a mapping table: each source value maps to a target value, or to an explicit, written decision to drop it. No silent defaults, no "it'll probably be fine." A value you didn't map is a data-quality bug you've scheduled for six months from now.

Migration is a chance to delete

A migration is the one moment the whole team is looking at the entire suite at once. That makes it the best opportunity you'll ever get to delete — and the easiest one to waste by carrying everything over wholesale.

Moving the whole suite feels safe and is the worse choice. You pay to transport the dead weight — the duplicates, the tests for features that no longer exist, the permanently flaky ones nobody trusts — and then you maintain that junk in a shiny new tool. The mess didn't get cleaner; it just changed address.

Prune before or during the import. Drop the duplicates and the dead cases. Leave behind the tests you don't trust. The best-migrated suite is smaller than the one you started with, and the new tool is the cleanest it will ever be on day one — so don't fill it with things you'd have deleted anyway.

The parallel-running period

You will run both systems for a while, and that's correct, not a failure. The parallel period exists to do two things: verify the migration is complete and correct, and keep the old history reachable while people adjust. The danger isn't running in parallel. It's running in parallel with no end.

Give it a date. Decide, before you start, when the new tool becomes the single source of truth and the old one goes read-only. That date is what turns "parallel" into a transition instead of a permanent state.

Without it, the failure mode is predictable. Both systems stay live, people update whichever is in front of them, and your record splits across two tools — each half-right, neither trustworthy. A migration with no cutover date isn't a migration; it's the permanent acquisition of a second tool. Set the end date first, and let everything else work backward from it.

A sequenced checklist

Here's the whole plan in order — a test case migration checklist a lead can actually run:

1. Decide what you're willing to lose. For history, attachments, and links, choose per type: migrate, archive read-only, or drop.
2. Prune the source suite. Delete duplicates, dead cases, and untrusted tests before anything is exported.
3. Build the mapping table. Every field and status, source to target, with no silent defaults.
4. Do a sample first. Export a small batch, import it, and check it end to end before touching the full set.
5. Run the full import. Verify the counts match and spot-check a range of cases.
6. Archive the old system read-only for the history you chose to keep reachable.
7. Run parallel for a fixed, short window — with the cutover date you already set.
8. Cut over and decommission. The new tool becomes the source of truth; the old one is archived on the date you named.

Where a tool can honestly help

On the mechanics, Tesbo imports cases from CSV and from TestRail, which covers the case data in step five, and every imported case runs through the same review that governs the record — so a person accepts what enters the new suite rather than trusting the import blindly.

Be clear-eyed about the rest, though. No tool magics your run history across a CSV that can't carry it, so plan the read-only archive regardless of where you're moving. Migration is never fully lossless or fully automatic, and any vendor who tells you otherwise is skipping the part you'll feel in month three. Tesbo manages and drafts the cases; it doesn't run your tests, and it won't invent history the export didn't include.

The fortnight version

The migrations that take a quarter are the ones that discovered the losses halfway through — mid-import, with half the team already working in the new tool and the old run history stranded. The migrations that take a fortnight decided the losses up front, mapped every field, pruned the junk, and named a cutover date before exporting a single row.

The export was never the hard part. The decision was. Make it first, write it down, and the rest is just careful execution against a checklist.