A brokerage that has been running LionDesk for five years typically has somewhere between 6,000 and 15,000 contacts in the system. Some were entered by agents who have since left. Some were imported twice from different lead sources. Some have phone numbers in the notes field, deal stages in the contact name, and a mix of tags that meant something to one agent three years ago but nothing to anyone today. When the broker decides it is time to move to a different CRM — Follow Up Boss, kvCORE, Wise Agent — the instinct is to export everything and import it into the new system immediately. That instinct is almost always wrong.
What a raw LionDesk export actually looks like
LionDesk exports contacts as a CSV. The file usually runs between 40 and 80 columns depending on which custom fields were ever created. Many of those columns are empty for 90 percent of the records. The columns that matter most — primary phone, email, lead source, last contact date — are often inconsistently populated. Phone numbers appear as ten digits, as formatted strings with dashes, or as a raw number with no area code because someone typed it in manually. Duplicate records are common: the same person appears under two different email addresses, or the same email appears under two different names because an agent updated one record and not the other.
Import that CSV into a new CRM and you carry all of those problems forward. Worse, the new system will create its own record IDs and automation triggers will start firing based on stale or incorrect data — drip campaigns going to people who closed three years ago, lead-routing rules assigning dead contacts to active agents.
The audit step that most brokerages skip
Before any migration, the export needs to go through a structured review. That review should answer four questions: Which records are duplicates? Which phone numbers and emails are unformatted or invalid? Which contacts have no last-contact date within the past two years and can reasonably be archived rather than migrated? And which custom fields from LionDesk map to a standard field in the destination CRM versus a custom field that needs to be created?
Say a brokerage has 9,000 contacts in LionDesk. A deduplication pass typically finds 1,200 to 1,800 records that are exact or near-exact duplicates. Archiving contacts with no activity in over 24 months often removes another 2,000 to 3,000. The clean, active list that actually needs to move is closer to 4,500 records — and those records are worth migrating carefully rather than dumping in bulk.
An AI-assisted workflow can accelerate the audit significantly. A script can scan every phone number field against a standard formatting rule, flag anything that does not match, and produce a report in minutes rather than days. The same logic applies to email validation and duplicate detection by partial name and phone match. The output is a spreadsheet that a human reviews and approves before anything touches the new CRM.
Mapping fields before the import
LionDesk uses its own field names and picklist values. The destination CRM uses different ones. A contact tagged "Buyer – Active" in LionDesk may need to land in a pipeline stage called "Active Buyer" in the new system, or be assigned a specific smart list in Follow Up Boss. That mapping has to be defined explicitly before the import runs — not figured out afterward.
Writing the field map in a shared document and having the broker or team lead approve it takes a few hours. Cleaning it up after a bad import takes weeks. The mapping document also becomes the source of truth if the migration needs to be rolled back or rerun.
Custom fields deserve particular attention. LionDesk allows brokerages to create fields for things like loan type, price range, referral source, and agent notes. Those fields do not automatically appear in the destination CRM. Some can be mapped to existing standard fields. Others need to be created first. A few should simply be dropped because they were used inconsistently and carry no reliable information. Deciding which is which before the import prevents a cluttered schema in the new system.
Running the import in stages
The safest way to migrate is in batches, not all at once. Import the 200 most recently active contacts first — people who were contacted in the last 90 days. Verify that their records look correct in the new CRM: fields populated as expected, tags applied, pipeline stages assigned. Check that any automations that should trigger on import actually trigger, and that automations that should not trigger on historical contacts are paused during the import window.
Once the first batch checks out, run the next 1,000. Then the remainder. Running in stages means that if something is wrong with the field mapping or a picklist value, it surfaces on 200 records and not 9,000.
Real Estate AI Group's general approach here is to audit before building — or in this case, audit before migrating. A migration that moves clean data in stages and validates at each step is recoverable. One that dumps everything at once and discovers problems six weeks later is not.
Where to start
Pull your LionDesk export today and open it in a spreadsheet. Count the number of rows, then filter for records where the primary email column is blank. That number tells you immediately whether you have a data quality issue worth addressing before you move to any new system — and it takes about five minutes to find out.