Contacts, listings, deals, documents and the activity behind them, moved together — profiled at source, mapped field by field, deduplicated on load, reconciled by count on every pass, and cut over in parallel rather than overnight. Twopir Consulting treats migration as a project, because the alternative is an import that loses your firm its adoption in week one. History is not optional data. It is the reason anybody logs in.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups whose contacts, listings, deals and years of activity history Twopir Consulting has moved into Propertybase.
What We Move
A migration is judged on go-live morning by people who did not attend any of the planning meetings. Each of these looks like a small technical compromise in week two and like a broken promise in week ten. You get one first impression.
The contacts arrive; six years of calls, emails, notes and past transactions do not. Agents open a record, find nothing they recognise, and conclude the new system is worse than the old one — a judgement made in the first hour and almost impossible to reverse.
Three versions of the same past client, two of the same property, and no agreed rule about which survives. Cleaning after the load means merging records that already have new activity attached, which is far harder than deciding the rule beforehand.
The mapping was built from a schema document rather than from the data. Then the load meets free-text dates, a phone field holding notes, and a status picklist with forty distinct values because it was never validated — and the schedule absorbs it.
Agreements, disclosures and signed contracts stay behind in a shared drive, unattached to any record. The first compliance request after go-live turns into a manual search, and the audit trail the firm was buying does not yet exist.
A sample of five hundred records behaves nothing like six years of history. Volume surfaces locking, timeouts and validation rejections that a sample never triggers, and finding them in production on cutover weekend is the most expensive way to learn.
The old system is switched off on Friday. On Monday every unmapped field and missing document surfaces at once, in production, with agents watching — and there is no rollback because nobody planned for one. A parallel run costs two weeks and prevents exactly this.
Propertybase data migration is the work of moving a brokerage's operating history into a Salesforce org so that it means the same thing on the other side. That is more than a load: the source has to be profiled rather than trusted, every field mapped to a target that may not have an equivalent, duplicates resolved under an agreed rule, relationships rebuilt so an activity still hangs off the right contact and the right deal, and the whole pipeline run repeatedly against a sandbox until it is boring.
One technical decision does most of the work: every record needs a stable external identifier, and every write should be an upsert against it. That single choice makes the migration idempotent — a re-run after a timeout or a partial failure costs nothing, because it updates rather than duplicates. Migrations without it cannot safely be repeated, which is why they end up being attempted once, in production, on a weekend. For listings specifically that identifier also has to be the one your MLS feed will key against afterwards, or your first sync will duplicate everything you just moved.
Who this is for: brokerages replatforming off an agent CRM, a spreadsheet estate or a transaction tool they have outgrown, and firms consolidating several offices onto one org. We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we work with enterprise organizations facing the same problems at greater scale. Where migration is one part of a wider build, the whole engagement is Propertybase implementation.
The five data classes in a brokerage migration, and how differently each one behaves
| Contacts & companies | Listings & properties | Deals & transactions | Activity & documents | |
|---|---|---|---|---|
| Why it matters | The relationships the firm's revenue actually rests on | Inventory history, comps and the seller conversations built on them | What closed, when, for how much, and who earned what | The reason an agent believes the new system knows their client |
| Hard part | Deduplication across sources, and agreeing which version survives | Matching to a stable identifier the MLS feed will also key against | Rebuilding relationships to contacts, listings and commission records | Volume, and attaching each item to the right parent record |
| Commonly cut | Rarely — everyone agrees this must move | Closed and expired history, which is where comps come from | Older closed deals, which is where commission disputes come from | Almost always, and it is almost always the wrong call |
| Our default | Move everything, deduplicated on load under a written rule | Move active plus closed history, keyed for the feed | Move all of it; scope cuts here resurface as disputes | Move it, staged after the parent records land |
The row worth arguing about is the third. Scope cuts are usually proposed against activity and history because they are the largest and least visible in a demo — and they are exactly what agents judge the system on. If budget forces a cut, cut recency rather than category: five years of everything beats everything of one thing.
Three shapes of migration work with very different risk profiles. The third is the one most often underestimated, because merging two clean sources is harder than moving one messy one.
Profiling the source before anybody commits to a schedule. The cheapest stage and the one that most reliably changes the estimate, because nobody's data is what its schema says it is.
The move itself, built as a repeatable pipeline rather than a one-off load. Run against a sandbox until the reconciliation is boring, then run once in production with a rollback that exists.
Several systems or offices into one org — after an acquisition, a merger, or years of each office choosing its own tools. The hard part is not the loading; it is agreeing whose version of a shared client is right.
Profile the source; never trust the schema. Free-text dates, phone fields holding notes and a status picklist with forty values are found by looking at the data, not by reading a document about it. Every record gets a stable external ID. That makes the load an upsert and the whole pipeline idempotent, so a re-run costs nothing — and for listings it has to be the same identifier the MLS feed will key against afterwards.
Deduplicate on load, under a written rule. Merging after go-live means merging records that already carry new activity, which is far harder and far riskier than deciding survivorship beforehand. Rehearse at full volume, and keep a way back. A sample behaves nothing like six years of history; the parallel run and the rollback plan are what make cutover a decision rather than a gamble.
Parents before children, references before the records that point at them, and reconciliation after every single pass. A migration run out of order produces orphans nobody finds until a report is wrong.
Looking at what is actually in the systems rather than what they are documented to contain. This stage routinely changes the scope, and it is far cheaper to be surprised here than during a load.
Field by field, into the packaged Propertybase objects and your own. The document the whole migration is judged against, and the one you sign before anything moves.
Deciding, before the load, which version of a duplicated client or property wins and what happens to the rest. A business decision that gets made by a loader's default if nobody makes it deliberately.
The workstream most often cut and most responsible for adoption. Calls, emails, notes, past transactions and signed documents, each attached to the right parent record.
The pipeline itself, built to run many times rather than once. Every pass reconciles against the source, and any pass can be repeated without creating a duplicate.
The part that decides whether agents come with you. Both systems carry the truth until the numbers agree, and switching the old one off is a decision rather than a deadline.
Every source has a characteristic problem, and knowing it in advance is most of what experience buys on a migration. These are the eight a brokerage typically arrives with.
Export tooling is usually built for contacts and stops there, so activity and deal history need a different route out. Assume the first export you are offered is not the one you need.
One per agent, none agreeing on columns, and at least one holding a formula rather than a value. The hard part is reconciling forty versions of a lead-status vocabulary into one lifecycle.
Rich in milestone and document history, weak in the relationship back to a contact. Expect to reconstruct the link between a loop and the client it belongs to, often by address.
Technically the easiest and politically the hardest: two orgs that both work, with different customization and conflicting survivorship. The mapping is simple; the agreement is not.
Often the only record of what was agreed with a past client. Rarely migrated wholesale; usually the right answer is going forward via activity sync, with a targeted historical extract where it matters.
Large, unstructured, and organised by folder conventions that only one person understands. Attaching each file to the right record is the work; moving the bytes is trivial by comparison.
Historical splits and disbursements that agents will check against their own records. Migrate these and expect questions; skip them and expect the same questions with no answer available.
Not a migration source so much as a constraint: whatever identifier your listings arrive with after go-live has to match what you migrated on, or the first sync duplicates everything you just moved.
Getting that last one right is a feed design decision — see Propertybase integration and, for the load engineering itself, Propertybase API & integrations.
The production load should be the least interesting day of the project. Everything before it exists to make that true.
Actual values, not documented ones. Formats, completeness, outliers, junk rows, the real duplicate rate and the relationships between objects. This is the stage that most often changes the estimate, and finding a forty-value status picklist here costs a day rather than a weekend.
Field-level mapping onto the packaged objects and your own, picklists reconciled into one lifecycle, external IDs designed so every write is an upsert, and survivorship rules agreed with the business rather than defaulted by a loader. You sign this before anything moves.
The pipeline runs into a sandbox, repeatedly, at real volume — because a sample of five hundred records behaves nothing like six years of history. Locking, timeouts and validation rejections surface here. Each run reconciles by count, and we keep running until nothing surprises us.
Production load in staged passes, parents before children, with counts reconciled by object and by owner after each. Then a parallel run — typically two to three weeks — where both systems carry the truth, with delta loads so records created during the window are not stranded.
A data freeze, a final reconciliation, and a rollback plan that existed before it was needed. Switching off the old system is a decision made when the numbers agree, not a date set in advance — then hypercare through the first close cycle, when the gaps that matter actually surface.
Two engagements, both real estate. The first replatformed a four-office, 120+ agent brokerage off a basic CRM and spreadsheet estate, with a parallel run before cutover. The numbers are the ones those clients measured.
We had Salesforce. We had Propertybase. We had agents using three different follow-up tools. Nothing was connected, and our managing broker was flying blind. Twopir came in, mapped everything, and built a single operating model that our entire team actually uses. We went from not knowing where deals were to having a live dashboard that tells us exactly what's open, what's at risk, and what closed last week.
Replatform from a basic CRM and spreadsheet estate — contacts, listings, deals and history, with a phased cutover and no forced switch.
Commission reconciliation used to take our back office three full days at the end of every month. Agents were questioning their splits, and we had no clean audit trail. Twopir connected our deal records to Accounting Seed and built automated disbursement workflows. We now close commission statements the same day a transaction closes. The trust that has rebuilt with our agents because of that alone has been significant.
Historical commission and disbursement records moved onto the deal record, with the audit trail preserved.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. Migration is where implementations are won or lost, and it is the workstream most often scoped as though it were an import.
Nobody's data is what its schema says it is. Free-text dates, phone fields holding notes, forty distinct values in a status picklist — found by looking, and far cheaper to find at profiling than during a load with a go-live date attached.
That single decision makes the whole pipeline idempotent, so a re-run after a timeout costs nothing. Migrations without it can only be attempted once, in production, which is why they get attempted on a weekend with nobody available.
Survivorship is a business decision. Left unmade, it gets made by a loader's default — and merging afterwards means merging records that already carry new activity, which is harder and riskier than deciding beforehand.
The identifier you migrate on has to be the one the MLS feed will key against afterwards. Get that wrong and your first sync duplicates the entire inventory you just moved — a failure that looks like a feed problem and is actually a migration one.
A parallel run costs two weeks and prevents the Monday morning where every unmapped field surfaces at once in front of agents. Switching off the old system is a decision made when the numbers agree, not a date set in a plan.
Not if the migration is scoped as a migration rather than an import. Contacts, listings, deals, documents and the activity behind them move together, related back to the right parent records, deduplicated on load and reconciled by count against the source on every pass. This matters more than any other technical decision in a CRM project, because agents judge a new system almost entirely on whether the record of their past client conversations is in it. Implementations that move current records and leave history behind lose adoption in the first week and rarely recover it.
It depends on four things, and we will not quote before seeing them: how many source systems there are, how much history is moving, how clean that history is, and whether offices are being consolidated. What we can tell you in advance is the shape — profiling first, then mapping signed off, then repeated rehearsal loads into a sandbox until nothing surprises us, then a staged production load, then a parallel run of typically two to three weeks before the old system is switched off. Profiling is the stage that most often changes the estimate, which is exactly why it comes before one.
Agent-focused CRMs, spreadsheet estates, transaction platforms, document and file stores, accounting and commission records, and other Salesforce or Propertybase orgs during a consolidation. Each has a characteristic difficulty: agent CRMs export contacts well and activity badly; spreadsheets disagree with each other about columns and status vocabulary; transaction platforms are rich in milestones but weak in the link back to a contact; document stores are organised by folder conventions one person understands. Email is the exception we usually advise against migrating wholesale — going forward via activity sync, with a targeted historical extract where it genuinely matters, is normally the better trade.
On load, under a rule the business has agreed in writing — never afterwards. We measure the actual duplicate rate during profiling rather than assuming it, define match rules per object, and agree survivorship field by field: which record wins, and what happens to the values and activity on the ones that do not. Merging after go-live is materially harder because those records already carry new activity, and the merge decisions then affect live work. Where no rule should decide automatically, those cases go on an exception list for a person to resolve rather than being silently resolved by a loader's default.
Yes, and we insist on it. A parallel run of typically two to three weeks, sized to your transaction cycle, is what turns cutover from a gamble into a decision — both systems carry the truth, discrepancies surface while there is still a working fallback, and delta loads make sure records created during the window are not stranded. Switching the old system off then happens when the numbers agree rather than on a date set months earlier. The alternative is the Monday morning where every unmapped field and missing document surfaces at once, in production, in front of the agents whose confidence you need.
They will, unless the identifier you migrated on is the same one the feed keys against. This is the single most common expensive mistake in a real estate migration, and it looks like a feed problem when it is actually a migration one: listings arrive from the MLS, fail to match the records you loaded, and get created again. Every listing needs a unique, never-changing identifier — a broker listing ID or MLS ID — decided during mapping with the feed design in view, not chosen by whoever wrote the load. We treat the migration key and the integration key as one decision, made once.
Yes, and it is usually harder than moving one messy system, which surprises people. Merging two sources that both work means resolving identity across them — the same past client, the same property, recorded differently in each — and then deciding whose version survives, which is a business decision with politics attached rather than a technical one. Conflicting picklists and stage models have to be reconciled into a single lifecycle, and ownership and sharing decided before records land in one place. We sequence these office by office rather than as a single event, so each cutover is small enough to reverse.
A replatform off a CRM you have outgrown, a spreadsheet estate nobody can reconcile, two offices merging onto one org, or a migration that already went wrong once. We will profile what you actually have and tell you what it takes — before anyone commits to a go-live.
Salesforce architecture, Propertybase delivery & real estate operations
