Migrate from BackDocket to Twenty CRM

Backdocket contacts map 1:1 to Twenty People records. All standard contact properties such as name, email, phone, and address fields migrate as direct field mappings without transformation. Each Backdocket contact's associated case and claim records link via custom fields on the People record in Twenty, preserving the relationship between the client contact and their legal matter data. Owner assignment from Backdocket resolves against Twenty workspace members by email during the import.

Backdocket companies map to Twenty Companies records with all standard fields transferring directly. Firm name, domain, address, and industry classification migrate without transformation. Company records must exist before People records import because Twenty enforces referential integrity via the companyId lookup on People — FlitStack sequences this automatically during the migration run. Backdocket's law-firm-specific custom properties on the company record translate to Twenty custom fields on the Companies object.

Backdocket case records have no native Twenty equivalent. The case ID, case type, case status, and assigned attorney fields migrate as custom fields on the related People record. Case history and status-change timestamps are preserved as custom datetime fields for audit continuity.

Backdocket's claim and intake objects represent the front-end pipeline for new client matters. These translate to a set of custom fields on the People record (claim_type, intake_status, intake_date, referring_source). Intake pipeline stage values require value mapping if Backdocket uses a stage pick-list.

Backdocket document links and file attachments re-upload to Twenty's file storage and attach to the parent People record. Backdocket does not provide a bulk file export — FlitStack downloads files individually and re-uploads to Twenty. File size limits apply. Inline document previews do not carry over as rendered content.

Backdocket tasks map to Twenty Tasks records. Due dates, task descriptions, assignee email (resolved to Twenty workspace member), and completion status carry over. Open vs. completed task state is preserved. Recurring task rules do not migrate and must be rebuilt in Twenty's workflow builder.

Backdocket calendar events including court dates and hearing schedules migrate as Twenty Notes with custom datetime fields (event_date, event_type, location). Backdocket's calendar integration events carry original timestamps. Full calendar sync (Google Calendar, Outlook) must be reconnected in Twenty's settings post-migration.

Backdocket custom fields on any legal-specific object (e.g., Lien records, Insurance policy references, Court jurisdiction flags) migrate as Twenty custom fields under the relevant object. Twenty's Metadata API handles custom object creation — FlitStack generates the field definitions during the schema-setup phase before data loads.

Backdocket user and owner IDs are resolved by email match against Twenty workspace members. FlitStack flags any Backdocket owner with no matching Twenty user before migration — your team either creates the Twenty account first or assigns records to a fallback owner. Unmatched owners do not block migration; they are flagged for manual reassignment.

Backdocket's billing and invoice records have no native equivalent in Twenty CRM. FlitStack preserves invoice metadata (invoice number, amount, date, status) as custom fields on the associated People record for reference. Actual invoice files must be rehosted manually or linked via URL custom fields.

Backdocket notes migrate as Twenty Notes attached to the parent People record. Original create timestamps, note authors (resolved by email), and rich-text formatting are preserved where Backdocket's export format supports it. Notes without a clear parent record attach to the default workspace.

Backdocket workflow definitions, task sequences, and approval chains do not migrate. Twenty has a workflow builder for triggers, actions, and background jobs. FlitStack exports Backdocket workflow definitions as a JSON reference document for your Twenty admin to use during manual rebuild. Allocate 2–5 days for workflow recreation depending on rule complexity.