Why the Marketo to Salesforce sync is the hardest part of leaving Marketo
If your renewal or a data residency requirement has pushed you to leave Marketo Engage, the Salesforce link is the dependency to plan first. Mautic, with its Salesforce plugin, is the main self-hosted option, but the sync must be re-designed, not copied. Marketo and Mautic handle lead ownership, field writes and campaign membership differently, so a field-for-field copy of today's behavior will usually create duplicates, overwritten values or sales alerts that fire at the wrong moment.
Marketo Engage is part of Adobe Experience Cloud, according to Adobe's Marketo Engage documentation. That placement matters for planning because your sales team probably experiences Marketo only through what lands in Salesforce: lead scores, lifecycle stages, campaign responses and task creation. Before you extract any data, document which Marketo-driven fields Sales reads daily, which Salesforce objects those fields sit on, and which team owns each rule. Confirm with your Salesforce administrator whether any triggers, flows or assignment rules depend on values Marketo writes.
The rest of this page covers three things: the direction each system writes data, the fields and campaign membership that need mapping, and how sales teams will notice when something has changed. Treat that work as a design exercise with named owners and a test plan, not as a configuration task. Ask any implementation partner for a written list of the sync objects, fields and sync directions that will be verified before cutover, and confirm the Mautic Salesforce plugin version and its configuration steps against the Mautic Salesforce plugin documentation for your target release.
What a sync replacement must preserve for sales
Marketo's Salesforce connector does more than copy records, so a replacement has to keep the lead data, ownership and campaign state that sales relies on. Each card below is a requirement to settle before cutover, and each one stays inside infrastructure your organization controls.
Field mapping for leads and contacts
Every Marketo field that sales sees on a Salesforce lead or contact needs a named counterpart in Mautic, with the data type and picklist values agreed in advance. Mautic's Salesforce plugin maps fields through its own configuration, so map each field to a documented destination and confirm which direction each one syncs. Check custom fields and date formats in a test org first, since silent truncation is a common cause of blank values in Salesforce.
Lead ownership and assignment
Sales expects a lead to land with the right owner, and Marketo often sets ownership through its sync rules and assignment logic. Document which rules decide owner, territory and queue today, then decide whether Mautic or Salesforce assignment rules take over. Ownership must have exactly one source of truth so records do not bounce between systems on each sync cycle.
Campaign membership and status
Salesforce campaign member statuses such as responded or attended tell reps what a prospect has done. List every Marketo program that writes to Salesforce, the statuses it sets, and the trigger for each. Mautic campaigns run through cron-driven triggers, so confirm that membership updates arrive on the timing your sales team expects.
Activity visibility on the Salesforce record
Reps rely on recent email opens, form fills and page visits appearing on the lead or contact timeline. Decide which Mautic activities must be written back to Salesforce, and which can stay in Mautic for marketers only. Test with a real rep account, because a sync that moves data but hides it from the timeline still looks broken to sales.
Duplicate handling
When the same person exists as a Mautic contact and a Salesforce lead, the sync needs a matching key, usually email, and a rule for which record wins. Agree the match rule, the merge direction and who reviews conflicts. Keep copies of the deduplication logic and its outcomes on your own servers, so the audit trail stays under your control.
Detecting a broken sync
A sync can stop without any error reaching the people who depend on it. Set up alerts on failed sync jobs, cron runs that do not complete, and gaps in record counts between the two systems, and log them in a place your operations team already monitors. Ask your sales operations lead to name the first three symptoms they would report, then wire alerts to those symptoms.
What Marketo syncs in each direction versus what Mautic's Salesforce plugin syncs
Your current Marketo to Salesforce behavior is the baseline for this migration, and it is set in your own instance. Record the configuration before anyone designs the replacement, because teams often remember the sync as simpler than its actual settings.
- Lead and contact records. Confirm which Marketo lead fields write back to Salesforce, which Salesforce fields write into Marketo, and which side wins when both change.
- Campaign membership and statuses. Confirm whether program or campaign member statuses flow to Salesforce, and whether sales-owned fields are ever overwritten by Marketo.
- Activity and scoring fields. Confirm whether scores, activity counts or last-activity dates are written to Salesforce and how often that happens.
- Object scope. Confirm whether custom objects or lead-to-account relationships are synced, and which record types are excluded.
- Filters and dedupe rules. Confirm the sync filters, deduplication rules and any operational triggers that depend on them.
Export a sample of records from each direction and keep the output as the acceptance reference for later testing.
Mautic documents a Salesforce plugin for integrating Mautic with Salesforce CRM, and its configuration is described in the Mautic Salesforce plugin documentation. Read the documentation for the Mautic version you plan to run, because plugin behavior can change between releases. Treat the plugin as a documented integration to test against your baseline, not as a copy of the Marketo sync.
- Documented scope only. Use the plugin documentation as the source for which objects and directions it covers, and record every gap against your Marketo baseline.
- Salesforce org version. Confirm object and field coverage for your specific Salesforce org version and edition before design, since support depends on what your org exposes.
- Connected app and credentials. Confirm how the Salesforce connection is authenticated and which integration user holds the permissions it needs.
- Custom fields and objects. Confirm whether your custom fields and objects are supported, and whether mapping requires configuration beyond the defaults.
- Sandbox testing. Run the plugin against a sandbox org and compare its results with the Marketo baseline before any production switch.
Write down every item you cannot confirm from the documentation and resolve it with your Salesforce administrator before go-live.
Direction matters more than volume. For each object, the migration team should state whether data moves from Marketo to Salesforce, from Salesforce to Marketo, or both, and who is allowed to change a value. Put that answer into a table with one row per field before mapping begins.
- One-way fields. Mark fields that only one system should write, such as a lead source set by marketing or an account owner set by sales.
- Two-way fields. Mark fields that both systems edit, and define the winning value and the timestamp rule used to resolve conflicts.
- Read-only fields. Mark system fields that should never be written back, such as record IDs and creation dates.
- Sync frequency. Record how often each direction runs in Marketo today, so the replacement schedule matches what sales expects.
- Owner per direction. Name one accountable person for each direction, on both the marketing and the sales operations side.
Compare the finished table with your Marketo configuration export and mark every difference as a decision to approve before go-live.
Campaign membership is where sales teams usually notice a sync change first. Marketo program membership and statuses shape what representatives see on a contact, so map each Marketo program and status to the Salesforce field or Mautic campaign outcome that carries the same meaning.
- Membership source. Confirm which Marketo programs and statuses are written to Salesforce today and which are used only inside Marketo.
- Status mapping. Map each status value to a Mautic campaign or segment outcome, and list any values that have no equivalent.
- Historical records. Decide whether existing membership history is written to Salesforce during migration or kept only in the archive.
- Multiple memberships. Check how contacts enrolled in several programs appear in Salesforce, since one record can carry many memberships.
- Sales reports. Identify which Salesforce reports and dashboards filter on membership, and test each one against the migrated data.
Give sales a sample of records from both systems side by side and ask them to confirm each campaign value they rely on before cutover.
How the sync breaks when campaign membership moves
Sales teams notice a broken sync first in two fields: lead status and campaign membership. When a lead that sales has been working shows the wrong status, or a campaign response stops appearing on the Salesforce record, reps stop trusting the data and start checking Marketo-equivalent views by hand. Lead source and lead owner are the next fields to fail. If a lead arrives in Salesforce with a blank or changed lead source, or with an owner set by a rule that no longer fires, assignment rules route it to the wrong queue or the wrong rep. The routing error is usually visible within a day, but the cause often sits in a rule that changed weeks earlier during the move.
Mautic does not run its campaigns, segments and sync the same way Marketo smart campaigns and the Marketo sync do. Mautic segments are rebuilt by cron jobs, and campaign updates and triggers also run on cron schedules that the Mautic documentation says should be staggered, so a contact can take longer to enter or leave a segment than a reader expects from Marketo. Membership in one system can therefore lag, or differ, from membership in the other at any given moment. Each Marketo smart list, trigger, flow step and sync rule has to be written down, matched to its Mautic equivalent, and tested with a known set of contacts. Do not assume that a rule with the same name behaves the same way.
Before cutover, ask the implementation team to produce a mapping sheet that lists each Salesforce field that Marketo writes, the Mautic field or campaign that replaces it, and the direction of the update. Confirm with the vendor and your own administrators which Salesforce objects the Mautic Salesforce plugin reads and writes, how it handles lead status and campaign membership, and what happens when both systems change the same record. Run both systems in parallel with a test segment of known contacts, and compare the lead status, source, owner and campaign membership in Salesforce after each cron cycle. Sales should sign off on that comparison before the old sync is switched off.
Which open-source options keep the Salesforce link
This table compares Mautic, listmonk and Dittofeed against the constraint of keeping a Salesforce link after leaving Marketo. Read the Mautic row first, since it is the only option with a documented Salesforce plugin, then use the other two rows to see where they fit as complements rather than sync replacements.
| Option | How it meets the constraint | What to confirm about CRM integration | Main trade-off |
|---|---|---|---|
| Mautic with Salesforce plugin | Documented Salesforce plugin integrates Mautic with Salesforce CRM, covering the lead and campaign data flows Marketo handled | Sync direction, which Salesforce objects and fields are mapped, how campaign membership and lead status map, and the plugin version against your Mautic release | Sync behavior differs from Marketo's, so field mapping and campaign membership need re-testing before cutover |
| listmonk for newsletter-only sends | Self-hosted newsletter and mailing list manager suited to sends without a CRM sync | Not a Salesforce integration. Confirm whether any lead or subscriber data must still flow to Salesforce by another route | Does not replace the Marketo to Salesforce lead sync, so it cannot keep CRM records current on its own |
| Dittofeed for event-driven journeys | Omni-channel platform for broadcasts and automated user journeys over email, push, SMS, WhatsApp and Slack | No native Salesforce sync in the supplied information. Confirm any Salesforce connection with the vendor or your own integration design | Does not replace the Marketo to Salesforce lead sync, so a custom integration would carry the sync work and its upkeep |
How to deploy Mautic and its Salesforce plugin inside your network
This sequence takes Mautic from an empty server to a tested Salesforce connection that runs alongside Marketo until the sales team is satisfied with the data, so the cutover is a controlled decision rather than a single switch.
Confirm the Mautic release and server versions
Your architect or platform lead selects the Mautic release line to deploy and checks its requirements on the Mautic releases page and the requirements page. Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, and Apache, Nginx or IIS, with npm needed from Mautic 5.0 onward. Confirm the security support window for the release you pick, and confirm the Salesforce plugin version is compatible with it. Done when a written version matrix is signed off by the security and platform owners.
Provision a VPS or dedicated server
The platform team builds a dedicated host inside your network or cloud account, sized with your database and mail volume in mind. The Mautic project states that it should not be installed on shared hosting and recommends a VPS or dedicated server. Restrict inbound access, place the database on the same private network, and keep backups of the database and the file system. Done when the server passes your hardening baseline and the team can reach the database from the application host only.
Install Mautic with Composer
The platform engineer installs Mautic using the Composer project template, which is the recommended method since version 4.0, or the production package with the web or command-line installer. Store configuration outside source control, record the installed version, and set up the web server virtual host with HTTPS. Done when the administrator can log in, the installed version matches your matrix, and the test contact can be created and viewed.
Schedule cron jobs in staggered order
Operations configures the cron jobs that Mautic depends on for segment updates, campaign updates and campaign triggers, plus the broadcasts command for segment emails. The Mautic documentation says these should be staggered rather than run at the same moment, so the team sets distinct start times and monitors overlap. Record each job in your scheduler inventory with its owner. Done when every job runs on schedule and logs show no overlapping or failed runs over a monitoring period you define.
Enable the messenger consumer for queued email
Operations starts the messenger consumer as a supervised service so queued emails are processed. Without it, emails queued by campaigns or broadcasts can sit unsent, which looks like a deliverability problem to marketing. Confirm how the consumer restarts after a server reboot and how its logs are collected. Done when a test campaign email leaves the queue and reaches a seed mailbox you control.
Configure the Salesforce plugin in a sandbox org
The Salesforce administrator creates a connected app and integration user in a sandbox org, then the Mautic administrator configures the Salesforce plugin using the Mautic Salesforce documentation. Test authentication, the sync direction for contacts, leads and campaign membership, and the handling of duplicate records. Document every object and field the plugin reads or writes. Done when test records sync in both directions as expected and the field map is approved by sales operations.
Map fields and campaign membership
Marketing operations maps Marketo fields, lead status, scores and program membership to Mautic fields, points and campaign membership, using the exported Marketo data as the reference. Compare the Salesforce field list with Marketo's sync settings to find any field that Marketo writes but the Mautic plugin does not. Record each gap and its decision. Done when every mapped field has a named owner and a test record shows the expected value in Salesforce.
Cut over after a parallel-run period
Run Marketo and Mautic side by side against the same Salesforce org for an agreed period, with sales reviewing lead routing and activity records in both. Only after sign-off, pause the Marketo sync, switch the production sync to Mautic, and keep Marketo read-only as a fallback until the team confirms the data is complete. Done when sales leaders accept the parallel results in writing and the cutover checklist is closed.
Questions teams ask before changing the Salesforce sync
What drives the cost of replacing the Marketo to Salesforce sync?
The cost depends mostly on how much of the sync has to be rebuilt, not on the license you stop paying. The main drivers are the number of mapped fields, how many custom objects and campaign-related records cross the boundary, how many Salesforce orgs or sandboxes are involved, and how much history must be moved. Each of these adds mapping, testing and reconciliation work. Mautic's Salesforce plugin is documented in the Mautic knowledge base, so the configuration effort depends on how far your org departs from standard objects. Ask any quote to itemize field mapping, custom object handling, number of orgs, sandbox testing, cutover support and post-cutover monitoring as separate lines, so you can see which drivers you are paying for.
How long does a Salesforce sync migration take?
The timeline is set by the number of objects and fields in scope, the number of teams that must sign off on field meanings, and how many test cycles run in a sandbox before production. No researched duration is available for this work, so treat any single number you hear with caution. A scoped plan should list the discovery of current Marketo sync behavior, the field and campaign membership mapping, a sandbox build, parallel reconciliation and a cutover window. Ask the quote to name the milestones and the dependencies on your Salesforce admin team, since those usually set the critical path.
What does our team need to provide before the work starts?
Three things unblock most sync projects: Salesforce admin access with rights to create integration users, fields and sync settings, a sandbox org that mirrors production closely enough to test real records, and named owners for each field and campaign status. Field owners matter because a field that looks the same in both systems often carries different meaning, such as lifecycle stage or lead source. Without owners, mapping decisions stall. Confirm with your Salesforce administrator whether sandbox refreshes are available and how often, and agree on who signs off on each mapped field before the engagement begins.
Can our internal team replace the sync without outside help?
Yes, a team with Salesforce administration skills, PHP and Mautic operations experience and cron and queue monitoring experience can do this in-house, and many do. The Mautic Salesforce plugin is documented, and the Mautic cron jobs documentation describes the background processes that must run reliably. The question is capacity and risk. Ask whether the people who know the current Marketo sync behavior will be available during discovery, whether anyone has run a cutover before, and who is on call when a sync batch fails after go-live. If those answers are uncertain, a fixed-scope engagement can cover the mapping, sandbox build and cutover, while your team keeps ownership of the result.
What happens to lead and contact ownership during cutover?
Ownership is the field most likely to break during cutover. Marketo-driven workflows often assign or update the Salesforce owner of a lead or contact, and Mautic will not inherit those rules automatically. Before cutover, document every rule that sets owner, the queue or round-robin logic behind it and the precedence when a record matches several rules. Then decide whether Mautic writes the owner, reads it from Salesforce, or leaves it to Salesforce assignment rules. Run a reconciliation in the sandbox that compares owners before and after a sample of records. Ask your quote to include that reconciliation and a rollback plan for owner changes.
How do we check that campaign membership still syncs correctly?
Campaign membership is where sales teams most often notice a problem. Map each Marketo program membership status to the equivalent Salesforce campaign member status before cutover, and agree on which Salesforce campaigns Mautic will write to. Then test a set of known contacts through each status change in the sandbox and confirm the expected membership appears in Salesforce. After go-live, compare counts of campaign members by status over several days against Marketo's last known figures. Any gap should be explained before the old sync is switched off.
How do sales teams notice that the sync has changed?
They usually notice through missing or duplicated activity on records, lead status that differs from what reps expect, and lead alerts that fire at different times. Set up a short watch list before cutover: sales leads for a few key accounts, daily counts of new leads and contacts, and the number of failed sync records. Tell sales managers which fields to check and how to report a mismatch. Ask your implementation partner to include a monitoring view in the scope, since silent failures are the most common source of lost trust in a new sync.
Evidence that the new sync works before sales relies on it
Sales leaders and auditors will ask the same question: how do you know the new Salesforce sync is right? Four artifacts answer it, each covering a different risk: mapping, data agreement, failure visibility and recovery. Prepare them before cutover, not after the first complaint from a rep.
Signed field mapping document
This is a table listing every Marketo field, its Mautic equivalent, its Salesforce target and the sync direction for each. Sales operations should sign it, because they own the lead status, owner and lifecycle fields that reps use daily. Check especially fields that Marketo writes back to Salesforce, such as score and program membership, since those need an explicit owner in Mautic.
Reconciliation report by count and owner
Compare lead counts, record owners and lifecycle stages between Marketo and Mautic, and between Mautic and Salesforce, for the same date range. Run the comparison on a sample of records and on the full population, and record every mismatch with its cause. Illustratively, a lead owned by one rep in Marketo but unassigned in Salesforce should appear as a named exception, not a silent difference.
Sync error logs and alerts
Keep logs of every failed create, update or upsert, with the record identifier, the field and the error message, and route them to a monitored channel. Mautic runs its sync through cron-driven jobs, so an unmonitored failed job can leave Salesforce stale without any visible sign. Confirm who receives alerts, how long logs are retained and what triggers escalation.
Documented rollback path
Write down how to pause the Mautic to Salesforce sync, restore Marketo as the source for affected fields and re-run a bounded set of records without creating duplicates. Test the procedure on a copy of the data before cutover. Name the decision owner who can trigger rollback, and agree the criteria in advance so the call is not made during an incident.
Independent review of the evidence
DeployOpen prepares the mapping, reconciliation, logs and rollback records, and can help the client organize them against the controls its auditors or internal assurance teams use. DeployOpen does not issue audit reports, attestations or certifications. Ask your auditor or assurance function early which evidence they expect, so the artifacts match their request.
How sales teams notice the change and what to tell them
Sales reps will notice the move first in Salesforce, so the message to them has to be settled before cutover. Under Marketo, the connector writes lead status, campaign membership and activity history back to Salesforce on a continuous basis. Under Mautic, the Salesforce plugin is configured with its own field mappings, sync direction and object scope, so what appears on a lead or contact record depends on the mapping you build, not on the old Marketo program structure. Before any rep sees a change, confirm which Salesforce objects Mautic will write to (leads, contacts, campaign members, or activity tasks), who owns the record when a lead is created in Salesforce versus Mautic, and whether lead status values will match the picklist sales already uses. Document the answers in the Mautic Salesforce plugin documentation and check them against your own configuration in a sandbox org.
The communication plan should tell reps what will look different and what will look the same. Expect changes in three places: campaign member entries, where the campaign names and member statuses come from your Mautic campaigns rather than Marketo programs; activity timelines, where email opens, clicks and form fills may appear with different wording or in a different order; and owner assignment, where any lead routing or ownership rule that depended on Marketo scoring needs to be reproduced in Salesforce or Mautic before the switch. Give reps a short written note covering the new campaign names, the lead status values that trigger follow-up, and a named contact in sales operations for questions. Run a short check with two or three reps on a test record before announcing the change to the wider team.
For the first weeks, watch a small set of fields rather than the whole record: lead status, lead source, the most recent campaign member status, last activity date, record owner, and any score or rating field your team uses for prioritization. Compare daily counts of new leads and converted leads in Salesforce with the same counts in Mautic, and investigate any gap that persists beyond a single sync cycle. Ask sales operations to log duplicate records, since a new sync direction is the most common cause of duplicated leads and contacts. Agree in advance which person decides to roll back a mapping change and how a rep reports a record that looks wrong. Illustrative example: if a rep sees a lead with no owner after a routing rule was removed, that is a mapping decision to fix in the same week, not a sales issue to resolve by hand.
How DeployOpen maps and tests the Salesforce sync under your constraint
DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, so the Marketo to Mautic move and its Salesforce connection are handled as one scoped piece of work. The sync is mapped and tested against your own Salesforce configuration before any cutover is agreed.
How we scope
- Written scope lists every Marketo sync direction, object and field that must keep working after cutover.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Scope names which Salesforce objects, campaign memberships and sales alerts are in and out of the sync.
How we build
- Field maps between Marketo lead fields and Salesforce fields are documented and reviewed with your sales operations owner.
- Campaign membership and lead status rules are rebuilt in Mautic and checked against sample records from your own org.
- The Mautic Salesforce plugin is configured in your environment, with cron jobs staggered and sync behavior tested end to end.
How we hand over
- Handover includes the field mapping, sync rules, cron schedule and an runbook for operating the integration.
- Test evidence records which sync paths were exercised, what passed and which items were accepted as known differences.
- Sales teams receive a short guide describing where lead ownership, scores and activity now appear in Salesforce.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover re-testing the Salesforce sync when Mautic releases a new version or your Salesforce configuration changes.
- Ask any provider to confirm in writing which Salesforce edition, API access and plugin version the sync is tested against.
