Migrate from REDA to Twenty CRM

Extract REDA data via Salesforce REST and Bulk APIs

We authenticate against your REDA Salesforce org using OAuth 2.0 and pull all CRM objects — Contact, Account, Opportunity, Task, Note, and any custom property, unit, or lease objects — via the Salesforce REST API for small datasets and Bulk API 2.0 for large record volumes. Each object exports to a separate CSV file. We capture all standard fields plus REDA custom fields (__c) and system fields (CreatedDate, LastModifiedDate, OwnerId). File splits at 20,000 records are handled in this step so downstream import sequencing is predetermined.

Audit source data for quality and referential integrity

We profile every exported file for duplicate records (matching on email, domain, and object ID), missing required fields, and orphaned foreign keys — especially AccountId references on Contacts and Opportunity records that may not have a corresponding Account in the export. We also audit the REDA custom property and unit objects for circular references, null owner assignments, and date-field consistency. The audit report flags records that need manual resolution before migration and identifies which objects exceed Twenty's 20,000-record import threshold.

Map REDA schema to Twenty data model and design custom objects

We build a field-level mapping document that pairs every REDA object and field to its Twenty counterpart — direct mappings, value mappings for pick-lists, and custom_field_required entries for REDA custom fields. For REDA's property, unit, and lease custom objects, we deliver a Twenty custom-object design specifying object names, field definitions, field types, and pick-list values. You create these objects in Twenty's Settings → Data Model before the import step runs. We also deliver the stage-value mapping table that translates REDA Opportunity stage names to Twenty stageName options.

Invite Twenty workspace members and resolve owners by email

Twenty requires all users referenced as assignees to exist in the workspace before import — a People record with an assigneeId pointing to a non-existent member fails at import time. We extract every REDA OwnerId, resolve it to an email address, and match it against Twenty workspace members. Your team receives a list of unmatched owners with instructions to invite them to Twenty and wait for acceptance. Unresolved owners receive a fallback assignee (typically the migration admin) and are flagged in the post-migration report for re-assignment.

Run sample migration with field-level diff before full commit

A representative slice of records — typically 200–500 per object type, covering standard and custom fields — imports first into a clean Twenty workspace or a dedicated test environment. We generate a field-level diff report comparing source values against the migrated values in Twenty, verifying field names, pick-list values, date formats, owner resolution, and custom field population. You review the diff and approve before the full migration is scheduled. This step is where stage value mapping, currency normalization, and custom field translation are validated end-to-end.

Full migration with delta-pickup and post-migration reconciliation

The full migration runs with all objects in the sequenced import order: Companies first, then People, then Opportunities, then Tasks and Notes, then custom Property/Unit/Lease objects last. During the cutover window, REDA remains fully operational — we use scoped read access only. A delta-pickup pass captures any records created or modified in REDA during the import run. After migration, we reconcile record counts between REDA exports and Twenty imports, verify foreign-key links (People→Company, Opportunity→Company, Unit→Property), and deliver an audit log with one-click rollback available if reconciliation identifies data discrepancies.