Account Engagement+ or Mautic: which path keeps the work you need?
If your team runs B2B campaigns in Account Engagement and Salesforce CRM, the decision in front of you at renewal is narrower than the sales conversation makes it look. You are choosing between staying in a Salesforce-hosted edition, including the Account Engagement+ and Marketing Cloud Next options Salesforce is promoting, and self-hosting Mautic alongside the CRM you already run. Both paths keep prospect data flowing into Salesforce, but they differ on who hosts the marketing database, who pays for each component and how much rebuilding the work requires. This page compares the edition costs, the migration work and what each path keeps, including scoring, grading, nurture programs, reporting and the link back to CRM. On the Mautic side, the connection to Salesforce runs through the Salesforce plugin documented in the Mautic Salesforce plugin documentation, so the plugin's configuration and upkeep belong in your comparison from the start.
Before you treat any upgrade quote as the baseline, confirm the details of Account Engagement+ and Marketing Cloud Next with Salesforce against your own contract. Ask for the contact or prospect limits, API access, included integrations, sandbox rights and data retention terms in writing, and ask which features are exclusive to each tier. Salesforce's product pages and your account team are the authoritative sources here, and this page does not state their prices or limits. For the Mautic path, list what you would run yourself: hosting on a VPS or dedicated server rather than shared hosting, email sending, cron jobs for segments and campaigns, the Salesforce plugin and the staff time to operate them. Price each component separately, and note which costs are one-time migration work and which recur every year.
What the constraint requires from a marketing automation platform
Four tests decide whether a move away from Account Engagement keeps control of your data and your options. Each card below turns one test into a question you can put to Salesforce, to a Mautic partner or to your own team before committing to a path.
Confirm who owns the database
Mautic is free to self-host on your own database, so the contact, activity and scoring records sit in a database your organization runs. Under Account Engagement, prospect and activity data live in Salesforce's hosted service. Before choosing a path, ask who holds database administrator rights, where backups are stored, which region hosts the data, and who can restore it. The owner of the database is the owner of the records, so write that answer into the decision memo.
Read the license terms
The Mautic repository is licensed under GPL-3.0, and the LICENSE.txt file in the repository sets the terms. Legal teams should read that file themselves and confirm how the license applies to any custom plugins, themes or connectors your integrator writes. The license governs use and redistribution of the software, so it does not change what Salesforce's own subscription terms say about the Account Engagement service you are leaving.
Test the CRM integration path
Mautic connects to Salesforce CRM through its documented Salesforce plugin, which is configured as described in the Mautic knowledge base. Account Engagement connects natively to Salesforce. Ask your team to map every field, lead and contact status, and campaign membership that sync today, then check each one against the plugin's documentation. Test sync direction, duplicate handling and error reporting in a sandbox before any production cutover.
Plan the export for any exit
Whatever path you choose, plan how data leaves the current system. Mautic imports contacts from CSV through its user interface with automatic column to field mapping, and recommends background imports via the mautic:import console command run by cron for large files, processed in batches of 100 rows by default. Account Engagement data leaves through its export path, which needs its own review. Ask for a full export, a test import into a staging Mautic, and a reconciliation of record counts before the old system is turned off.
How Account Engagement+, Marketing Cloud Next and Mautic compare
This table sets the Salesforce-hosted upgrade paths against self-hosted Mautic connected to Salesforce CRM across data ownership, CRM integration, contract control and operating work. Edition names, prices and feature availability change, so confirm them against your own Salesforce order form before deciding. The main takeaway is that the upgrade keeps native Salesforce depth, while Mautic trades that depth for control of data, licensing and the platform itself.
| Dimension | Account Engagement+ | Marketing Cloud Next | Self-hosted Mautic with Salesforce CRM |
|---|---|---|---|
| Data ownership | Data is held in Salesforce-managed services under your Salesforce agreement | Data is held in Salesforce-managed services under your Salesforce agreement | Data sits in your own database and servers, where you control backups and retention |
| CRM integration | Native integration with Salesforce CRM, maintained by Salesforce | Native integration with Salesforce CRM, with Salesforce-defined data model | Connected through the Mautic Salesforce plugin, which your team configures and maintains |
| Edition and contract control | Edition, contact limits and renewal terms set by Salesforce; confirm in your order form | Newer product with terms set by Salesforce; confirm availability and pricing in your order form | Mautic is free to self-host under GPL-3.0; your costs are hosting, sending and staff time |
| Upgrade path | Salesforce directs customers toward this edition; confirm migration terms and timing with your account team | Salesforce positions this as its next product; confirm migration scope with your account team | Mautic publishes monthly patches, quarterly minor releases and a two-year major cadence, so you schedule upgrades |
| Native Salesforce depth | Strongest fit for teams that rely on Salesforce-native reporting, scoring and lead handling | Broadest Salesforce ecosystem scope, with more features bundled into one platform | Depth depends on plugin coverage; confirm which objects, fields and sync rules you need before committing |
| Operating work | Salesforce administers the platform; your team manages configuration and user access | Salesforce administers the platform; your team manages configuration and governance | Your team runs hosting, cron jobs, email delivery, security patching and plugin upkeep |
| Best fit | Teams that want to stay on Salesforce-managed services with minimal platform work | Teams planning a wider Salesforce marketing footprint who accept a newer platform | Teams that need data residency control, want to limit license exposure and can staff platform operations |
What stays in Salesforce and what moves when you choose Mautic
Salesforce CRM remains the system of record for accounts, contacts and opportunities whichever path you choose. Staying on Account Engagement+ or moving to Mautic changes where prospect engagement, scoring, grading and nurture programs are run, not where sales records live. The practical decision is therefore which engagement data your sales team relies on inside Salesforce today and whether that data can be reproduced in the new setup. Start by listing every field, score and grade that feeds lead status, routing or opportunity reporting.
Mautic connects to Salesforce through its Salesforce plugin, which the Mautic Salesforce plugin documentation describes as a configuration task in the Mautic knowledge base. The plugin is a plugin, not a native Salesforce feature, so the field-level mapping between Mautic contact fields and Salesforce objects is something you define and must test in your own org. Confirm which Salesforce objects the plugin reads and writes, which direction each field syncs, how duplicates are matched, and what happens to activity history. Do not assume that a field which exists in Account Engagement maps one to one without checking.
Native Account Engagement features that appear inside Salesforce, such as prospect activity views and Account Engagement reporting dashboards, will need to be rebuilt in Salesforce reports or replaced with Mautic reporting. Engagement Studio programs become Mautic campaigns, and scoring and grading rules have to be recreated and validated against historical results. Plan a parallel run where both systems score the same prospects so your team can compare outcomes before cutover. Ask your Salesforce administrator and your Mautic implementer to document every report, page layout and automation that depends on engagement data, because those dependencies are the most common source of surprises.
Which Mautic deployment fits your team
Your team installs Mautic on a virtual private server or dedicated server that you control. The Mautic project says it should not be installed on shared hosting and recommends a VPS or dedicated server instead, so that is the baseline for a self-run deployment. Installation can use the web or command-line installer, or Composer with the recommended project template, which has been recommended since version 4.0. The Mautic requirements page lists the current stack.
- Stack you maintain: Apache, Nginx or IIS, PHP, a MySQL or MariaDB database, and npm from Mautic 5.0 onward.
- Cron schedule: Segment updates, campaign updates and campaign triggers run from cron, and the project says these jobs should be staggered.
- Email path: A broadcasts command sends segment emails, and a messenger consumer must run whenever emails are queued.
- Upgrades: The project plans monthly patch releases, minor releases every three months and major releases every two years, so someone must schedule each one.
Internal staff carry every task in this model, and outside help is optional. Check that the PHP version of the release you pick is supported and confirm its security support end date before you commit to it.
Mautic.org offers managed Mautic and hosting services alongside the free self-hosted download, so a provider can run the stack for you. Mautic has no paid edition of the software itself, which means any recurring fee pays for the operation, hosting and support around the code. The provider takes on servers, PHP, the database, cron and patching under its contract, and your team focuses on campaigns, data and integrations. The contract, not the software license, defines what you can and cannot change.
- Responsibility boundary: Confirm in writing who patches the operating system, PHP, Mautic, cron and the mail queue.
- Pricing model: Ask what the recurring fee includes, such as contact volume, sending, storage and support hours, and what triggers extra charges.
- Data location: Confirm which region and facility hold your database, backups and attachments, and who can access them.
- Exit terms: Ask how you export contacts, templates, campaigns and logs, and how long data is kept after cancellation.
- Version control: Ask which Mautic versions the provider runs and how quickly it applies security releases.
Outside operations reduce internal effort, but you still own the data and the migration decisions. Ask the provider for its written responsibility matrix and a sample data export before you sign.
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Mautic, that means the application, database, cron, mail queue and Salesforce connection run in infrastructure your organization controls. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Your internal team keeps ownership of decisions about campaigns, data and compliance.
- Scope and design: Architecture for the web, database, cron and mail queue inside your network, documented in the written scope.
- Hardening and evidence: Configuration to your security baseline, with the controls and evidence prepared for your assessors. DeployOpen does not issue audit reports or certifications, so independent auditors and certification bodies make those determinations.
- Salesforce integration: Connection to Salesforce CRM through the Mautic Salesforce plugin, plus links to the identity and logging systems you already run.
- Backup and upgrades: Backup design with restore testing, and upgrade planning against the release support windows.
- Ongoing support: Retainers for upgrades, continuous testing and support after go-live, if you want them.
This model moves most build and operating tasks to a named delivery team while your staff keep governance. Ask for the written scope, the named deliverables and the owner on your side for cron, mail and upgrade decisions after handover.
How to move from Account Engagement to self-hosted Mautic
This sequence takes a Salesforce-connected B2B team from Account Engagement to a self-hosted Mautic instance that syncs with Salesforce CRM, with prospects, campaigns and scheduled jobs verified before Account Engagement is switched off. It works as a checklist for planning the project, not as a fixed timetable.
Confirm the Mautic release and support window
Your team or DeployOpen reviews the Mautic releases page and chooses a release whose security support covers your planned go-live and the years after it. Mautic 7.3 is described as the long-term support release with security support through 31 December 2027, while Mautic 7.2 is supported until 30 September 2026. Confirm the PHP version each release needs before provisioning. Done when the release, its end-of-support date and a patch calendar are written into the project plan.
Provision a VPS or dedicated server
The infrastructure owner provisions a VPS or dedicated server in your own cloud account or data center that meets the Mautic 7.0 requirements: PHP 8.2 to 8.5, MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, and Apache, Nginx or IIS. Mautic should not run on shared hosting. Npm is needed from Mautic 5.0 onward. Done when a staging host passes the requirements check and has backups, TLS and a separate sandbox environment ready.
Install Mautic with the chosen method
Install Mautic using the web installer, the command-line installer, or Composer with the recommended project template, which the installation docs support from version 4.0. Composer suits teams that want repeatable builds under version control. Record the installed version and configuration in your change system. Done when the admin login works, the database is reachable and the instance reports the expected version.
Connect the Salesforce plugin to a sandbox org
Configure the Mautic Salesforce plugin against a Salesforce sandbox, not production, following the plugin documentation. Map Mautic fields to the Salesforce lead and contact fields you rely on, and test sync for a small set of test records in both directions. Salesforce admins and Mautic administrators sign off on the field mapping. Done when test leads and activity appear in the sandbox as expected and duplicate handling has been checked.
Import prospects with the import command
Export prospects from Account Engagement using the export process described in your export plan, then load them into Mautic. Use the web interface for small files and the mautic:import console command run by cron for large files, which processes 100 rows per batch by default. Compare record counts and a sample of field values against the source export. Done when imported counts match the export and a reconciliation report is filed.
Stagger cron jobs for segments, campaigns and triggers
Configure the cron jobs for segment updates, campaign updates and campaign triggers, staggering their start times as the Mautic cron documentation recommends so they do not compete for resources. Add the broadcasts command for segment emails and run a messenger consumer for queued email. Your operations team monitors job logs for the first full cycle. Done when every scheduled job completes without errors across a test cycle and queued email is delivered.
Cut over and verify before retiring Account Engagement
Switch sending domains and forms to Mautic, run parallel sends to a test list, and confirm tracking, unsubscribes and Salesforce sync in production. Keep Account Engagement read-only for a defined period so you can re-run exports if a gap appears. Retire the Account Engagement connector only after the verification checklist is signed by marketing operations and Salesforce admins. Done when exports are verified, stakeholders approve the cutover and the retirement decision is documented.
Evidence to collect before and after the switch
A reviewer or procurement lead will ask for the same core records whether you upgrade to Account Engagement+ or move to Mautic. DeployOpen prepares this evidence for your assessors, but independent auditors and certification bodies issue any attestation, not DeployOpen.
Salesforce order form and renewal terms
Keep the signed order form, the current edition, the contract term and the renewal notice window for your Account Engagement subscription. Confirm in writing whether Account Engagement+ or Marketing Cloud Next is offered as a replacement, what it includes, and whether any migration credit applies. Your exit plan depends on these dates, so check them with your Salesforce account owner before you commit to a cutover date.
Contact and consent reconciliation
Export prospects and their consent or opt-out status from both systems, then reconcile record counts and suppression lists before and after the switch. Mismatched counts between Account Engagement and Mautic are the most common finding in a data review, so record the method and the totals. Confirm that every opted-out address is still suppressed in Mautic before the first campaign runs.
Mautic version and support dates
Record the exact Mautic version in production, its PHP and database versions, and the security support end date for that release. Mautic 7.2 receives security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Keep this record current, because an unsupported release becomes an open finding.
Cron and queue run logs
Mautic depends on scheduled cron jobs for segment updates, campaign updates and campaign triggers, plus a broadcasts command and a messenger consumer for queued email. Keep logs showing that each job ran on schedule, with failures and retries noted. Missing runs mean contacts stop moving through campaigns, so reviewers will look for gaps rather than a single clean day.
Backup and restore test results
Keep a dated record of a full Mautic restore into a separate environment, including the database, the media files and the configuration. A backup that has never been restored is an untested assumption. Record who ran the test, how long it took, and whether contact counts matched the source after restore.
Plugin sync configuration
If you keep Salesforce CRM, document the Salesforce plugin settings, the field mappings, the sync direction for each object and the account used for the connection. Confirm which fields Mautic writes back to Salesforce and which remain read-only, since a misconfigured sync can overwrite lead data. Retain the configuration export and a sample of synced records as evidence.
Questions buyers ask before choosing Mautic or Account Engagement+
What drives the cost difference between Account Engagement+ and self-hosted Mautic?
The main difference is who is paid for what. Account Engagement+ is a subscription, so its fees recur and scale with the edition and contact limits Salesforce quotes you. Mautic has no paid edition of the software itself, according to mautic.org, so your costs are the infrastructure, email sending, the Salesforce integration upkeep, and staff or partner time to run and upgrade it. Infrastructure is recurring, while setup and migration are one-time. Mautic must run on a VPS or dedicated server rather than shared hosting, according to the Mautic requirements page. Ask any quote to split one-time migration from recurring hosting, support and upgrades, and to name the edition and contact tier it assumes.
How long does a move from Account Engagement to Mautic take?
Duration depends on the number of prospects, the activity history you need to keep, how many Engagement Studio programs must be rebuilt as Mautic campaigns, and how much scoring and grading logic must be mapped. Those inputs, not the software, set the timeline. Mautic imports contacts from CSV and recommends background imports through the mautic:import console command for large files, processed in batches of 100 rows by default, according to Mautic documentation, so bulk volume affects the load window. Ask for a schedule that separates data export, import, integration testing and cutover, and confirm how long you will run both platforms in parallel.
Can our team migrate to Mautic without outside help?
A technically capable team can install Mautic and import contacts without outside help, but the work is larger than a CSV import. The install options include the web or command-line installer and Composer with the recommended project template since version 4.0, according to Mautic's installation docs. Operations also include cron jobs for segment updates, campaign updates and triggers, a broadcasts command, and a messenger consumer when email is queued, all of which must be scheduled and monitored. Salesforce connectivity relies on the Salesforce plugin. Check internal skills in PHP hosting, cron and queue operations, email deliverability and Salesforce administration before deciding. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure under a written, fixed scope.
Will Salesforce reporting and the CRM link keep working after the move?
Native Account Engagement sync is replaced by the Mautic Salesforce plugin, so the link needs to be designed and tested, not assumed. Salesforce documents Account Engagement as integrated with Salesforce CRM, and Mautic documents a Salesforce plugin configured as described in its knowledge base, according to Mautic's plugin documentation. Confirm field mapping for leads, contacts, campaigns and activity, how lead status and scoring fields sync back, and which reports depend on Account Engagement objects. Ask the implementer to show a test run of each sync direction before cutover.
How do Mautic release support windows affect planning?
Mautic's support windows are the planning input that changes most often, so tie your upgrade calendar to them. Mautic's stated cadence is monthly patch releases, minor releases every three months and major releases every two years, according to the Mautic releases page. Mautic 7.2 (Absolunto) has active and security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Older lines have earlier end dates, so confirm which version you will run at go-live and budget upgrade work into recurring costs. Check PHP and database requirements for each release before scheduling.
What should we ask for in a written quote for a Mautic migration?
Ask for a fixed scope that lists each deliverable and what is excluded. Request separate line items for discovery and data export from Account Engagement, Mautic installation and hardening, the Salesforce plugin configuration and testing, rebuilding programs as campaigns, cron and queue setup, backups, documentation, and cutover support. Ask which items are one-time and which are retainers for upgrades, security testing or ongoing support, and what triggers a change order. Request the assumptions behind contact volume, number of programs and integrations, and the Mautic version targeted. Confirm who owns the hosting accounts and the data at the end of the engagement.
Does moving to Mautic remove the need for Account Engagement licensing right away?
Not automatically. Your Account Engagement subscription keeps billing until its contract term ends, so plan the cutover date around the renewal. Check the notice period and whether the contract renews automatically, and confirm with Salesforce what access you keep for export. Use the overlap period to validate imports, campaign behavior and reporting in Mautic before you stop sending from the old platform. Confirm the exact terms with your Salesforce account team, since this page does not set contract terms.
Where migrations to Mautic usually stall
The most common stall is consent and suppression history. Before any contact moves, export unsubscribe status, email preference records, opt-in evidence and bounce or suppression flags from Account Engagement, and confirm which of them the import will carry into Mautic as contact fields, DNC flags and channel preferences. Do not assume a plain CSV import preserves them. Ask the team that owns consent to sign off on a field-by-field mapping, and keep the original export as the evidence record. Sending to a contact who opted out in the old system is the mistake that creates the most regulatory exposure, so treat this mapping as a gate, not a cleanup task.
The second stall is duplicate records during sync. While Mautic's Salesforce plugin and Salesforce CRM both hold prospect and lead data, the same person can appear as a lead in one system and a contact in another, and each update can overwrite the other. Decide in advance which system is the master for each field, which object Mautic writes to, and how matches are made, then run a duplicate report in Salesforce before turning on two-way sync. Scoring and grading also stall here: Account Engagement scores often depend on its own activity tracking and automation rules, so rebuild the logic in Mautic, compare scores for a sample of records against the old values, and document every difference before cutover.
The third stall is operational. Mautic does not run its own schedule. It depends on cron jobs for segment updates, campaign updates and campaign triggers, plus a broadcasts command and a messenger consumer when emails are queued, so a server that is installed but not monitored can stop sending without any visible error. Confirm each job runs on the documented schedule, check that the queue worker restarts after reboots, and alert on job failures before go-live. Then run both platforms in parallel for a defined period, compare send volumes, bounces and form submissions, and agree the rollback point in writing: the date after which Account Engagement is switched off and the export needed to restore it is retained. Confirm the exact retention and support terms with your own change board and with DeployOpen's written scope before that date is fixed.
How DeployOpen implements Mautic beside Salesforce CRM
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For teams weighing the Account Engagement+ upgrade against a move to Mautic, we start by agreeing on what the Salesforce connection must do and what the business can give up.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts
- The written scope lists the Salesforce objects, fields and sync direction Mautic must read and write
- Scope also records which Account Engagement programs, scoring rules and reports need a documented replacement
- We ask for your Salesforce edition and API access details so the integration path is confirmed early
- Quotes follow from the written scope, so ask for the scope breakdown when comparing options
How we build
- We install Mautic in your own cloud account, data center or air-gapped network on a server you control
- We configure the Mautic Salesforce plugin and test contact, lead and activity sync against a sandbox
- We set up the cron jobs for segment updates, campaign triggers and broadcasts, staggered as the documentation advises
- We run security testing on the Mautic deployment and its integration points before go-live
- We rebuild priority nurture logic as Mautic campaigns and document each mapping decision
How we hand over
- Handover documentation covers the architecture, the sync configuration and the cron and queue setup
- Runbooks describe backups, restores and the steps for upgrading Mautic to a supported release
- Your team receives a written list of what stays in Salesforce and what lives in Mautic after cutover
- We prepare controls and evidence for your own compliance assessments, without issuing any audit report
- Independent auditors and certification bodies remain responsible for any attestation you pursue
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- A retainer can cover monitoring of the cron and messenger jobs that Mautic depends on
- Upgrade planning follows the Mautic release schedule so your instance stays on a supported version
- Retainer scope and response expectations are agreed in writing before the retainer starts
- Ask for the retainer scope alongside the project scope so both costs are comparable
