Migrating from Excel to a real estate CRM: a six-step method

The signal to switch is not the size of the file

A spreadsheet stays an excellent tool as long as one person maintains it and one version circulates. The difficulty starts when a salesperson works from a copy sent by email, sales administration keeps its own tab, and management asks for a status update on a date when the three files do not agree.

So the real trigger is organisational, not technical. It appears when you can no longer answer three simple questions in seconds: is this unit actually available today, who owns the next action on this record, and how much has been collected on this project this month.

• Several versions of the same file circulate by email or WhatsApp.
• An option placed on a unit is only visible to the person who entered it.
• Reservations and collections are reconciled by hand.
• The indicators management asks for take half a day to produce.

As long as inventory, sales tracking and payments do not share the same unit identifier, every consolidation remains a manual reconstruction.

1. Take stock of the files before discussing imports

Before any migration, list the files actually in use, not the ones that should be. For each, note who maintains it, how often it is updated, which columns genuinely serve a purpose, and which have not been filled in for months.

This inventory almost always reveals overlapping roles: two files tracking the same unit with different statuses. Deciding now which one prevails avoids carrying the conflict into the new system.

• One named owner per file.
• Useful columns separated from historical ones.
• Implicit rules (colours, comments, highlighted cells) written down explicitly.
• An explicit decision on which file prevails when they disagree.

2. Clean up in the spreadsheet, not after the import

Correcting data in a spreadsheet, with the filters and sorting the team already knows, is far faster than fixing it row by row once imported. The clean-up covers three things: identifiers, statuses and formats.

Unit identifiers must be unique and stable: the same unit cannot be called « A12 » in one file and « Bldg A - 12 » in another. Statuses must fit into a short list that everyone reads the same way. Dates and amounts must be real dates and real numbers, not text.

• One row per unit, with no merged cells or interleaved subtotals.
• A closed list of statuses: available, optioned, reserved, sold.
• Consistent date formats and amounts without units glued to the number.
• Duplicate prospects merged by phone number or email before importing.

A doubtful figure that is imported becomes a doubtful figure shared with the whole team. The sorting happens before, not after.

3. Migrate in order of dependency

The order is not arbitrary: each step builds on the previous one. Projects and units form the reference; prospects attach to it; reservations connect a prospect to a unit; payment schedules and collections follow from reservations.

Importing payments before units forces you to attach the amounts by hand. Importing units first lets the following imports find their attachment automatically through the identifier.

• Projects, phases and buildings.
• Units with property type, floor area, price and status.
• Active prospects, with an owner and a next action.
• Reservations in progress, then their payment schedules and collections.

4. Start with one pilot project, not with the archives

A single project currently being marketed is enough to test the whole chain. It contains units in every status, active prospects, signed reservations and upcoming instalments: enough to validate the rules on real cases, at a volume the team can check row by row.

Delivered projects and archives can wait. They carry no sales action and do not need to be migrated for the new tracking to become useful. Migrating them first means spending the clean-up effort on data nobody uses.

A successful pilot on one project convinces the team more reliably than a full migration delivered with discrepancies.

5. Verify by cross-checking, not by impression

The migration is not finished when the import runs without errors, but when the totals reconcile. Compare the number of units per project, the split by status, the number of reservations in progress and the amount collected, between the old file and the new reference.

Discrepancies are informative: they almost always point to an implicit spreadsheet rule that was never written down. This is the right moment to state it, rather than letting it re-form as a parallel file.

• Units per project and per status, on both sides.
• Reservations in progress and amounts expected over the period.
• Total collected over the last three months.
• A list of records with no owner, no payment schedule or no attachment.

6. Set a date to retire the old file

As long as the old grid stays editable, it keeps being edited. That is the main cause of failed migrations: two sources coexist, the team hesitates, and double entry settles in for good.

Announce a date from which the file becomes read-only and serves only as an archive. Over the following two or three weeks, hold a short weekly review to handle exceptions and adjust statuses or access rights.

• An announced retirement date and a dated archived version.
• One identified point of contact for questions during the transition.
• A weekly review to handle exceptions.
• Access rights revisited once the new habits have settled.