Migrate from ELMA365 to Salesforce Sales Cloud

ELMA365 User records serve both employee directory and CRM contact functions. Users with ELMA365 logins who are also customers or external stakeholders map to Salesforce Contact; internal-only employees map to Salesforce User. We extract the full user directory, classify by role type and email domain, and apply the split during migration. Email addresses serve as the dedupe key for Contacts and the match field for Users.

ELMA365 Company records map directly to Salesforce Account. The company name becomes Account Name, and any registered business address migrates to BillingAddress. Account is created before any Contact import so that the AccountId Lookup is satisfied at the moment of Contact insert. If the ELMA365 instance uses HUB multi-tenancy with subsidiary-level companies, we map each subsidiary's companies to separate Account hierarchies or top-level Accounts depending on the customer's Salesforce sharing model.

ELMA365 Projects require a scope decision during discovery. If Projects represent customer accounts or external organizations, they map to Salesforce Account. If Projects represent internal work packages, initiative tracks, or deliverables tied to Accounts but not equivalent to Accounts, we map them to a Salesforce Custom Object (Project__c) with a Lookup to the relevant Account. The customer's project governance model drives this decision during scoping.

Standard ELMA365 Tasks with title, description, due date, assignee, and status map to Salesforce Task. Tasks linked to Projects map via WhatId to the corresponding Account or Project__c Custom Object. Tasks that represent project deliverables with custom fields beyond the standard Task schema are evaluated for migration to Task__c or a dedicated Custom Object with a Lookup to Account and Contact.

Running and historical Process Instances carry state data, step status, and instance-level fields. We extract instance fields and current step name into a Process_Instance__c Custom Object with a Lookup to the originating Account or Contact. If the customer uses ELMA365 for service ticket management, Process Instances may map to Salesforce Case instead, with ELMA365 process steps mapping to Case Status values or custom status picklists.

Applications built in ELMA365's low-code designer store data in custom-defined tables with no standardized export format. We reverse-engineer the schema by extracting ELMA365's configuration export (obtained from the customer during discovery), parsing the field definitions, data types, and lookup relationships, and creating equivalent Salesforce Custom Objects with __c API names. We pre-create the destination schema before any data import. The number of custom Applications and their field complexity are the primary drivers of scoping complexity.

Each field in an ELMA365 Custom Application maps to a Salesforce Custom Field on the corresponding Custom Object. Field types are mapped: ELMA365 text to Text(255) or Long Text Area, ELMA365 number to Number, ELMA365 date to Date, ELMA365 lookup to Lookup relationship, ELMA365 file attachment to ContentDocumentLink. Required fields in ELMA365 become Required fields in Salesforce only if historical data satisfies them; otherwise they are created as Optional during migration.

Documents attached to Tasks, Projects, or Process Instances in ELMA365 are downloaded from ELMA365's file store and re-uploaded to Salesforce's ContentWorkspace or as Attachments on the parent record. Folder hierarchy is preserved where ELMA365 exposes it via API or XML export. Files are uploaded before parent record migration to ensure ContentDocumentLinks resolve correctly.

ELMA365 roles and department assignments are mapped to Salesforce Profiles and User Roles during scoping. Role semantics differ: ELMA365 roles govern BPM process assignments and access, while Salesforce roles govern record visibility in hierarchies. We document the mapping and recommend that the customer configure Salesforce sharing rules and hierarchy roles post-migration to approximate the original ELMA365 access model.

Electronic HR document management (Кадровый Электронный Документооборот) in ELMA365 stores employee documents and e-signatures. We extract document files and metadata (employee name, document type, date) and attach them to the corresponding Salesforce Contact record. E-signature validity cannot be transferred; documents are migrated as files and the customer's legal team must re-establish e-signature compliance in Salesforce or a connected e-signature tool.

ELMA365 connectors to SAP, Tantor DBMS, Telegram, and WhatsApp are configuration-level settings with no migration path to Salesforce. We document each active connection endpoint, credential references (documented without exposing secrets), and data flow direction. The customer rebuilds these integrations in Salesforce using AppExchange connectors, MuleSoft Composer, or custom Apex integrations post-migration.

ELMA365 reports and dashboards use the platform's native reporting engine and cannot be exported and re-imported into Salesforce Reports or Einstein Analytics. We deliver a written inventory of every ELMA365 report with its filters, groupings, and data sources, plus the underlying migrated data so that the customer's Salesforce admin or a reporting consultant can rebuild equivalent reports post-migration.