How to move a brokerage off five tools in a weekend
John Nguyen — Founder of Patio, licensed Texas REALTOR®
A weekend is enough to move a ten-agent brokerage onto a new system. It is not enough to move everything you have ever had, and the difference between those two statements is the whole plan.
Migrations fail for a predictable reason: the office tries to bring all of its history across, discovers halfway through Saturday that the data is worse than anyone remembered, and arrives at Monday with half a system. The version that works starts from the opposite premise — move what the business needs to operate on Monday, leave the rest where it is, and bring it over later or never.
Here is the plan. It assumes a small office, a decided destination, and a broker who has accepted that some things will not come across.
Two weeks before: the part that actually determines the outcome
Almost all of the risk lives here, not in the weekend.
Export everything, now, and look at it. Every system, full export, before you need it. Two reasons. First, exports take longer than vendors say and some require a support ticket. Second, and more important: you need to look at the data while there is still time to react. Open the contact export. It will be worse than you think — duplicates, blank fields, people who left in 2019, three records for the same person. Every migration discovers this and the ones that discover it on Saturday are the ones that fail.
Decide what is operational and what is archive. This is the central decision of the whole project.
Operational is what the office needs to work on Monday: active listings, live transactions, the current roster, the contacts anyone is actually working, this year's financial position. For a ten-agent office this is a surprisingly small amount of data.
Archive is everything else. Closed transactions from previous years, old marketing, dead leads, historical documents. It has to be retained — record retention is a real obligation and your state has rules about duration — but retention and migration are different things. Keep the old system's export, stored properly and accessibly. Do not spend your weekend importing 2019 into a new product.
Write the line down and get the broker to agree to it in advance. Under pressure on Saturday afternoon, someone will want to move the line, and a decision made at 4pm on day one is how a two-day migration becomes a three-week one.
Clean the contacts before you move them. The only cleanup worth doing is deduplication and removing people who are definitively gone. Do it in a spreadsheet, not in either system. Moving a mess produces a mess you now have in two places.
Do a test import. Ten records. Then look at what arrived. Fields land in wrong columns, dates get reinterpreted, phone formats break. Find this with ten records, not four thousand.
Tell the agents. Twice, with dates. What changes, when they lose access to the old thing, what they need to do, and where the help is. An agent surprised on Monday is an agent who does not adopt.
Friday: freeze
End of business Friday, the old systems become read-only. Not deleted — read-only. Nobody enters new data anywhere. This is non-negotiable and it is the discipline the whole weekend rests on: any record created in the old system after your export is a record that silently does not exist in the new one.
Take your final exports Friday evening, after the freeze.
Then confirm three boring things: everyone has credentials for the new system, the broker knows who to call, and you have a written note of what "done" looks like. A migration without a definition of done runs until someone gives up.
Saturday: structure and the money
Morning — set up the shell. The brokerage, the offices, the roles, every agent's account, the permissions. Nothing imported yet. This is the frame everything else hangs on, and getting a role wrong here is felt for months.
Midday — import in dependency order. Agents, then contacts, then listings, then active transactions. Each one in that order because the later ones reference the earlier ones. Import, then check a sample of ten against the source before moving on. Do not chain four imports and verify at the end; you will not know which one was wrong.
Afternoon — the money. Commission structures, splits, cap positions, anything outstanding. Give this its own block and do it while you are fresh.
This is the single most sensitive category in the migration, and it deserves one specific discipline: reconcile against a number you already trust. Take the year-to-date figures from the old system, or from your accounting, and confirm the new system produces the same answers for the same agents. An agent whose cap position is wrong on Monday will not trust anything else in the product for a year, and they will be right not to.
Sunday: verify, then walk through it
Morning — verification, and do it properly. Not a glance. For each category, a real check:
- Counts. Contacts, listings, active transactions. Numbers must match the source, and when they do not you need to know why before Monday, not as a mystery.
- Spot checks. Ten records per category, compared field by field against the export.
- The awkward ones. The transaction with the unusual structure. The agent with the non-standard split. The listing with the co-listing arrangement. These are where import logic breaks, and they are never in a random sample.
- Every active transaction, individually. All of them, one by one. In a small office this is a manageable number and it is the highest-value hour of the weekend, because a live deal with a missing document is the only failure here that can cost real money.
Afternoon — walk the real workflows. Not a feature tour. Actually do the things: add a contact, log a call, open a listing, upload a document to a live file, run the broker's view, produce whatever report the office depends on. Every one of these will surface something small. Fix them now.
Late afternoon — write the one-pager. Where everything is, how to do the five things agents do daily, and who to ask. One page, sent Sunday evening. This costs thirty minutes and prevents most of Monday's questions.
Monday: the three things that go wrong
They are the same three every time.
Somebody finds missing data. Usually old, usually archive, usually something the office agreed on two weeks ago to leave behind. Have the answer ready: it is retained, here is where, and here is how to get a record out of it if you genuinely need one. Without that answer prepared, this becomes a crisis about trust rather than a question about data.
An agent cannot do one specific thing. Not the system — one workflow, one agent, one habit that does not map. Fix it individually and immediately. These are the moments that decide whether adoption happens, and they are cheap to solve on the day and expensive a fortnight later.
Something looks wrong and is not. A number displayed differently, a list sorted another way, a field in another place. It will be reported as broken. Have someone available who can look at it within the hour, because an unresolved "the new system is wrong" spreads through an office faster than any actual defect.
Staff the Monday. The office manager does nothing else that day, and the broker is reachable. One prepared day is worth more than another week of preparation.
What "done" looks like
Not "everything moved." Done is: every active transaction is live and complete, every agent can do their daily work, the money reconciles against a number you already trusted, and the old systems are read-only with their exports safely retained.
Everything else is archive, and archive has no deadline.
Keep reading
Switching tools
All-in-one alternatives for independent brokerages
What consolidation actually buys an independent office, what it costs, and the five-question test for whether a platform is genuinely one system.
Switching tools
dotloop vs SkySlope for small brokerages — and what neither does
How to compare two transaction management platforms on the things that matter to a small office, and the four jobs neither of them is built to do.