Migration uncertainty can delay a switch
An agency may postpone changing platforms when it does not know what can be exported, how photos will be preserved or how long both systems must run in parallel. Duration depends on data volume and quality, available formats and support from both vendors.
Step 1: decide what actually moves
- Mandatory: active properties, working contacts, transactions in progress, valid contracts.
- Useful: properties sold in the last two years, for comparables and valuations, plus the history of recurring clients.
- Archive: everything else. Export it once, keep the file, do not import it. There is no reason to fill a new platform with data you never open.
Step 2: request the export
Your data is yours. Ask for an open format, preferably CSV or Excel, separated into properties, contacts and activities. Then check three things immediately: whether diacritics survived, whether prices and surfaces arrived as numbers rather than text, and whether photos are included as files or only as web addresses.
Photos are the most commonly missed part. If the export contains only links, they work exactly until the day you close the old subscription. Download them locally first.
Step 3: clean before importing
Migration is the only moment when everyone agrees to tidy up. Use it:
- Remove duplicate properties created by repeated listings.
- Merge contacts that appear three times with phone numbers written differently.
- Standardise localities and neighbourhoods, otherwise search in the new system will be just as chaotic.
- Mark clearly what is sold, active or suspended.
The rule is simple: bad data is not repaired by importing, only relocated.
Step 4: import in the right order
- Users and roles — agents must exist before properties can be assigned to them.
- Contacts — owners, buyers, collaborators.
- Properties — linked to owner and responsible agent.
- Photos — attached to properties that already exist.
- Transactions and activities — last, when there is something to attach them to.
Step 5: verify on a sample, not on the total
After import, do not only check record counts. Choose a sample that includes simple properties and complicated cases, then verify price, surface, rooms, floor, area, attached owner, photo order and intact characters. Sampling can expose mapping errors, but it does not replace reconciling totals and reviewing import error reports.
Step 6: run in parallel, but briefly
The parallel period depends on the migration's volume and risk. Define a cutover date, who may edit each system and how changes made before cutover will be synchronised. After validation, keep the old system as a read-only archive if the vendor's terms allow it.
Step 7: republishing on portals
The most sensitive practical point. Active portal listings are tied to your accounts, not to the CRM. Before moving, record what is published and where; after import, reconnect the portal accounts and verify synchronisation on a few listings rather than all at once. The full workflow is in the publishing guide.
Step 8: the first week with the team
- One short session, on the agency's real data, not on a generic demo.
- One workflow explained very well: from lead to viewing. The rest is learned along the way.
- One person designated as the contact point for questions.
- A firm rule: from Monday, nothing is recorded anywhere else.
Common mistakes
- Migrating in peak season. Choose a quieter period.
- Importing without cleaning, to save a day and lose a year of bad searches.
- Forgetting the photos until after the old account is closed.
- No owner. If the migration belongs to everyone, it belongs to no one.
Conclusion
A CRM migration becomes manageable when you follow the order: inventory and back up the data, clean it, import in layers, validate the result and define a controlled cutover. If you are evaluating a move, read the selection criteria or see the Lukian platform.
