Migrate from Evam to Twenty CRM

Evam Customer records map directly to Twenty CRM Person objects. Standard profile fields (name, email, phone, demographic attributes) migrate 1:1. Custom customer properties defined beyond Evam's standard schema migrate as custom fields on the Person object in Twenty. We use the customer email address as the dedupe key during import to prevent duplicate Person records. The migration user must have write access to the Person API in the target Twenty instance.

Behavioral and transactional Events in Evam are the highest-risk migration object. Evam's event stream stores timestamps, payload schemas, and triggering rules; however, the raw volume (potentially billions of touchpoints) makes full export impractical. We scope the event export to a defined time window (typically the last 90-180 days) agreed during scoping, preserve the full event sequence per Customer, and migrate Events as Task records in Twenty or as a custom Event object if the customer requires the payload schema preserved. Older events are aggregated or sampled to keep migration scope manageable.

Evam Segments are customer groupings used to filter journey entry and campaign targeting. Segment membership criteria (rule sets or filter configurations) export as condition trees. We preserve the membership criteria in a written Segment inventory document that the customer's admin uses to recreate filter groups in Twenty's list view or as a custom picklist field on Person. Active Segment membership (the current list of Customers in each Segment) migrates as tag values or custom multi-select fields on Person records.

Evam Campaigns attached to journey steps or run independently migrate as Task records in Twenty with campaign metadata (name, status, start/end dates, channel assignments) stored in custom fields. Campaign performance metrics (open rates, click rates, conversion rates) are derived post-migration in Twenty's reporting layer or a connected analytics tool. We preserve the Campaign-to-Customer association as a Task linked to the Person record.

Evam Journeys encode step sequences, branch conditions, wait timers, and entry/exit rules. Journey definitions are not exposed via a documented export endpoint. We use API snapshots and manual documentation during discovery to capture journey topology and produce a written inventory of every active Journey with its trigger, conditions, step sequence, channel actions, and wait logic. The customer's admin rebuilds this in Twenty using available automation tools or external workflow platforms. We do not migrate Journey logic as executable code.

SMS sender IDs, push notification credentials, and in-app notification configurations are bound to Evam's registered application environment and cannot be transferred. We document the full channel configuration during discovery — including provider names, credential types, sender IDs, and webhook URLs — and deliver a re-setup checklist so the customer's operations team can re-register credentials in Twenty or a connected channel platform before cutover.

Evam's AI-based propensity scores are computed per-customer within Evam's runtime environment and are not accessible via the documented API. We cannot migrate these scores directly. Customers relying on AI-driven routing in Journeys should plan to re-run scoring in the destination platform post-migration, integrate an external scoring tool, or accept a scoring-free reset on day one. We flag this as a pre-migration decision point during scoping.

Extended properties on Customers, Events, or Journeys defined by the customer beyond Evam's standard schema migrate field-by-field. We map each custom field to a corresponding custom field in Twenty, noting data type compatibility (text, number, date, picklist, multi-select, relation). Custom fields on Events require the custom Event object or Task custom fields to be provisioned in Twenty before event import begins.

Evam Owner records map to Twenty CRM workspace Users. We resolve by email match. Any Evam Owner without a matching Twenty User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

If the Evam instance stores organizational data alongside Customer records, Company objects map directly to Twenty CRM Company. The Company domain or name becomes the deduplication key. Company records are created before Person import so that the Person-Company relationship is satisfied at the moment of Person insert.