Switching CAT Software: A Reporter's Migration Checklist

Switching CAT software feels risky for one reason: your dictionary and your formats are your livelihood, and moving them wrong could cost you a job. The good news is that a methodical migration can be tested before deadline work moves. Here is the checklist.

Signs it is time to evaluate a switch

You do not change tools for fun. You evaluate alternatives when the current one is costing you:

• It crashes, especially in realtime, when a crash is a professional emergency.
• The interface slows down editing you do every single day.
• The cost of the license, upgrades, add-ons, and support no longer matches the value.
• It is missing realtime or delivery features clients now expect.
• Support is slow, or upgrades break your workflow.

If two or more of those are true, it is worth a serious look.

Export your dictionary and briefs safely

Your dictionary is non-negotiable. Before anything:

1. Back up your current dictionaries (main, personal, job, and specialty dictionaries) in your software’s native format.
2. Export to a portable format. RTF/CRE is an industry interchange format for steno dictionaries and jobs¹ (Eclipse vs. Case CATalyst compares what each vendor documents about interchange). Stenograph documents RTF/CRE import and RTF/CRE export, while Advantage’s Eclipse materials cover dictionary work and job production.²
3. Verify the export. Spot-check that outlines, definitions, conflicts, and punctuation came across, not just the word list.
4. Keep your briefs and phrases with the dictionary; they are part of how you write fast.

RTF/CRE supports interchange, but it may not reproduce every system-specific behavior.³¹ Keep native backups even after the converted files pass review.

ANative backup, kept

BRTF/CRE copy, verified

COutlines

DDefinitions

EConflicts

FPunctuation

Ask the vendor you are moving to what conversion help is included. Stenograph’s switching page, for example, says its Training Agents help with keyboard mapping and dictionary and standard page conversions.⁴ Treat any assisted conversion the same way: verify the result against your native backups before deadline work.

Preserve your job and transcript formats

Your transcripts have to keep looking like yours and comply with the rules that apply to the work:

• Page layout, line count, margins, and line numbering
• Title pages, appearances, certificate pages, and your signature or seal
• Indexing, Q&A formatting, and parenthetical styles

Rebuild a couple of standard formats in the new tool and compare them side by side with the old output before you trust it on a real job.

Run both systems before you commit

Do not flip overnight. Run the new software alongside the old for a few non-urgent jobs:

• Write or import a job, edit it to final, and produce every required deliverable.
• Test realtime in a low-stakes setting before you stream it to attorneys.
• Confirm exhibits, audio sync, and backups all behave.

Only switch your deadline work once the new tool has handled representative work reliably.

ASame job, both systems

BNew software, beside the old

CEvery deliverable compared

DDeadline work moves last

The migration checklist

• Back up all dictionaries in native format
• Export dictionaries and briefs to RTF/CRE; verify the export
• Recreate standard transcript formats; compare them side by side
• Import a finished job and reproduce every deliverable
• Test realtime privately
• Run both systems on two or three non-urgent jobs
• Confirm backups and exports work out of the new tool
• Switch deadline work last

Portability is product-specific

A healthy migration path includes native backups, documented exports, and representative conversion tests. It does not depend on a blanket no-lock-in promise.