CRM migration
Field-level mapping, validation, and rollback between Marketing 360 and Twenty CRM. We move data and schema; workflows are rebuilt natively in Twenty CRM.
Marketing 360
Source
Twenty CRM
Destination
Compatibility
7 of 10
objects map 1:1 between Marketing 360 and Twenty CRM.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Marketing 360 to Twenty CRM is a structural migration from an all-in-one marketing platform to a focused open-source CRM. Marketing 360 uses a unified Contact object with assignees, tags, statuses, types, and custom fields; Twenty separates People and Companies as distinct objects, requires custom fields to be pre-created via the metadata API, and does not include a built-in payments layer. We sequence the Marketing 360 contact export across paginated API endpoints, resolve HubSpot-style assignee references to Twenty workspace members, and import contacts with their company associations using Twenty's Person and Company objects. The UXi website export produces XML content only—layout files and root-domain media assets are not portable and require rebuild. Automation journeys are not exposed via Marketing 360's public API and must be manually rebuilt in Twenty. We deliver a written inventory of active journeys and website content for the customer's team to address post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Marketing 360 object lands in Twenty CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Marketing 360
Contact
Twenty CRM
Person
1:1Marketing 360 Contact records map to Twenty Person. The src fields firstName, lastName, email, phone, and contactName map to the equivalent Twenty Person fields. The Marketing 360 customerId becomes a custom identifier field for cross-system reconciliation. We run assignee and company resolution before Person insert to satisfy any lookup requirements in Twenty's schema.
Marketing 360
Contact.organizationId
Twenty CRM
Company
1:1Marketing 360 Contacts with a populated organizationId link to the equivalent Marketing 360 Company record. We resolve this lookup at migration time by first extracting the full Companies list, then inserting Companies into Twenty as Company records, and finally linking each Person to the corresponding Company via the workEmail.domain match or an explicit companyLink field.
Marketing 360
Company
Twenty CRM
Company
1:1Marketing 360 Company records (exposed via organizationId on Contact) map to Twenty Company. The company name, domain, address fields, phone, and any custom fields migrate as typed fields on the Twenty Company object. We create the Company records first in the migration sequence so that Person records can reference them via lookup during import.
Marketing 360
Custom Fields
Twenty CRM
Custom Fields on Person / Company
lossyMarketing 360 exposes custom fields via a dedicated Custom Fields API with id-value pairs per contact. Twenty requires custom fields to be pre-created in Settings → Data Model before CSV or API import. We extract the full Marketing 360 custom field taxonomy during scoping, create matching custom fields in Twenty (with appropriate types: text, number, date, select, multi-select), and then import the values as part of the Person or Company record insert. Fields must exist before import; we handle this as a pre-import configuration step.
Marketing 360
Tag
Twenty CRM
Tag or Custom Multi-Select Field
lossyMarketing 360 Contacts carry a tags array with id and tag name. We extract the full tag taxonomy and apply tag memberships to migrated Persons in Twenty. Depending on tag usage (segmentation versus classification), we either create a tags custom field on Person or use a separate Tag approach. The customer selects the strategy during scoping based on how tags drive their workflow in Twenty.
Marketing 360
Assignee
Twenty CRM
WorkspaceMember
1:1Marketing 360 stores assignees as username, fullName, and email nested under Contact records. We extract the distinct assignee set and match by email against Twenty workspace members. Where no matching user exists, we hold the assignee in a reconciliation queue for the customer's admin to provision the Twenty user before record import resumes. Unresolved assignees are logged with the contact record for post-migration cleanup.
Marketing 360
Status and Type
Twenty CRM
Custom Picklist Fields on Person
lossyMarketing 360 uses arbitrary name-id pairs for contact Statuses and Types. We extract the full taxonomy from the API and map these to equivalent custom picklist fields in Twenty Person. The picklist values are created in Twenty's Data Model during the pre-import schema setup, and the migrated Status and Type values are applied to the Person records during import.
Marketing 360
Website Posts and Pages (UXi export)
Twenty CRM
External CMS
1:1The UXi export tool produces XML containing Posts, Pages, Testimonials, and Media. Layout files and theme assets are not included. We extract text content, categories, tags, and media URLs from the XML and deliver them as a structured export package for the customer's team to import into their chosen CMS (WordPress, Webflow, or another platform). We do not rebuild the website design or host the content ourselves.
Marketing 360
Testimonial
Twenty CRM
Note or Custom Object
1:1Marketing 360 Testimonials export via the UXi XML as structured records with author name, content, and media URLs. We extract these and deliver as a CSV or JSON package that the customer's team can import into Twenty as Note records linked to the relevant Person or Company, or into a custom Testimonials object if they choose to create one.
Marketing 360
Automation Journey
Twenty CRM
Workflow (manual rebuild)
1:1Marketing 360 automation and journey logic—trigger conditions, time delays, branch rules, and subscriber entry points—are stored in the platform's application layer and not exposed via the public REST API. We cannot migrate automated workflows automatically. During migration scoping we document all active journeys and provide a manual rebuild checklist mapped to equivalent workflow features in Twenty CRM. The customer's team rebuilds these post-migration.
| Marketing 360 | Twenty CRM | Compatibility | |
|---|---|---|---|
| Contact | Person1:1 | Fully supported | |
| Contact.organizationId | Company1:1 | Fully supported | |
| Company | Company1:1 | Fully supported | |
| Custom Fields | Custom Fields on Person / Companylossy | Fully supported | |
| Tag | Tag or Custom Multi-Select Fieldlossy | Fully supported | |
| Assignee | WorkspaceMember1:1 | Fully supported | |
| Status and Type | Custom Picklist Fields on Personlossy | Fully supported | |
| Website Posts and Pages (UXi export) | External CMS1:1 | Fully supported | |
| Testimonial | Note or Custom Object1:1 | Fully supported | |
| Automation Journey | Workflow (manual rebuild)1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Marketing 360 gotchas
UXi website export does not include layout files
Automation journeys are not accessible via API
Bulk contact export requires pagination over the CRM API
Payments configuration is outside the CRM data model
Twenty CRM gotchas
Import order is enforced and critical
Export limited to 20,000 records and visible columns only
Soft-deleted records count toward uniqueness and trigger restores
API rate limits cap at 200 req/min on Organization tier
No native email sequences — follow-up cadences require external tools
Pair-specific challenges
Migration approach
Discovery and data audit
We audit the Marketing 360 account across CRM records (Contacts, Companies, custom fields, tags, assignees, statuses, types), website content (Posts, Pages, Testimonials via UXi export), active automation journeys, and email subscriber lists. We extract the full custom field taxonomy and tag taxonomy from the Marketing 360 API. The audit output is a written migration scope covering record counts per object, schema mapping, UXi content inventory, and a journey inventory requiring manual rebuild. We also confirm the target Twenty deployment method (self-hosted Docker, Railway, Render, or twenty.com SaaS) since this affects API endpoint configuration.
Twenty schema setup
We create the destination schema in Twenty. This includes creating custom fields on Person and Company via Settings → Data Model (matching the Marketing 360 custom field types and picklist values), inviting workspace members who will correspond to Marketing 360 assignees, and verifying that all users have accepted their invitations before record import begins. The Twenty workspace must be fully configured with custom fields before any data import; fields do not auto-create during import. We set up the schema in a staging Twenty instance first for validation.
Pagination-based data extraction from Marketing 360
We extract CRM data from Marketing 360 using paginated API reads across Contact, Company, and engagement endpoints. For accounts with large record volumes, we run parallel workers with backoff to stay within undocumented rate limits. We validate record counts against the Marketing 360 UI after each extraction batch. UXi content export is run separately to produce the XML package of Posts, Pages, and Testimonials. Any automation journey definitions are documented via screen recording and manual inventory during this phase.
Data transformation and staging import
We transform the extracted Marketing 360 data into Twenty-compatible format. Contact records are split into Person and Company lookups where organizationId exists. Assignees are resolved by email match against Twenty workspace members, with unresolved assignees logged to a reconciliation queue. Custom field values are mapped to the pre-created Twenty custom fields. Status and Type taxonomies are mapped to custom picklist fields. We run a staging import into Twenty to validate record counts, spot-check field mapping, and confirm that Person-Company linking works correctly before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: Companies first (from Marketing 360 organization records), then Persons (linked to Companies), then custom field values applied per record. Each phase emits a row-count reconciliation report before the next phase begins. UXi website content is delivered as a structured export package for the customer's web team to import into their chosen CMS. The automation journey inventory document is delivered at this stage for the customer's team to begin manual rebuild.
Cutover, validation, and handoff
We freeze Marketing 360 writes during cutover and run a final delta migration of any records modified during the migration window. We validate record counts across all objects, spot-check Person-Company linking, and confirm that custom field values populated correctly in Twenty. We deliver the automation journey rebuild checklist and UXi content export package with a handoff call. We support a one-week hypercare window for reconciliation issues. We do not rebuild workflows or website designs inside the migration scope; these are documented for the customer's team to address separately.
Platform deep dives
Marketing 360
Source
Strengths
Weaknesses
Twenty CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Marketing 360 and Twenty CRM.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Marketing 360: Not publicly documented by Marketing 360.
Data volume sensitivity
Marketing 360 doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Marketing 360 to Twenty CRM migration scoping. Not seeing yours? Book a call.
Walk through your Marketing 360 to Twenty CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Marketing 360
Other ways to arrive at Twenty CRM
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.