Migrate from Empire SUITE to Twenty CRM

Empire Suite person records map to Twenty's People object. Email, phone, job title, and address fields migrate directly. If Empire Suite stores multiple email addresses per contact, the primary email maps to People.email and additional addresses are appended as text in a custom field.

Empire Suite company records map to Twenty's Companies object. Company name, domain/website, industry, employee count, and annual revenue migrate directly without requiring custom field creation. Parent-company relationships map to Companies' built-in relation field using the Twenty domainUnique rule to preserve organizational hierarchies.

Empire Suite deal records map to Twenty's Opportunities object. Deal name, amount, stage, and expected close date migrate directly. Pipeline-to-stage mapping requires value-by-value mapping if Empire Suite uses custom stage names that don't match Twenty's default pipeline stages.

Empire Suite's primary company assignment per contact maps to People.companyId lookup. If Empire Suite supports multiple company associations per contact, the primary association migrates as the People.companyId relation and secondary associations are stored as custom multi-select text to preserve the data.

Empire Suite custom entity types migrate to Twenty's Custom Objects. Before migration, each custom entity must be created in Settings → Data Model with equivalent field types. Relationships between custom entities and standard objects (People, Companies, Opportunities) map via Twenty's relation field type.

Empire Suite activity records (call logs, email records, meeting notes) are flattened into Twenty's Notes object and linked to the parent People or Companies record via Twenty's relation field. Original timestamps and owner assignments are preserved as Note metadata fields.

Empire Suite user records migrate as Twenty Workspace Members. Before migration, all users must be invited and accept their invitations in Twenty — Twenty's import UI cannot resolve owner references without pre-existing user records. FlitStack flags unmatched owner IDs before migration runs.

If Empire Suite stores project or case records as distinct entities, these migrate as a Twenty Custom Object named 'Projects' or 'Cases'. A relation field links each project record to its associated Companies and People records using the domain or email unique-key rule.

Empire Suite invoice and billing records have no native equivalent in Twenty CRM. These migrate as a Custom Object named 'Invoices' with relevant fields (invoice number, amount, date, status, linked company). Billing automation must be rebuilt in a dedicated accounting tool post-migration.

Empire Suite report and dashboard configurations do not migrate. Their underlying data (opportunities, activities, custom objects) migrates fully, but report layouts and chart definitions must be rebuilt in Twenty's dashboard builder after migration. FlitStack provides a data integrity check to confirm all source data arrived correctly in Twenty.

Empire Suite workflow rules (approval chains, conditional triggers, automated routing) do not migrate. They require manual rebuild in Twenty's workflow builder or via REST API. FlitStack exports workflow definitions as a JSON reference document for the rebuild phase.

Empire Suite file attachments on records migrate as Notes records in Twenty with a reference URL or embedded attachment. Twenty does not have a native file-storage object — files are re-hosted or the Notes record stores the source URL for retrieval.