Migrate from eMarketeer to Twenty CRM

eMarketeer Contacts map directly to Twenty CRM People records. Email, name fields, phone, and any custom properties migrate to corresponding Twenty custom fields. Custom property schema is derived during discovery since eMarketeer lacks a public field registry. All fields must be created in Twenty Settings → Data Model before import begins. Source record IDs are preserved as a legacy ID field for deduplication and audit.

eMarketeer account-level data (if present) maps to Twenty CRM Company records. Companies are imported before People so that the relationship lookup is satisfied at People insert time. Domain and address fields map directly. If eMarketeer does not have an explicit Company object, contacts are still mapped to People with a Company field value that we use to either link to an existing or create a new Company record during migration.

eMarketeer Campaigns (email and multi-channel sends) do not have a native equivalent in Twenty CRM's sales model. We map campaign metadata (name, subject, send date, recipient count) to a Note record attached to the relevant People records, and if the campaign relates to a sales deal, we create an Opportunity with campaign details for pipeline attribution. Open and click metrics migrate as Note activity entries with timestamp.

eMarketeer segments are defined by real-time criteria rules that re-evaluate continuously. Twenty CRM has no live segment engine, so we snapshot current segment membership at migration time and create a static People list in Twenty. We preserve the segment name and criteria description in a Note for the customer admin to reference when rebuilding manual filters. Segments with complex multi-condition rules may result in multiple static list snapshots if criteria cannot be fully resolved.

eMarketeer Flows (automation sequences with trigger-action logic) do not migrate as code. We audit every active flow during discovery, document its trigger type, conditions, delay steps, and actions, and deliver a written inventory with recommended Twenty equivalents. The customer admin rebuilds flows in Twenty or a connected automation tool. Flows with unsupported trigger types (CRM event triggers, for example) are flagged explicitly for manual rebuild.

eMarketeer Events (registrations and attendance tracking) map to Twenty CRM Task records with event metadata stored in custom fields. Registration status, attendee count, and event date migrate as task fields. If the customer needs a richer event model, we create a Custom Object for Events and migrate records there; this requires pre-creation of the custom object schema in Twenty before import.

eMarketeer email engagement history (opens, clicks, unsubscribes per contact per campaign) aggregates into a Note attached to the relevant People record in Twenty CRM. Each Note captures the engagement type, campaign name, timestamp, and metric value. Twenty CRM does not have a native email engagement object, so the aggregated Note format preserves historical engagement data for reference without creating separate objects.

SMS send history from eMarketeer flows migrates as Note records attached to People. SMS content and send metadata transfer; delivery receipts and opt-out states reconcile against the destination system post-migration. If the customer plans to use a separate SMS integration with Twenty, the SMS content Notes provide a reference for rebuilding send sequences in that tool.

eMarketeer custom properties on Contacts and Campaigns map to Twenty CRM custom fields on People and Opportunity objects. Property types (text, number, date, dropdown) map to equivalent Twenty field types. Enumerations and default values require explicit mapping during scoping since picklist options in Twenty must be created in Settings before import. Schema derivation happens from the export during discovery since eMarketeer has no public field registry.

eMarketeer form definitions and embedded layouts are not reliably exportable. We do not migrate forms as data. We export the contact records and use those as reference for field mapping when the customer rebuilds forms in their chosen replacement tool (Twenty-compatible form builder or custom integration). Form field labels and submission data that exist in contact records migrate as part of the People record.