CRM migration
Field-level mapping, validation, and rollback between Mautic and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Mautic
Source
Salesforce Sales Cloud
Destination
Compatibility
8 of 13
objects map 1:1 between Mautic and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
5-7 weeks
Overview
Moving from Mautic to Salesforce is a migration from a standalone marketing-first platform to a CRM-first ecosystem. Mautic organizes data around Contacts with a built-in CRM layer; Salesforce separates Leads and Contacts and expects Accounts as the organizational parent. We resolve that structural difference during scoping by defining the lifecycle-stage-to-Lead-or-Contact split rule before any data moves. We bypass Mautic v6's broken CSV export by reading contact and company data directly from the MySQL/MariaDB database, work around the index-per-table limits that throttle large contact databases, and resolve the Custom Object relationship gaps by accessing junction tables directly. Campaigns and Segments migrate as Salesforce Campaigns with membership history preserved; Stages and Points map to Salesforce Lead Status and a custom lead score field. Workflows, Sequences, landing pages, and Reports do not migrate; we deliver a written inventory of every active automation and page that requires rebuild in Salesforce Flow, Experience Cloud, or a dedicated marketing implementation partner.
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 Mautic object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Mautic
Contact
Salesforce Sales Cloud
Lead or Contact (split required)
1:manyMautic Contacts with lifecycle stage of subscriber, lead, or marketing qualified lead map to Salesforce Lead. Lifecycle stage of sales qualified lead, opportunity, customer, evangelist, or other maps to Salesforce Contact tied to an Account. We compute the split using Mautic's stage and lead_status properties at migration time, preserve the original Mautic lifecycle stage in a custom field stage__c on both Lead and Contact for audit, and set the Salesforce Lead Status picklist to a value derived from the Mautic stage name. All custom contact fields migrate as typed Salesforce fields with __c suffixes.
Mautic
Company
Salesforce Sales Cloud
Account
1:1Mautic Company records map directly to Salesforce Account. The company domain maps to the Account Website field and serves as the dedupe key during import. We resolve Mautic's many-to-one contact-to-company relationship by creating Account first, then setting AccountId on each Contact at insert time. Any company phone, industry, revenue, and address fields map to the equivalent Account fields.
Mautic
Campaign
Salesforce Sales Cloud
Campaign + CampaignMember
1:1Mautic Campaign definitions (name, description, start and end dates, campaign type) map to Salesforce Campaign records. Campaign membership (which Contacts entered which Campaigns and when) migrates as Salesforce CampaignMember records linked by CampaignId and ContactId or LeadId. The CampaignMember Status field maps from Mautic's campaign membership status. We resolve the Contact-to-Campaign membership through the Mautic_leads_campaign_leads junction table accessed directly from the database.
Mautic
Segment
Salesforce Sales Cloud
Campaign (informational)
lossyMautic Segments are dynamic contact lists filtered by field values, tags, and behavioral conditions. We export the segment filter definitions as structured JSON and attach them to a Salesforce Campaign record's description field. The segment membership itself is not re-imported as CampaignMembers because Salesforce recalculates dynamic membership differently; the filter definition serves as a rebuild reference for the customer's admin to reconstruct as a Salesforce Campaign or a filtered Report.
Mautic
Stage
Salesforce Sales Cloud
Lead Status or custom field
1:1Mautic Stages define contact lifecycle positions (Lead, MQL, Customer, etc.) and are stored in the Mautic lead stages table. We map each Mautic stage name to a Salesforce Lead Status picklist value (for Lead records) and preserve the full stage name in a custom text field stage__c on Contact for reference. If the destination Salesforce org uses a custom stage model for Contacts, we align to that instead.
Mautic
Points
Salesforce Sales Cloud
Lead Score (custom field)
lossyMautic's Points system scores contacts based on actions (page visits, form submissions, email opens, manual adjustments). We map the Mautic Points integer value to a custom Number field on the Salesforce Lead or Contact record named lead_score__c. Point Groups (thresholds that trigger stage changes) are documented as Salesforce Flow entry conditions or assignment rules for the customer's admin to rebuild.
Mautic
Tag
Salesforce Sales Cloud
Multi-Select Picklist or custom tag field
lossyMautic Tags are flat string labels applied to contacts and other objects. Tags with fewer than 150 unique values migrate to a Salesforce multi-select picklist on Contact or Lead. Tags exceeding 150 unique values migrate to a custom text field tag_list__c storing comma-separated values, or to Salesforce Topics with TopicAssignment records if the customer licenses the Topic model. Tag-based segmentation logic is preserved as a filter definition attached to the relevant Campaign or Report.
Mautic
Custom Object
Salesforce Sales Cloud
Custom Object (__c)
1:1Mautic Custom Objects extend the data model beyond standard contacts and companies. Relationships between custom objects use junction tables in Mautic's MySQL schema (the Relationships API is documented as broken). We access the junction table records directly from the database, pre-create the destination Salesforce custom object schema with all custom fields and lookup relationships, then import the custom object records with foreign key references resolved to Salesforce record IDs at migration time. Custom object naming uses the __c suffix per Salesforce convention.
Mautic
Asset
Salesforce Sales Cloud
ContentDocument
1:1Mautic Assets are downloadable files (PDFs, guides, media) stored as binary blobs in the Mautic database or filesystem. We export asset metadata (filename, title, description, download count, storage path) and create Salesforce ContentDocument records with the file stored as ContentVersion. The asset's download URL is preserved as an external link on the ContentDocument if the Mautic instance remains accessible post-migration.
Mautic
Landing Page
Salesforce Sales Cloud
Campaign (rebuild reference)
1:1Mautic Landing Pages are standalone web pages with theme assignments and tracking configuration. We export page content, URL slugs, theme names, and form embedding configurations as a structured reference document. Landing pages do not migrate as functional pages because Salesforce does not have a native landing page builder in Sales Cloud. We recommend Salesforce Experience Cloud, Marketing Cloud Landing Pages, or a CMS partner (Contentful, Webflow) as the replacement, and we provide the content export in a format suitable for re-import.
Mautic
User
Salesforce Sales Cloud
User
1:1Mautic Users map to Salesforce User records by email address match. We extract all Mautic user records including role names, role permissions, and ownership assignments during scoping. User provisioning in the destination Salesforce org is a separate manual step the customer's admin completes before record migration, because active Salesforce Users must exist before OwnerId references can be resolved on Contacts, Leads, Accounts, and Opportunities.
Mautic
Category
Salesforce Sales Cloud
Topic or custom field
lossyMautic Categories group assets, campaigns, emails, and contacts into a hierarchical folder structure. We export the full category hierarchy as a JSON tree and reassign it to Salesforce Topics (Topic model) or to a custom text field category_path__c on each migrated record, depending on the destination org's data model complexity.
Mautic
Engagement: Email
Salesforce Sales Cloud
EmailMessage + Task
1:1Mautic email engagement records (sends, opens, clicks, bounces) map to Salesforce EmailMessage records linked to a Task record on the contact or lead timeline. The email content, send timestamp, and engagement metrics (open count, click count) preserve as Salesforce fields. For Mautic emails linked to a Mautic Campaign, we create a Salesforce CampaignMember record if the contact maps to a Lead or Contact with a corresponding Salesforce Campaign.
| Mautic | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Contact | Lead or Contact (split required)1:many | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Campaign | Campaign + CampaignMember1:1 | Fully supported | |
| Segment | Campaign (informational)lossy | Fully supported | |
| Stage | Lead Status or custom field1:1 | Fully supported | |
| Points | Lead Score (custom field)lossy | Fully supported | |
| Tag | Multi-Select Picklist or custom tag fieldlossy | Fully supported | |
| Custom Object | Custom Object (__c)1:1 | Fully supported | |
| Asset | ContentDocument1:1 | Fully supported | |
| Landing Page | Campaign (rebuild reference)1:1 | Fully supported | |
| User | User1:1 | Fully supported | |
| Category | Topic or custom fieldlossy | Fully supported | |
| Engagement: Email | EmailMessage + Task1: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.
Mautic gotchas
Mautic v6 CSV export silently fails to deliver files
Mautic 4 to 5 upgrade breaks plugins without warning
MySQL/MariaDB index limits throttle large contact databases
Custom Object Relationships API is non-functional
Mautic 5 to 6 migration logs no errors on failure
Salesforce Sales Cloud gotchas
Workflow Rules and Process Builder are retired
Bulk API batch quota exhaustion during large imports
Storage overage billing is non-obvious
Account-Contact many-to-many relationship mapping
Territory and team member import ordering dependencies
Pair-specific challenges
Migration approach
Discovery and source audit
We audit the source Mautic instance across version (v4, v5, or v6), hosting model (self-hosted or Mautic Cloud), contact volume, custom field count, custom object count and their relationship structures, campaign count and membership volumes, segment filter definitions, active user count, and any installed plugins with Salesforce sync configurations. We confirm the destination Salesforce edition (must be Enterprise or higher for REST/Bulk API access) and identify any custom objects or junction tables in the Mautic MySQL schema that require direct database access. The discovery output is a written migration scope with object inventory, estimated row counts per object, and a confirmed Lead-versus-Contact split rule.
Source data extraction bypassing v6 export
We extract contact, company, campaign membership, stage, points, tag, custom object, and user data directly from the Mautic MySQL/MariaDB database using authenticated read access, or through batched REST API calls with pagination. We bypass the broken Mautic v6 CSV export entirely. For custom object relationships, we read junction table records directly from the database schema and reconstruct the relationship graph for Salesforce. We profile the database for index usage and flag any tables approaching MySQL's 64-index limit before extraction. We take a full filesystem and database snapshot before any extraction to enable rollback of the source instance if needed.
Destination schema design and provisioning
We design the Salesforce destination schema in a Sandbox org before production migration. This includes provisioning custom objects with __c API names, custom fields with type-mapped Salesforce field types, Record Types for any Mautic pipeline equivalents, Sales Processes for stage whitelists, and page layouts per Record Type. We create the lead_score__c numeric field for Mautic Points, the stage__c text field for original lifecycle stage preservation, and any multi-select picklists for Mautic Tags exceeding 150 unique values. Schema is deployed via Salesforce Metadata API or change set into the Sandbox first for validation.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using production-like data volume. The customer's RevOps lead reconciles record counts (Leads in, Contacts in, Accounts in, Campaigns in, CampaignMembers in, custom objects in), spot-checks 25-50 random records against the Mautic source, and validates the Lead-Contact split rule against the lifecycle stage matrix. Any field mapping corrections, custom object schema adjustments, or split rule refinements happen here in Sandbox before production migration begins. We also validate that Salesforce validation rules and field-level security do not reject records during the Sandbox run.
User provisioning and owner reconciliation
We extract every distinct Mautic user referenced on Contact, Company, Campaign, and Engagement records and match by email against the Salesforce destination org's User table. Users without a matching Salesforce User go to a reconciliation queue. The customer's Salesforce admin provisions any missing Users (active or inactive depending on whether the original Mautic user is still active) before production migration. OwnerId references on Contacts, Leads, Accounts, Opportunities, and Campaigns require resolved Users before record insert can proceed.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Mautic Companies), Leads and Contacts (with the lifecycle stage split applied and AccountId resolved on Contacts), Campaigns (with campaign definitions and dates), CampaignMembers (linked by resolved LeadId and ContactId), custom objects (with lookup relationships resolved to Salesforce record IDs), engagement history via Bulk API 2.0 (Tasks, Events, EmailMessages, Notes), Assets as ContentDocument records, and Tags as multi-select picklists or custom fields. Each phase emits a row-count reconciliation report before the next phase begins. We use Bulk API 2.0 with batch chunking, parent-record lookup resolution, and exponential backoff on API limit responses for activity history.
Cutover, delta sync, and rebuild handoff
We freeze Mautic writes during cutover, run a final delta migration of any records modified during the migration window, then enable Salesforce as the system of record. We deliver the automation and landing page inventory document listing every Mautic Workflow, Sequence, landing page, and report with a recommended Salesforce equivalent (Salesforce Flow, Experience Cloud, Marketing Cloud Landing Pages, or a CMS partner). We support a one-week hypercare window for reconciliation issues. We do not rebuild Mautic Workflows as Salesforce Flow inside the migration scope; that is a separate engagement.
Platform deep dives
Mautic
Source
Strengths
Weaknesses
Salesforce Sales Cloud
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 Mautic and Salesforce Sales Cloud.
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
Mautic: Not publicly documented — enforced at the server level, not within Mautic software.
Data volume sensitivity
Mautic 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 Mautic to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Mautic to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Mautic
Other ways to arrive at Salesforce Sales Cloud
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.