Getting your existing data in is the path with the most rework in it, and almost all of that rework comes from doing it in the wrong order.
The order
1. Decide your structure first. Hubs, pipelines, departments. Importing before this means importing again.
2. Add custom fields for what does not fit. See Custom fields.
3. Import a sample. Twenty records, not twenty thousand.
4. Check the sample properly.
5. Import the rest. See Importing spreadsheets.
6. Clean up what arrived. See Data management.
Where to start
Coming from another CRM, read Migrating from another CRM first. It covers what maps across and what does not.
Coming from spreadsheets, read Importing spreadsheets.
Connecting a live system, see Apps and import.
Decide what not to bring
The most valuable half hour in this whole path, and the one everybody skips.
Dead records are not history, they are noise. A contact nobody has spoken to in four years does not become useful by being imported. It makes search worse, reporting worse, and every list longer.
Bring what you will act on. Then, if you must, archive the rest somewhere outside the product where it can be consulted and does not have to be maintained.
Duplicates multiply. Two overlapping exports produce a database where every fifth company exists twice, and cleaning that afterwards costs more than deduplicating the spreadsheet beforehand.
Agree what a duplicate is
Before deduplicating anything, agree the rule, because two people cleaning the same data with different rules produce a worse result than one person with a bad rule.
Same email is usually decisive. Same company name usually is not, because subsidiaries and branches legitimately share one. Same phone number is somewhere in between.
Write the rule down and apply it once. See Data management.
Custom fields, in moderation
Fields for things your business tracks that the standard record does not.
Add them before importing, or the data has nowhere to land and you import twice. See Custom fields.
Add as few as you can. Every custom field appears on every record forever, and a form with forty fields is a form people fill in badly. The test: will somebody filter or report on this? If not, it is a note, not a field.
Do not recreate what already exists. Owner, stage, value, dates and status are standard. A custom "Status" field beside the real one is the most common import mistake there is.
Import the sample first
Twenty records. Every time.
Then look at them as a user would. Open three. Is the owner right, does the value show in the right currency, did the dates survive, is the text in the field it belongs in?
Check one deliberately awkward record. The one with an apostrophe in the name, the one with no email, the one with an amount in another currency. Those three reveal nearly every mapping problem.
Fixing a mapping after twenty records is a minute. After twenty thousand, it is a deletion and a reimport, and by then somebody has already edited a few by hand.
One object at a time, end to end
Import companies, check them, clean them, and only then start contacts. Running three imports in parallel means three sets of problems arriving at once and no way to tell which import caused what.
Keep the file
The source spreadsheet, exactly as imported, kept somewhere findable.
When something looks wrong in three months, the only way to tell whether it arrived wrong or was edited afterwards is to compare against what was imported. Without the file, that question has no answer and the investigation stops.
Common failures
Dates. Day-month against month-day is the single most common import error, and it is silent: everything looks fine until March.
Currency. Amounts imported without a currency are assumed to be your reporting currency, which quietly overstates or understates everything.
Owners. Records imported without an owner are records nobody is responsible for.
Encoding. Names with accents arriving as symbols means the file was saved wrongly, and it is worth fixing at the source rather than in the database.
Do it in one sitting per object
Contacts in one go. Companies in one go. Deals in one go.
Splitting an import across two days means two files, and the second one usually includes rows the first one already had. Duplicates from a split import are the hardest kind to find afterwards, because the two copies are genuinely identical.
Who owns the file
One person holds the source spreadsheet and makes every correction in it.
Corrections made in the product after import are lost the moment somebody reimports the file to fix something else, and somebody always does. Fix upstream, reimport, then work in the product.
After the import
Look for orphans. Deals with no company, contacts with no organisation. See Data management.
Check the totals against the system you came from. Not record counts, values. Counts match while values are wrong more often than people expect.
Set a date and stop using the old system. Two live systems produce two versions of the truth within a fortnight, and the reconciliation is worse than either migration.
Import order between objects
Objects reference each other, so the order matters.
Companies before contacts, so a contact can attach to its company.
Contacts and companies before deals, so a deal has a party. A deal imported without one is exactly the orphan the cleanup step goes looking for.
People before anything owned, so records can carry an owner on arrival rather than being assigned afterwards by hand.
Getting this wrong does not fail loudly. It produces records that import perfectly and are attached to nothing.
Getting data back out
Worth knowing before you put anything in. See Exporting your data and Getting your data out.
Next
Finance, which has its own data of its own kind.
Did this answer your question?
No, ask a person