Migrate from ELMA365 to Pipedrive

ELMA365 Contacts map to Pipedrive People. The ELMA365 full name and contact details (email, phone, address) map directly. We extract the owner assignment and set the Pipedrive Person's owner_id via email-match against the destination User table. Any ELMA365 Contact without an email address is flagged during extraction and held in a reconciliation queue for the customer to resolve before import, since Pipedrive requires an email or name to create a Person record.

ELMA365 Company records map to Pipedrive Organizations. The company name becomes the Organization name, domain maps to the Website field, and industry or address fields map where ELMA365 has them populated. We create the Organization before any Person import so the Organization ID (org_id) is available as a lookup reference during Person insert. Deduplication is performed on domain and name during the transform phase.

ELMA365 Projects do not have a direct Pipedrive equivalent because Pipedrive is not a project management platform. We map ELMA365 Projects to Pipedrive Deals (one Deal per Project, with the Project name as Deal title and the Project description in the Deal summary field) and create a linked Activity record noting that this Deal originated from an ELMA365 Project. The customer chooses whether to map each Project to a single Deal or to multiple Deals per Project during scoping.

ELMA365 Tasks map to Pipedrive Activities of type task. Title, description, due date, assignee, and status transfer directly. We resolve the assignee by email match against Pipedrive Users. Status mapping depends on the ELMA365 task lifecycle: open tasks become open Activities, completed tasks become completed Activities with the original completion timestamp preserved in a custom field.

ELMA365 Process Instances (running or historical workflow executions) have no direct Pipedrive equivalent. We merge process instance data into the nearest corresponding Pipedrive Deal and append an Activity note summarizing the process state, step, and timestamp. If a Process Instance references a Contact or Company, we link the Activity to the matched Pipedrive Person or Organization. This is a scope decision during discovery because the denormalized mapping may not suit all business processes.

Custom Applications built in ELMA365's low-code designer store data in customer-defined tables. We reverse-engineer the schema from ELMA365's configuration export, identify which standard object each Application is logically attached to (Person, Organization, or Deal), and map Application fields to Pipedrive custom fields on those objects. Custom field types (text, number, date, picklist) map to their Pipedrive equivalents. This step requires schema extraction that may add one to two weeks of lead time if ELMA365's configuration export is not readily available.

ELMA365 Users are exported from the directory with name, email, role, and department. We match each ELMA365 User to a Pipedrive User by email. Users without a matching Pipedrive User are held in a reconciliation queue for the customer's admin to provision before record import begins. Role semantics differ — ELMA365 roles define process-level permissions while Pipedrive roles define CRM access levels — so we map role names to Pipedrive role identifiers and note any gap in the mapping workbook.

Documents attached to ELMA365 Tasks, Projects, or Process Instances are downloaded from the file store and re-uploaded to Pipedrive as Activity attachments. Folder hierarchy from ELMA365 is preserved as a flat Activity note referencing the original ELMA365 folder path. Files larger than 20 MB require chunked upload handling via Pipedrive's multipart file API. We do not migrate document version history beyond the latest version.

ELMA365 BPM workflow definitions are JSON configuration artifacts proprietary to ELMA365's automation engine. They do not export to a portable format. We document every workflow definition during discovery — its trigger, steps, transition logic, assignee rules, and SLA timers — and deliver a written inventory recommending how to reproduce each workflow in Pipedrive's Automation section. The customer's admin rebuilds these post-migration.

ELMA365 RPA robot configurations are proprietary automation artifacts that cannot be exported and re-imported into Pipedrive. We flag every RPA robot during discovery and document its function (data entry, screen scraping, system integration) with a recommendation for replacement: Pipedrive native Automation, a Zapier/Make integration, or a dedicated RPA platform. This is a scope conversation with the customer before migration begins.