Most teams arrive at Spodus with data already living somewhere else: a spreadsheet, an old CRM, an export from HubSpot or Pipedrive. The importer reads CSV files and spreadsheet exports, so in most cases you can upload the file your old tool gave you without converting it first. This guide covers the general flow. If you are moving off a specific tool, the migration guides walk through exporting from each one.
Prepare your files
Export your records one file per record type: contacts, companies, and deals. Keep a column with the original record's ID if you have one. It makes re-linking deals and notes to the right contacts much easier, and you can delete it after the import. Trim columns you will never use; a narrow, clean file maps faster than a wide one full of analytics fields you will not carry over.
Older .xls files cannot be read. Open one in Excel and save it as .xlsx, or export a CSV.
Map your columns
When you upload a file, Spodus shows your columns next to the fields on the record type and pre-fills the obvious matches. Exports from HubSpot, Pipedrive and Salesforce are recognised by their column headers, so the common mapping is already done when the step opens; confirm it rather than building it.
Fields have to exist before you can map to them. The wizard maps columns onto the fields the record type already has and does not create new ones mid-import. If a column has no home yet, add the field first — see Customizing fields and stages — then come back and map to it.
How duplicates are handled
Spodus matches on the record type's primary field: the name column on contacts and companies, and whatever the board uses as its primary on other objects. It is not an email or domain match, so if two people share a name they will look like one record to the importer.
Before you commit, the preview tells you how many rows already exist. The check asks the server which primary values are already in the workspace, and folds in earlier rows of the same file, so duplicates within your upload are caught as well as duplicates against what you already have.
The default is to skip duplicates, not to update them. Rows that match something already in the workspace are left alone, and your existing records are not overwritten. You can turn that off to import everything and merge by hand afterwards. Rows with no value in the primary field are always skipped, whatever you choose.
Import in dependency order
Order matters because records reference each other. Import companies first, then contacts linked to those companies, then deals that point at the right company and contact. If you import deals before the contacts exist, the associations will not resolve.
Verify
Spot-check a sample of records: confirm a handful of deal amounts, stages, and company associations landed correctly, and check your total row counts against the source export. Deleting a record moves it to the trash rather than destroying it, so a bad run is recoverable — but it is still quicker to get the mapping right than to undo a large import.
