Migrate from ELMA365 to Microsoft Dynamics 365 Sales

ELMA365 Projects that represent organizations or companies map to Dynamics 365 Account records using the Project Name as Account Name and the primary contact as a linked Contact. Projects that represent process containers with no CRM equivalent (internal initiatives, compliance workflows) map to a custom Project__c Dataverse table we provision before migration. The customer defines the mapping rule during discovery based on which ELMA365 Projects function as customer accounts versus internal process tracks.

ELMA365 Tasks map to Dynamics 365 Task records via the Dataverse task table. Title, Description, Due Date, Status, and Priority migrate directly. The Task's owning Project reference maps to the corresponding Account or custom Project__c record via a WhatId lookup we resolve at migration time. Assignee resolution uses email matching against the Dynamics 365 User table.

ELMA365 Process Instances carry state data and step status from BPM workflows. If the Process Instance represents a sales opportunity (deal tracking, deal stage), it maps to Dynamics 365 Opportunity with stage and estimated value fields populated from ELMA365 process variables. If the Process Instance represents a non-sales process (onboarding, procurement), it maps to a custom ProcessInstance__c table. The mapping rule is defined during discovery based on the customer's ELMA365 process taxonomy.

ELMA365 Custom Applications built in the low-code designer have no standard export format. We reverse-engineer the schema by parsing ELMA365's configuration export (requested from the customer's administrator) and map each Application table to a corresponding Dataverse custom table with typed columns, lookup relationships, and option-set fields. Custom table names preserve the ELMA365 Application name with alphanumeric characters only per Dataverse naming rules. We provision the destination schema in a Sandbox before production migration begins.

ELMA365 Users map to Dynamics 365 Users by email address as the reconciliation key. Role and department assignments from ELMA365 map to Dynamics 365 Security Roles and Business Units. Multi-tenant HUB user records from each subsidiary workspace are consolidated into a single Dynamics 365 org with Business Unit isolation applied based on ELMA365 tenant membership.

ELMA365 Documents attached to Tasks, Projects, or Process Instances are downloaded from ELMA365's file store and re-uploaded to Dynamics 365's SharePoint-integrated document management. Folder hierarchy from ELMA365 maps to SharePoint document libraries and folders under the parent Account or Opportunity. Document metadata (file name, created date, author) preserves via SharePoint column fields. Files without a resolved parent Account map to a general Documents library for manual reassignment post-migration.

Electronic HR document management artifacts from ELMA365 (employee records, e-signatures, HR contracts) migrate as files to a dedicated SharePoint HR Document Library in Dynamics 365. E-signature validity does not carry over and must be re-established in the destination platform per local legal requirements. HR document metadata (employee name, document type, date) populates SharePoint column fields for search and filtering.

ELMA365 connectors to SAP, Tantor DBMS, and other external systems store as configuration-level connection definitions. We document each connection endpoint, credential reference, and integration purpose during discovery and deliver a written integration map for the customer's IT team to rebuild as Dynamics 365 connections, Power Automate cloud flows, or Azure Logic Apps post-migration. Integration logic itself does not migrate.