Every team that changes systems meets the same problem. Years of projects, tickets, and records live in the old tool, and the new one starts empty. The move between the two is where data disappears.
It rarely disappears all at once. It goes quietly, one unmapped field at a time, and the loss surfaces weeks later when someone looks for a comment thread that did not make the trip.
This guide is tool-agnostic. The steps are the same whether your work lives in a board tool, a ticket system, or a folder of spreadsheets. Follow them in order and nothing is lost by surprise. Things may still be left behind, but only because you decided to leave them.
Data is lost in the mapping, not the transfer
Export files rarely vanish. What kills data is the gap between what the old system stored and what the new system accepts. The common failure points:
- Fields that exist in the source but not the destination. A custom field with three years of values has nowhere to land, so the import silently drops it.
- Values that exist in both systems but mean different things. The source has five ticket states, the destination has three. Someone must decide where the other two go.
- Attachments and comments. Many exports include the record but not the files and discussion attached to it. The record arrives looking complete, and is not.
- People. Records carry assignee names. If those names do not resolve to real accounts in the destination, the work arrives unowned.
- Time. Some imports stamp every record with the import date. Created dates, closed dates, and the order of events are data too.
Every step below exists to close one of these gaps before it opens.
Inventory the source before exporting anything
Do not start with the export button. Start with a list of what the old system actually holds. For each type of object (projects, tickets, contacts, documents, whatever your system calls them), record:
- How many there are. You will check this number again at the end.
- Which fields are populated, including custom fields. A field nobody filled in can be dropped without ceremony. A field with three years of values cannot.
- Whether records carry attachments or comment threads, and roughly how many.
- Which people appear as owners or assignees, including people who have left.
- What reads from the system: automations, integrations, reports, saved views. These break at cutover and need their own list.
This takes an afternoon and it is the highest-value afternoon of the whole project. You cannot verify what you never counted.
Decide what moves, per object type
Not everything should make the trip. Live work must move. A ticket closed four years ago is a different question: it has reference value, but every record you migrate adds mapping work and verification work.
Decide per object type, and write the decision down:
- Moves in full. Open work, active projects, current contacts.
- Moves in part. Closed work back to a chosen date, if your team genuinely searches it.
- Stays behind, readable. Old history you keep as flat exports, or in the old system's read-only state if it offers one.
The written list of decisions matters as much as the decisions. It becomes your verification plan, and it is the difference between "we chose not to move that" and "where did that go".
Map fields before you move records
For each object type that moves, build a mapping table with three columns: the source field, the destination field, and the rule that converts one to the other. Most rows are trivial. The value of the table is the rows that are not:
- Status values. List every state the source uses and the destination state each one becomes. Do not let an import tool decide this by default.
- People. List every name that appears in the data and the destination account it maps to. Decide now what happens to work owned by people who have left: reassign it, or land it on a named house account, but never let it map to nobody.
- Fields with no destination. Each one gets an explicit ruling: dropped with a reason, or carried into a notes field so the value survives even if the structure does not.
A field dropped by decision is housekeeping. A field dropped by surprise is data loss. The mapping table is what separates the two.
Preview before anything is written
Never run a first import against a live workspace and hope. Before anything is written, you want to see exactly what will be created, what will be skipped, and why.
Good import tooling shows this as a preview: the full list of what the import will do, reviewable before it does it. If your import path offers a preview, read all of it, not the first page. The skipped items and their reasons are the most informative part.
If there is no preview, build one manually: run the import into a disposable test workspace first, using a small representative slice of the data. Pick the slice deliberately. Include your oldest records, your largest ones, and the ones with the most attachments, because edge cases live at the edges.
Only after the preview or pilot matches your mapping table does the real import run.
Verify with counts, then with spot checks
After the import, verification has two layers, and you need both.
Counts first. For each object type, compare the destination count against the inventory you took at the start. The numbers either match or they differ by exactly the records you decided to leave behind. Any other difference is a defect, and now is when you find it.
Then spot checks. Counts prove volume, not fidelity. Open individual records and compare them field by field against the source: the oldest record, the most recently updated one, one with a long comment thread, one with attachments, one owned by a departed team member. Ten well-chosen records catch more than a hundred random ones.
Check the people especially. Every assignee should resolve to a real account, and the work of people who left should sit exactly where your mapping table said it would.
Cut over deliberately
The move itself needs a schedule, announced in advance:
- Freeze the source. Pick a moment after which nobody writes to the old system. Anything written after the export will not be in the destination, so the freeze and the export happen together.
- Import and verify against the frozen state, as above.
- Switch the team on an announced date, with the old system left readable.
- Retire the source only after a full working cycle in the new system, when a week or a month of real use has passed without anyone needing the old system.
The single most common cutover mistake is running both systems as writable at once "during the transition". Two writable systems means two diverging sources of truth, and reconciling them later is a second migration. One system is current at any given moment. The other is read-only.
Who does the work
There are three honest answers, and the right one depends on whose hours are cheapest and where the judgement calls should land.
Your own team, using the destination's importers. Cheapest in cash, most expensive in your time, and every mapping decision above is yours to make and verify.
A contractor who has done it before. Faster hands, but the mapping decisions still need someone who knows what the data means.
The destination vendor, as a service. The vendor knows their own import path best; you still own the inventory and the acceptance checks.
We are in the third category, so weigh this paragraph accordingly. ROIkeep offers a done-for-you migration: you send what you have (spreadsheets, board exports, ticket history), we study it, quote the job, run the mapping, and hand back a running system, with previews before anything is written. Free self-serve importers exist on every plan for teams that would rather do it themselves.
Whoever runs it, hold them to the standard in this guide: an inventory before the export, a mapping table you have approved, a preview before anything is written, a stated list of what will not carry over, and counts that reconcile at the end. A migration run that way loses nothing you did not choose to leave.