Implementation and migration

Contacts are the thing brokerages worry about, so start there. There are three ways into the platform and they are not mutually exclusive. Most teams use two.

The first is a file. Export from your current system and upload the CSV or VCF. You tell us where it came from, or let the parser work it out, and the columns get mapped for you. Google and Outlook exports have known layouts and map directly. Anything else gets read and matched to our fields, with a keyword fallback if that fails. You never sit in front of a mapping grid.

Then you review before anything is written. The upload shows you the parsed rows with a data quality score, lets you fix a value inline, and lets you uncheck rows you do not want. Duplicates inside the file are grouped and flagged, with a single action to keep the first of each group. Only the rows you approve get created, in batches of up to a thousand per submission, and you can drop the whole import straight into a new list.

The second route is your address book. Connecting Google or Microsoft includes a read-only contacts scope, and the sync pulls your address book across. This path does check against your existing contacts. It scores each incoming record on email, phone, and name, then decides whether to skip, merge, update, or create. A close match does not become a second record.

The third is your current CRM. Follow Up Boss and Dotloop have purpose-built connectors, and other systems go through the same connector layer generically. Contacts arriving that way run through the same duplicate check as the address book sync.

Being blunt about this is the point of the page. A few steps cannot be done for you, and pretending otherwise is how implementations slip.

You supply the export from your current vendor. We cannot log into their system and pull it, so someone on your side has to run the export and hand over the file. Export contacts, deals, and notes as separate files while you are in there, even for the categories you do not plan to import, because that export is your only backup once the old contract ends.

You supply the MLS Member ID for each agent. That is the identifier we match against our agent records to link a person to their listings and production. If an agent gets it wrong, verification fails and the platform tells them so rather than silently linking the wrong profile.

You approve every OAuth grant yourself, on Google's or Microsoft's screen. Nobody at RealAnalytica can do that on your behalf, which is the whole point of it working that way.

And you rebuild the automation layer. Sequences, saved lists, and templates do not come across from any vendor. See security for what those grants can and cannot reach once they are in place.

A single agent needs nobody's help. Sign up, connect a mailbox, upload a file, and link an MLS Member ID. The guided setup on first login walks through profile details, branding, the CRM connection, the MLS link, and the inbox connection. Every step is skippable, and the MLS step is hidden entirely for plans without data access so nobody stares at a screen they cannot use. A checklist stays on the dashboard afterward for whatever you skipped.

A team adds invitations. An admin sends them from the team screen, one email at a time, with a role attached. The link expires after 48 hours. Accepting creates the user, attaches them to the right team or organization at the right plan tier, and adds a seat, which updates the subscription quantity. There is no self-serve bulk invite today. If you are inviting forty people, you are clicking forty times.

A brokerage moving a full roster uses a different path, and our team runs it. You supply a spreadsheet of agents with their MLS codes and team assignments. It gets validated before anything is created, then the organization, the teams, and the users are created in one batch with your branding applied. That batch is all-or-nothing: if one row fails, the whole thing rolls back rather than leaving you half migrated. Raise it on a demo call or through the contact form.

The playbook below is the planning document. It covers the audit, the export, the staged import, the parallel operation period, and the training sequence, with the timings a real team should budget. Read it before you pick a switch date.