Direct answer
Move the history people actually use. Contacts, companies and open deals are the core of a CRM migration; the years of notes, emails, calls and files attached to them are where the difficulty and the doubt live. The practical approach is to decide which history earns a place in the new system, migrate that with its owner and date intact, and keep the rest reachable in an archive. What can be migrated depends on what the old system exports and what the new one accepts, and we do not claim full-fidelity migration from every source. This page is a guide to the decisions. For the wider process see CRM migration, CRM data mapping for migration and the CRM migration checklist.
What history is worth moving
Ask the people who use the records. A rep reading an account before a call wants recent context and key decisions, not every automated email sent years ago. Useful questions:
- Would someone open this item to prepare for a conversation?
- Does it record a decision, an agreement or a commitment?
- Is it needed for a legal, contractual or financial reason, according to your own advisers?
- Is it attached to an open deal or an active customer?
- Could it be found in the archive if needed, without living in the new system?
Notes, emails, calls and tasks
Each activity type behaves differently. Notes are usually text and travel well. Emails may be stored inside the CRM, synced from a mailbox or linked to one, and how they migrate depends on which. Call records may be a log entry with no recording. Tasks matter mainly when open, since completed tasks are seldom read again. Decide per type what to keep, whether to bring in open items only, and how each arrives in the new system: as a native activity, a note containing the text, or a linked file.
Keeping owner and dates
A note that loses its author and date loses much of its value, since people judge history by who wrote it and when. Check whether the new system lets you set the original author and creation date on imported items, or whether everything will appear as created by the import on the day it ran. If the original values cannot be set, decide where they will be kept, for example as a line at the start of the note. Former employees need a valid record in the new system, or their items need a defined placeholder.
Attachments and files
Files add size, cost and risk. Find out where attachments are stored today, whether they can be exported with their link to the record, and how the new system stores them. Options include importing files into the new CRM, moving them to shared storage with a link on the record, or leaving them in the old location. Check file types and size limits on the target, and how you will confirm that a file opens after transfer. Treat sensitive documents with the same care as in the source system, and involve whoever owns that data.
Archive as an alternative
Not all history needs to live in the new CRM. An archive, such as a full export from the old system kept in readable form, can hold what is rarely needed, with a note in the new record saying where to look. This keeps the new system clean and faster to use, and reduces migration risk. The trade-off is that archived history is not searchable alongside live data, so the archive should be indexed by company or contact name and owned by someone. Decide how long the old system stays accessible and who pays for it.
Platform limits
Both systems set limits. The source may export only some object types, cap volumes or leave out inline images and linked files. The target may restrict which fields are writable on import, how activities are attached or how large files can be. These limits differ by product and plan and change over time, so we do not list any here. Check them for your specific pair of systems at the start, because they decide whether a full move is possible or whether part of the history must go to an archive.
Test and sign-off
Test history migration on a small sample first, then have users who know the accounts inspect it: are the notes readable, are the dates and authors right, do the files open and are they on the correct record? Fix mapping rules and rerun before the full load. Agree acceptance in advance, for example that named people have checked a defined list of accounts. Keep the original export untouched so any step can be repeated.
What stays behind
Decide explicitly what will not move and record it: older activity, duplicates, unusable attachments, system-generated noise. Tell the team where it can be found and for how long. Being clear about what stays behind prevents surprise on the first day and is a normal outcome of a sensible migration, not a failure. LATYNEX is a remote English-language vendor; we agree one scope and one price in writing, and for one CRM and one main pipeline the CRM Cleanup & Sales Workflow Setup package (€1,990, fixed scope) may fit, with history-heavy or multi-system moves scoped separately.
Questions
Do we have to migrate all our old notes and emails?+
No. Most teams get more value from moving recent and decision-relevant history and keeping the rest in a searchable archive. Decide with the people who use the records.
Will imported notes keep their original author and date?+
It depends on what the target system allows on import. Check early, and if the originals cannot be set, record them in the text of the note.
Can every attachment be moved?+
Not always. Export options, file types and size limits differ between systems, so confirm the limits for your pair of systems and plan an alternative for files that cannot move.
Is an archive a sensible alternative?+
Often yes. It keeps the new CRM lean while preserving access. It should be indexed, owned and kept for an agreed period.
How do we check that history migrated correctly?+
Trial a sample, have account owners review it against the source, and sign off on a named set of records before the full load.