Migrate from ELMA365 to Twenty CRM

ELMA365 stores organizational records as Companies or Контрагент within its contact management module. These map directly to Twenty's Company object. The company name, website, industry classification, address fields, and any custom fields migrate as typed fields in Twenty. We use the company domain or unique identifier as the dedupe key during CSV import and resolve any missing required fields with customer-provided defaults during scoping.

ELMA365 contact records (name, email, phone, job title, assigned owner, department) map to Twenty's People object. Email serves as the primary dedupe key. Owner assignments in ELMA365 resolve to Twenty Users by email match during import. If a Contact has no email, we use a composite key from first name, last name, and company to avoid duplicate creation.

ELMA365 Projects are hierarchical work containers with tasks, dates, and resource assignments. Whether they map to Twenty Companies (if representing an organization unit) or a custom Project object depends on the customer's data model. We ask during scoping whether projects represent deliverables tied to accounts or standalone work units, and configure the destination schema accordingly before migration. MS Project-compatible XML export is read directly and mapped to the chosen Twenty object.

ELMA365 Tasks (title, description, due date, assignee, status, priority) map to Twenty Tasks. Status values are reconciled against Twenty's standard task status options during schema setup. Custom task fields defined in ELMA365's designer migrate as custom fields on Twenty's Task object.

Custom Applications built in ELMA365's low-code designer store data in proprietary table schemas that lack a standardized export format. We reverse-engineer each application's schema by extracting the configuration export, identifying field names, types, and relationships, then pre-create matching custom objects in Twenty's Data Model before importing. This is the most labor-intensive part of the migration for customers with complex custom applications. Custom relationships between applications map to Twenty's relation field types (single or multi).

ELMA365 Users and Employees (Сотрудник) export from the platform's directory with roles and department assignments. We match by email to Twenty Users. Role semantics differ: ELMA365's BPM-based permission model does not map to Twenty's Read/Edit/Delete permission matrix. We document role mappings during scoping and leave final permission configuration to the customer's admin post-migration.

Documents attached to ELMA365 tasks, projects, or custom applications are downloaded from ELMA365's file store and re-uploaded to Twenty's attachment storage, preserving folder hierarchy where supported. We map document metadata (name, created date, file type) to Twenty's attachment fields. Large binary files are chunked for download and upload with checksum validation.

Historical process instances from ELMA365 carry state data and step history. We extract instance fields (case ID, current step, timestamps, assigned user) and write them to a custom Activity Log object in Twenty rather than trying to force BPM process state into a flat CRM record. The customer decides during scoping whether archived process instances are migrated in full or summarized.

Electronic HR document management (Кадровый Электронный Документооборот) stores employee documents and e-signatures. We extract document files and metadata (employee name, document type, upload date) as Twenty file attachments. E-signature validity cannot be verified in Twenty; we flag this limitation and recommend the customer consult legal counsel regarding e-signature re-certification post-migration.

ELMA365 RPA robot definitions and automation configurations are proprietary to ELMA365's RPA engine and cannot be exported or re-imported into Twenty. We inventory every RPA robot during discovery and document it in the automation handoff report. The customer chooses to rebuild in Twenty's Workflow engine, retain ELMA365 for automation-only use, or accept manual process re-entry.

ELMA365 BPM workflow definitions (process steps, transitions, assignments, conditions) store as proprietary JSON/configuration. We export the process definition and document the workflow structure, but Twenty does not import BPMN format. Workflow definitions are delivered in the written automation inventory for the customer's admin to rebuild using Twenty's Workflow builder.

Reports and BI dashboards built in ELMA365's reporting engine do not migrate. We extract underlying data so reports can be rebuilt in Twenty's dashboards or a third-party BI tool. The data is preserved; the report definitions are not.