Migrations go wrong before they start. The failures that surface mid-move (a field with nowhere to land, an owner nobody mapped, a count that will not reconcile) were all discoverable weeks earlier, for the price of a checklist.
This is that checklist. It is tool-agnostic and it costs nothing but time. Work through it before any data moves, whether you run the migration yourself or pay someone to run it for you. Every item produces something written down, because an undocumented decision is indistinguishable from an accident three months later.
Part one: the inventory
You are establishing what exists, so you can later prove what arrived.
1. List every source system. Not just the main tool. The spreadsheet that grew into a database, the shared document holding client contacts, the folder of exports from the system before this one. Migrations get quoted, scoped, and planned per source, and a source discovered mid-project reopens all three.
2. Count every object type in every source. Projects, tickets, tasks, contacts, records: whatever each system calls them, get a number for each. These counts are the other half of your final verification. Without them, "did everything arrive" has no answer.
3. Take a field census. For each object type, list the fields, including custom ones, and mark which are actually populated. Two lists come out of this: fields that must survive, and fields nobody will miss. Both lists need an owner's signature, because "nobody will miss it" is a claim someone should have to put their name on.
4. Count attachments and comments. Records travel more easily than the files and discussion attached to them. Know before you start whether your export includes them, and how many there are, so their absence is a finding rather than a surprise.
5. List every person in the data. Every name that appears as an owner, assignee, or author, including people who left the company. Departed people own live records more often than anyone expects.
6. List everything that reads from the source. Automations, integrations, scheduled reports, saved views, bookmarks in other documents. Each one breaks at cutover. The list becomes the rewiring plan.
Part two: the decisions
Each of these is cheap to decide now and expensive to decide mid-import.
7. Decide what moves, per object type. Live work moves. Reference history is a choice: move it, or keep it readable where it is, or keep it as flat exports. Write the ruling down per object type, with the cutoff date where one applies. History depth is also the single biggest driver of migration effort, so this decision sets the size of everything that follows.
8. Decide the destination's conventions first. Naming, statuses, and structure in the new system, settled before mapping starts. Migrating into an unconfigured workspace means doing the configuration twice.
9. Rule on every unmappable field. Anything in the field census with no destination gets an explicit ruling: dropped with a stated reason, or carried into a notes field. No default behaviour, whatever tool is involved, gets to make this call.
10. Rule on departed people. Their work is reassigned to someone specific, or lands on a named house account. It never maps to nobody, because unowned records disappear from every filtered view at once.
11. Decide who performs the migration. Your team with the destination's importers, a contractor, or the destination vendor as a service. The honest basis for the decision: whose hours it consumes, and who is best placed to make the mapping calls when the data is ambiguous. We sell the vendor-run option, so read our advice here knowing that: ROIkeep's done-for-you migration works from exactly the artifacts this checklist produces, and free self-serve importers exist on every plan for teams that keep the work in-house. Whoever you choose, items 1 through 10 are yours either way. Nobody can inventory your data's meaning for you.
12. Set the freeze. The moment after which nobody writes to the source. Export and freeze happen together; anything written after the export will not arrive in the destination. Announce the date, and decide now who has authority to slip it.
Part three: the acceptance checks
Write these before the migration, not after. A check written afterwards tends to describe whatever happened.
13. Write the count reconciliation. For each object type: the source count from item 2, minus the records excluded by item 7, equals the destination count. Any other arithmetic is a defect to be explained before sign-off.
14. Pick the spot-check records now. Choose ten to twenty specific records per source now, while the data is still familiar: the oldest, the largest, the most commented, one with attachments, one owned by someone who left. After the import, each is compared field by field against the source.
15. Define done. Who signs off, and against what: the counts reconcile, the spot checks pass, the people all resolve to real accounts, the item 6 list is rewired. Until that person signs, the old system stays readable and nothing gets retired.
Part four: the schedule
16. Sequence the sources. One source at a time, smallest or cleanest first. The first source teaches you the process; better to learn on the small one.
17. Schedule a pilot. Before the real import, a small representative slice into a disposable test workspace, checked against the mapping rulings. If the import path shows a preview of what will be created before anything is written, the pilot is where you learn to read it.
18. Set the cutover and retirement dates. The team switches on an announced date. The source stays readable, and read-only, until the acceptance checks have passed and a full working cycle has run in the new system. Two writable systems at once means two diverging sources of truth, so the freeze from item 12 holds until retirement.
The two items teams skip
Eighteen items invite triage, so name the two that get skipped most and cost the most.
The field census (item 3). Counting objects feels like progress; listing fields feels like bureaucracy. But object counts only prove that records arrived. The census is what proves the records arrived whole, because unmapped fields are dropped silently, per record, with the count still reconciling perfectly. Almost every migration complaint that starts with "it all transferred, but..." traces to a skipped field census.
Acceptance checks written in advance (items 13 to 15). Written afterwards, checks describe whatever happened, and sign-off becomes a mood instead of a measurement. Ten minutes of writing them down before the move converts "does this seem right" into arithmetic.
If you can only do half this list, do these two and the counts. They are the difference between discovering problems during verification and discovering them during work.
What the finished checklist gives you
Eighteen items, and most are an hour or less. Done honestly, you now hold:
- A source list with counts, so arrival can be proven.
- A field census with survival rulings, so nothing is dropped by surprise.
- A people map with no unowned work.
- Acceptance checks written before anyone has an interest in their outcome.
- A schedule with a freeze, a pilot, and a defined finish line.
That stack of documents is the migration, minus the mechanical part. It is also exactly what any competent migration service will ask you for, and what any quote worth trusting is based on. Whether the import itself is run by your team or by a vendor, the team that shows up with this checklist finished gets a faster move, a cleaner quote, and a verification step that ends in signatures instead of arguments.