Migrate from The Real Estate Platform (REP) to Twenty CRM

REP's per-tenant custom field schema requires mandatory pre-migration audit

The Real Estate Platform (REP) does not expose a public schema API. Each REP customer instance has a unique set of custom contact properties, custom company fields, and custom deal fields configured by Phoenix Software during onboarding. There is no standard REP field schema that applies across all REP tenants. Before FlitStack can create matching custom fields in Twenty and begin field mapping, we must run a REP schema audit that enumerates every custom property present in your specific REP instance. This audit step adds 1–3 days to the project timeline and must complete before the Twenty schema setup phase begins. Skipping this step risks silent data loss on any REP custom fields not pre-created in Twenty.

Twenty's CSV import enforces a strict dependency order that REP does not follow

Twenty's built-in import tool requires records to be uploaded in a specific order: Companies first, then People, then Opportunities, then custom objects with relations last. This ordering constraint exists because Twenty's foreign keys — companyId on People, and peopleId and companyId on Opportunities — must reference records that already exist in the database. REP has no equivalent constraint; companies, contacts, and deals can be exported in any order. FlitStack sequences the migration so that all REP Companies are migrated and committed before REP People are processed, and all People are committed before any Opportunities are migrated. This sequencing adds a coordination step for teams with circular references (contacts linked to deals that reference companies that reference those contacts) — such cases are flagged and resolved manually before the migration run.

REP marketing campaigns have no native equivalent in Twenty — a custom object must be pre-created

The Real Estate Platform (REP) includes a marketing campaign object that tracks which contacts are members of which campaigns, with campaign-level metrics. Twenty CRM has no native campaign object on any plan — not even as a paid add-on. If your REP instance stores campaign membership data that you need to preserve for reporting, FlitStack creates a custom Campaign object in Twenty during the schema setup phase, with a CampaignMember relation to the People object. However, Twenty's workflow builder and reporting tools are not aware of this custom object by default — your team may need to manually configure campaign-related views and filters post-migration. This is a structural gap between REP's feature set and Twenty's current object model that requires explicit acknowledgment before migration begins.

Twenty's import tool caps CSV files at 20,000 records per batch

Twenty's CSV import function (Command Menu → Import records) supports a maximum of 20,000 records per import file. REP instances with large data volumes — particularly real estate teams with thousands of historical transactions, contacts accumulated over years, or bulk activity logs from automated campaigns — exceed this limit. FlitStack handles this by splitting large REP record sets into 20,000-record batches before loading into Twenty, and managing the dependency ordering across batches. For REP instances exceeding 50,000 total records, we recommend using Twenty's REST or GraphQL API for the bulk load instead of CSV, which FlitStack can execute directly. The API approach bypasses the 20,000-record batch limit and allows higher throughput for large REP migrations.

REP's transaction and property data requires a custom object or custom field design decision

REP natively models real estate listings, property records, and transaction-linked deals as core REP objects — property IDs, listing status, listing price, and transaction type are standard REP fields stored on deals and companies. Twenty has no native real estate property or listing object. REP property references must be stored as custom fields on Companies or Opportunities, or as a separate custom Property object with a relation to Opportunities. The correct design depends on how your REP instance uses property data: if each deal is tied to one property, custom fields on Opportunities is sufficient; if deals can span multiple properties, a custom Property object with a one-to-many relation from Opportunities is more accurate. FlitStack documents this design decision during the REP schema audit and presents both options with a recommendation before the Twenty schema is configured.