Migrate from Account Engagement (Pardot) to Mautic: what moves and who does the work
This is a campaign-layer migration, and Salesforce CRM stays where it is. If your renewal, licensing terms, data residency rules or lock-in concerns are pushing you off Account Engagement, the move replaces the marketing automation tool, its forms, email sending, scoring and nurture programs, while your accounts, opportunities and sales workflows keep running in Salesforce. Marketing operations usually leads the work because it owns the programs and data definitions, with IT or an implementation partner handling hosting, the Salesforce connection and cutover. Mautic is free to self-host, and the project does not sell a paid edition of the software itself. Your costs are the servers, email sending, staff time and any outside help, not a license fee for the code.
Effort and risk concentrate in three places: the prospect and activity history you need to keep, the Engagement Studio programs you need to rebuild as Mautic campaigns, and the scoring and grading logic that sales relies on. Mautic runs its own cron jobs for segment updates, campaign updates and triggers, and it needs a messenger consumer when email is queued, so someone must own that operational layer from day one. Before you start, confirm with Salesforce which of your records and fields Account Engagement writes back to CRM, because those fields decide what the Mautic Salesforce plugin must sync and what can be retired. Ask your Salesforce administrator to confirm the API access your edition provides, since the export step depends on it.
The practical first decision is scope: move everything in one cutover, or run both platforms for a period with a defined set of programs and lists moving first. Mautic's Salesforce plugin is configured through its own documentation, so the plugin setup, field mapping and sync direction should be tested in a non-production instance before any live prospect is touched. Quotes for this work should break out the Mautic hosting, the Salesforce plugin configuration, the program rebuild, the data migration, and ongoing upkeep, and should state who handles email deliverability and who signs off on the scoring model.
Which Account Engagement capabilities map to Mautic and which need rework
This table maps the main Account Engagement capabilities to their Mautic equivalents and labels each as clean, needs rework or gap. Use it to scope the migration: clean rows move with import and standard configuration, rework rows need redesign or rebuilding, and gaps need a decision on a substitute or a custom build. Confirm the Salesforce sync row first, because plugin configuration depends on your Salesforce org setup.
| Capability | Mautic equivalent and migration path | Status |
|---|---|---|
| Prospects and lists | Prospects import as contacts via CSV. Lists are rebuilt as segments. | Clean |
| Forms and landing pages | Rebuild forms and landing pages in Mautic. Retest field mapping and submission handling. | Needs rework |
| Email sending | Mautic sends through your own mail transport. Set up sending domain authentication and queue workers before cutover. | Needs rework |
| Engagement programs | Rebuild each Engagement Studio program as a Mautic campaign. Plan for cron-driven campaign triggers. | Needs rework |
| Scoring | Re-enter point values as Mautic points and triggers. Compare results against sample historic scores. | Needs rework |
| Grading | No direct Mautic grade model. Recreate grades as a custom field set by segment or points rules. | Gap |
| Salesforce sync | Mautic Salesforce plugin. Confirm connected app, field mapping and sync direction in the plugin documentation. | Needs rework |
| Reporting | Mautic reports cover campaign and contact data. Salesforce pipeline and influence reports must be rebuilt. | Gap |
Which prospect, activity and integration data moves through the documented export paths
Account Engagement data reaches Mautic through a small set of documented paths, and each one leaves something behind in Salesforce. The cards below cover the export side, the import side, the Salesforce connection and the records that stay where they are.
Asynchronous Export API output
The Account Engagement Export API is asynchronous: you request a job, wait for it to finish, then download the results as CSV files. Prospect and activity exports arrive as flat files that you must join by prospect identifier before import. Confirm with Salesforce which of your editions and user licenses include API access, and plan for jobs that run longer than a single session. Keep the raw files as an archive copy before any transformation.
OAuth and connected app setup
Account Engagement API calls authenticate through OAuth using a connected app in Salesforce. Create the connected app, record its consumer key and callback settings, and confirm which user the export runs as, since that user's permissions limit what comes out. Store the client secret and refresh tokens in a secrets manager, not in configuration files. Document who owns the connected app so credentials can be rotated when staff leave.
Mautic CSV import with automatic mapping
Mautic's user interface imports contacts from CSV and maps columns to fields automatically, which suits small test loads. Match your exported column headers to existing Mautic contact fields before you import, and create any custom fields first so values are not dropped. Review the mapping on a sample file, and confirm how duplicate email addresses are resolved in your version.
Background import with mautic:import
For large files, Mautic recommends running the mautic:import console command from cron rather than the browser. The command processes rows in batches of 100 by default, so a multi-million-row file runs as a long background job. Set the batch size in your configuration only after testing, and monitor the job log for rejected rows and memory errors. Schedule it outside peak hours on the same server that runs your other Mautic cron jobs.
Salesforce plugin configuration
Mautic's Salesforce plugin connects Mautic to Salesforce CRM, and its setup steps are described in the Mautic knowledge base. Decide before go-live which Salesforce objects sync in each direction, which field mappings apply, and which records create new leads or contacts. Test on a Salesforce sandbox first. Confirm that the plugin version matches your Mautic release, since plugin behavior can change between versions.
What stays in Salesforce
Opportunities, accounts, and the Salesforce CRM records they link to remain in Salesforce, and the plugin syncs against them rather than moving them. Account Engagement-specific objects, such as the prospect's campaign membership history and scoring rules, need an explicit decision: export them as reference data, or rebuild them in Mautic. Record that decision in your data inventory so reporting in Salesforce still makes sense after cutover.
How Mautic connects to Salesforce CRM after the move
Mautic connects to Salesforce CRM through a Salesforce plugin, which the Mautic project documents as an integration configured through its knowledge base. The plugin is not a switch you turn on after installation. Before you configure anything, the inventory step must settle three decisions: which fields map between Mautic contacts and Salesforce Lead and Contact records, which direction data flows for each field (Salesforce to Mautic, Mautic to Salesforce, or both), and which Salesforce objects Mautic is allowed to read and write. Account Engagement currently handles some of this for you through its native connector, so the mapping is likely to be the largest piece of hidden configuration work in the move. Document each mapping in a table with an owner who signs off on it.
Confirm the Mautic release and plugin version your environment supports before you write that mapping. The Mautic Salesforce plugin documentation for your target release lists the configuration steps, and the versions of Mautic and the plugin must match the Mautic release you plan to run. Check the Mautic releases page for the support window of the release you choose, since a release nearing end of security support will require another upgrade soon after go-live. Ask your implementation partner to test the connector against a copy of your Salesforce sandbox or a non-production org, and confirm with your Salesforce administrator which API user and permissions the connection will use, because those permissions determine what the sync can change in your CRM.
The migration sequence from inventory to decommission
This sequence moves Account Engagement programs, prospects and scoring into Mautic in controlled stages while Salesforce CRM stays the system of record. Each stage ends with a written output that the next stage depends on, so cutover and decommission happen only after the pilot and parallel run have been checked.
Inventory programs, lists, rules and Salesforce fields
Start by listing every Engagement Studio program, prospect list, dynamic list, form, landing page, scoring and grading rule, and the Salesforce fields that Account Engagement reads or writes. Marketing operations usually owns this step, with a Salesforce administrator confirming which fields sync and in which direction. The output is a field map that pairs each Account Engagement field with its Salesforce counterpart and its Mautic contact field, plus a rule inventory that marks each scoring and grading threshold as kept, rebuilt or retired. The step is done when the business owner has signed off the map and the list of retired items.
Stand up a non-production Mautic instance
Install Mautic on a separate server or VPS that is not production, following the project's installation guidance and its requirements for PHP, the database and the web server. Mautic should not run on shared hosting. Configure the cron jobs for segment updates, campaign updates and campaign triggers, staggering them as the documentation advises, and confirm that the messenger consumer runs if email is queued. Your infrastructure team owns this step. It is done when a test email sends end to end and every scheduled job logs a successful run.
Pilot one program on the test instance
Choose one Engagement Studio program with a modest audience and rebuild it as a Mautic campaign on the test instance. Import a sample of its prospects from CSV, which Mautic maps to fields automatically, and use the command-line import through cron for larger files. Compare enrollment counts, email timing, scoring changes and suppression behavior against the original program. The output is a pilot report that lists each difference found, its cause and the fix. Do not move to the next step until the report has no unexplained differences.
Connect the Salesforce plugin in a parallel run
Configure the Mautic Salesforce plugin against a Salesforce sandbox first, following the plugin documentation for version-specific setup and authentication. Confirm that lead and contact records, field updates and activity writes behave as the field map specifies. Then run both platforms side by side on a copy of the audience, comparing sends, Salesforce activity and score values each day. Salesforce and CRM administrators own this step. It is done when the two systems agree on the agreed reconciliation checks for the full parallel period, and the team has written down what each check measures.
Cut over forms, sending domains and programs
Recreate forms and landing pages in Mautic, update embedded links and tracking domains, and move sending domains only after email authentication records are verified for the new sender. Switch each remaining program from Account Engagement to Mautic in batches, pausing the original program first so that no prospect is enrolled in both. Keep a rollback path for each batch until its first sends have been reviewed. The output is a cutover checklist that records each form, domain, program and owner, with the date each item moved and the reviewer who signed it off.
Decommission Account Engagement after verification
Once all programs and forms have run on Mautic and reconciliation shows no open gaps, archive what the business needs from Account Engagement. Use the Export API to retain prospect and activity history where your records policy requires it, and store the export in a location your retention rules cover. Then disconnect the Account Engagement connector in Salesforce, revoke its connected app access and cancel the subscription on the date your contract allows. The output is a decommission record that lists archived data, revoked credentials and the confirmed end date. Ask your legal and procurement teams to confirm contract terms before this step.
What Mautic needs in your infrastructure before the first import
Before any prospect or activity record moves across, the server platform has to be in place and stable, because Mautic is a self-hosted application with its own PHP, database and web server stack. The Mautic 7.0 requirements page lists 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 as the web server. From Mautic 5.0 onward, npm is also required. Confirm these against the release you choose, and check the project's requirements page before you size hosts. The project advises against shared hosting and recommends a VPS or dedicated server, so budget for a host you control with root or equivalent access, and agree who patches the operating system, PHP and the database. Choose the version by its support window, not by the newest number. The Mautic releases page lists Mautic 7.2 with active and security support until 30 September 2026, and Mautic 7.3 as the planned long-term support release with security support through 31 December 2027. Mautic 6.0 and 5.2 have earlier end dates. For a migration that will run for years, a long-term support line is usually the safer base. Install with the web or command-line installer, with Composer using the recommended project template (supported since version 4.0), or from GitHub for development only. Composer-based installs make upgrades more repeatable, which matters because your team will own every upgrade. Mautic runs its own scheduled work, so the cron plan must exist before the first import. Segment updates, campaign updates and campaign triggers each need a cron job, and the project's cron documentation says these should be staggered rather than started together. Add the broadcasts command for segment emails, and run a messenger consumer if your email is queued. Without these processes, imported contacts will sit in segments and campaigns that never update. Ask your platform owner to confirm where the jobs run, how failures alert, and whether the mail transport can sustain your send volume.
How the migration differs by program count, Salesforce setup and sending volume
A small B2B team with a handful of Engagement Studio programs, a short list of forms and landing pages, and a single scoring model usually has a contained migration. The inventory can be done by one person in a few working sessions, and most of the effort goes into confirming that prospects, opt-in status and recent activity arrive in Mautic correctly. Because the Salesforce integration is often the most visible part of the setup, the testing focus is on lead and contact syncing between Mautic and Salesforce CRM rather than on complex branching logic.
- Program inventory: List each Engagement Studio program, its entry rules, its email templates and its exit conditions in one spreadsheet, and mark which programs are still active.
- Contact import: Load prospects through the Mautic import screen for smaller files, and confirm that column mapping matches the Mautic contact fields before running the full set.
- Opt-in status: Check that unsubscribe and consent flags carry across for every record, since a few errors matter more than a large volume of mismatched fields.
- Integration test: Create a test lead in Salesforce, confirm it appears in Mautic, then trigger a simple campaign and confirm the activity returns to the CRM record.
- Parallel run: Keep Account Engagement active until each live program has been rebuilt and checked, and ask your team to confirm the parallel period length with the rest of your planning.
Before cutover, confirm with your Salesforce administrator which fields Mautic will write to and which fields only Salesforce owns.
A large team with many nurture programs, layered scoring and grading rules, and several business units usually faces a migration where the logic is the hardest part. Each Engagement Studio program may contain branches, delays and suppression rules that have to be rebuilt as Mautic campaigns, and scoring and grading thresholds may depend on years of tuning. The inventory must record the business intent behind each rule, not only its settings, so that the rebuilt campaign produces the same outcome for a prospect.
- Dependency map: Record which programs feed other programs, which lists they add or remove prospects from, and which scoring thresholds trigger a hand-off.
- Scoring and grading review: Write down each scoring rule and grading criterion, then decide with sales operations whether the thresholds still reflect the current ideal customer profile.
- Segment design: Plan Mautic segments and campaign triggers so that each program's entry and exit conditions can be tested against a sample of real records.
- Integration test cases: Build a test matrix covering each business unit, each hand-off to sales and each suppression rule, and run it in a non-production Mautic instance.
- Parallel run: Plan a longer parallel run than a small team would need, with side-by-side comparisons of enrolment counts and hand-off volumes, and confirm the period with your steering group.
Ask for a written list of every rule that is in scope before any rebuild starts, because unrecorded rules are the usual source of surprises.
Organizations that have built many custom objects, custom fields and complex relationships in Salesforce CRM face a different problem. The marketing data model in Mautic will not mirror Salesforce, so each custom object and field must be mapped to a Mautic contact field, a company field, a custom object, or a value that stays only in Salesforce. Field types, picklist values and relationship rules often differ, and these differences only appear when real records are pushed through the integration.
- Object and field catalog: List every custom object and custom field that Account Engagement reads or writes, and note its data type, required status and owner in Salesforce.
- Mapping decisions: For each field, decide whether Mautic will hold it, read it from Salesforce, or leave it out, and document the decision with the Salesforce administrator.
- Data quality checks: Sample records from the largest and oldest objects, looking for blank required fields, duplicate keys and picklist values that no longer exist.
- Integration testing: Test each object type separately, including creation, update and deletion events, since the Salesforce plugin configuration will differ by object.
- Parallel run: Extend the parallel run for any object whose sync behaves differently under real volume, and confirm the schedule of cron jobs that drive the sync with your platform team.
Ask the Salesforce plugin vendor and your Salesforce architect to confirm which objects and fields the plugin supports in your org before you commit to a mapping design.
What usually goes wrong in an Account Engagement to Mautic move
Most failed migrations break in a few predictable places: sender reputation, scoring logic, the CRM sync, background jobs, data hygiene and cutover timing. Each card names one risk and the check that prevents it, so the team can verify each control before prospects are moved.
Lost sender reputation during cutover
Moving sending from Account Engagement to Mautic often means a new sending domain, new IP addresses or a new mail transport. Mailbox providers judge the new sender from zero history, so a sudden volume jump can push good mail into spam folders. Before cutover, warm the domain gradually, confirm SPF, DKIM and DMARC records for the new sender, and keep the old sending path live until delivery metrics on the new one look stable.
Scoring and grading drift after rebuild
Account Engagement scores and grades are rarely documented in one place, and rebuilding them in Mautic often changes thresholds, point values or the activities that count. Prospects can then cross a sales-ready line on a different date or not at all. Export current scores and grades for a sample of prospects, recreate the rules in Mautic, and reconcile the two sets before any routing to sales depends on them.
Salesforce sync duplicating or overwriting prospects
The Mautic Salesforce plugin matches contacts to CRM records through its field mappings. If the matching key is inconsistent, or both systems are allowed to update the same fields, the result is duplicate leads or overwritten owner, status and consent values. Document which system owns each field, run the sync against a sandbox or a small test set first, and check for duplicates before enabling the full two-way flow.
Cron jobs not running, so campaigns stall
Mautic depends on cron jobs for segment updates, campaign updates and campaign triggers, and queued emails also need a messenger consumer. If these are missing, misconfigured or run at the same time, contacts stop moving through campaigns without any visible error on the sending side. Confirm each job runs on schedule with staggered timing, set up alerting on job failures, and watch campaign progression for the first few days after launch.
Unmapped fields and lost consent status
Custom fields in Account Engagement do not carry over automatically, and a CSV import maps columns to fields only where names match. Unmapped fields are silently dropped, and opt-out, unsubscribe and suppression status can be lost if they are not imported explicitly. Build a field inventory, map every custom field and consent flag before import, and confirm that suppressed contacts remain suppressed in Mautic before any campaign runs.
Cutover without a parallel run
Switching all programs and sending in one step leaves no way to compare results against the old system. Problems with scoring, sync or deliverability then surface only after prospects have received the wrong messages. Run both platforms in parallel for a defined period with a small audience, compare send counts, opens, clicks, scores and CRM updates, and set written go or no-go criteria before the old programs are turned off.
What drives cost and duration, and how to keep each one down
This table lists the main drivers of migration cost and effort, from prospect volume to testing depth, and how to reduce each one. Read it to see which items are one-time and which recur, and use the drivers to shape the questions you put to any implementation partner.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Prospects and activity history | Volume of prospects, custom fields and years of activity history drives export size, field mapping and import time into Mautic. | Decide which activity history must move. Archive older activity in a read-only store and import only active prospects and recent interactions. |
| Engagement Studio programs and rules | Each program has its own rules, branches and timing. Rebuilding each one as a Mautic campaign is design and testing work. | Inventory programs first. Retire unused ones and consolidate near-duplicates before rebuilding anything. |
| Scoring and grading models | Account Engagement scoring and grading must be re-expressed as Mautic points and segment logic. Ambiguous thresholds slow the design. | Document current thresholds and who depends on them. Agree target logic with sales and marketing before build starts. |
| Salesforce customization | Custom objects, field mappings, lead and contact matching rules, and Account Engagement connector settings each need to be replicated or mapped in the Mautic Salesforce plugin. | Export a field-level map from Salesforce early. Limit the sync to fields that drive campaigns and reporting. |
| Hosting and operations staffing | Mautic runs on your own server with a database, cron jobs, a queue consumer and upgrades on a published release cadence. Someone must own these. | Standardize deployment with infrastructure as code and monitoring. Confirm who on your team or partner's team carries patching and cron health. |
| Email sending and deliverability | Sending domains, authentication records, bounce handling and warm-up of a new sending setup take time and affect results from the first campaign. | Plan domain and authentication setup in parallel with the build. Confirm which sending service you will use and its recurring fees. |
| Testing depth | Testing covers segment membership, campaign triggers, Salesforce sync direction and suppression rules. Shallow testing shifts cost into live campaigns. | Define test cases from the program inventory. Run parallel sends with a small audience before cutover. |
| One-time versus recurring costs | One-time: export, mapping, rebuild, Salesforce plugin setup, migration testing. Recurring: hosting, sending volume, upgrades, support retainers. | Ask any quote to separate these two groups and state what each recurring item is based on. |
Questions buyers ask before moving from Pardot to Mautic
What drives the cost of moving from Pardot to Mautic?
The Mautic software itself has no license fee, so the cost is the work and the infrastructure around it. Recurring costs include a VPS or dedicated server (Mautic should not run on shared hosting), database and web server upkeep, an email sending service, and the admin time to keep cron jobs and the Salesforce integration running. One-time costs include migration labor, rebuilding programs, scoring and grading rules, and testing. Contact volume, the number of nurture programs, custom fields and the complexity of your Salesforce field mapping push the effort up. Ask any quote to itemize these components separately, with what is one-time and what recurs each year.
How long does a Pardot to Mautic migration usually take?
The supplied sources do not give a standard duration, so treat any figure you hear as unverified until it is tied to your environment. Timing depends on how many programs you rebuild as Mautic campaigns, how many prospects and activity records you move, how cleanly your Salesforce fields map, and how many people must sign off on scoring and grading. Your team's availability and the time needed to set up hosting and email sending also count. Ask for the duration in the written scope, with the milestones and the client decisions each milestone depends on.
What does our team need to provide during the migration?
The work needs access and decisions from both marketing and IT. On the Salesforce side, you need an administrator who can create the connected app and confirm which objects and fields the integration may read and write. Marketing operations should inventory existing Engagement Studio programs, email templates, lists and scoring rules, and name an owner who approves how each is rebuilt. IT needs server and database provisioning, control of the sending domain and its DNS records, and a named person for cron jobs, backups and upgrades. Confirm these roles in the written scope before work begins.
Can our team migrate from Pardot to Mautic without a partner?
A capable internal team can do it, provided it has Linux server administration, PHP and database experience, and a Salesforce administrator who understands the integration. Mautic installs from a production package or Composer, and its documentation covers CSV imports and the Salesforce plugin. The risks are in the details: staggered cron jobs, queued email delivery, field mapping that loses history, and ongoing patching. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure. Its engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
Does Salesforce CRM stay after moving to Mautic?
Yes, in the typical plan for this move. Salesforce describes Pardot as the legacy name for Account Engagement, its B2B marketing automation product integrated with Salesforce CRM. Replacing Account Engagement while keeping Salesforce CRM means Salesforce remains your system of record for leads, contacts, accounts and opportunities, and Mautic takes over campaigns and marketing automation. Mautic documents a Salesforce plugin for that connection, and the configuration steps are in its documentation. Confirm which objects sync, in which direction, and how your Account Engagement contract ends, since those terms come from Salesforce and your agreement, not from this page.
Does Mautic have a paid edition?
Mautic has no paid edition of the software itself. Its code is licensed under the GNU General Public License version 3 or any later version, and mautic.org offers the free self-hosted download. The project also promotes separately managed Mautic hosting services, which are optional and billed by those providers. Your real costs are therefore infrastructure, email delivery, implementation and support. Check the license of any third-party plugin you plan to use, because plugins may carry their own terms. Ask your legal or procurement team to review the license terms that apply to your deployment.
How do Mautic release support windows affect migration planning?
Support dates should decide which version you install. Mautic 7.2 (Absolunto) supports PHP 8.2 to 8.5 with 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. Mautic 6.0 receives security support until 30 September 2026, and Mautic 5.2 until 30 June 2026. Mautic 4.4 has paid Extended Long Term Support through 31 December 2026. Starting on a version that ends support during your rollout creates an upgrade you did not plan for. Confirm the current dates on the releases page and the release status at go-live.
What server requirements should we check before installing Mautic?
For Mautic 7.0, check for PHP 8.2, 8.3, 8.4 or 8.5, MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher, and a web server of Apache, Nginx or IIS. npm is required from Mautic 5.0 onward. Mautic should not run on shared hosting, so plan a VPS or dedicated server. Operations also need cron jobs for segment updates, campaign updates and campaign triggers, staggered as the documentation recommends, plus a broadcasts command for segment emails and a messenger consumer when emails are queued. Confirm these requirements against the version you choose, because they change between releases.
When to keep Account Engagement a while longer
The main reason to delay is that some campaigns cannot pause. If active nurture programs send regulated notices, renewal reminders or consent-dependent communications, a cutover that leaves a gap in sending or suppression history creates compliance exposure. Before committing to a date, list every active Engagement Studio program, its audience, and the consent basis for each, then confirm with your compliance lead whether any can be stopped, rebuilt and re-approved without breaking a required communication cycle. A sending gap is the risk most teams underestimate, so plan a parallel run where both systems send to separate test segments.
The second reason is an unresolved Salesforce integration design. Mautic connects to Salesforce through its plugin, which is documented in the Mautic Salesforce plugin guide, but the plugin does not decide for you how lead and contact records, campaign membership, owner assignment and activity history should map to your objects. If your team has not agreed which system is the system of record for prospect scoring, lead status and opt-out fields, the migration will stall or create duplicate records. Settle the field mapping and sync direction in writing before you export anything, and confirm with your Salesforce administrator which edition and API access your current setup depends on.
The third reason is operational capacity. Self-hosting Mautic means someone must run the cron jobs for segment updates, campaign updates and triggers, keep the broadcasts and messenger processes healthy, and apply monthly patch and periodic minor and major upgrades. The Mautic cron documentation asks that these jobs be staggered, so a team without a platform owner or monitoring for failed jobs is taking on recurring work that Account Engagement currently absorbs. If nobody on your staff can own that schedule through a full campaign cycle, staying on the hosted product for another quarter is a reasonable decision, and a fixed-scope implementation partner can help you build the runbook before you switch.
How DeployOpen scopes, runs and supports the Mautic migration
DeployOpen approaches the move from Account Engagement (Pardot) to Mautic as a fixed-scope engagement, with the Salesforce CRM connection, prospect data and campaign rebuild agreed in writing before work starts. Ongoing support, upgrades and testing are available as a retainer after handover.
How we scope
- Written scope lists which prospects, activity history, custom fields and Engagement Studio programs move into Mautic
- Scope records which Salesforce objects and fields the Mautic plugin will sync, and which stay only in Salesforce
- Scope names the Mautic release, PHP version and hosting environment, confirmed against current Mautic requirements before build
How we build
- Install Mautic in your own cloud account, data center or air-gapped network, not on shared hosting
- Configure the Salesforce plugin, map scoring and grading fields, and rebuild nurture programs as Mautic campaigns
- Set up cron jobs for segments, campaigns and broadcasts, and test imports in batches before cutover
How we hand over
- Documentation covers field mappings, campaign logic, cron schedules and the sync configuration for your team
- Test results record prospect counts, sync checks and campaign triggers compared against the source export
- Handover includes a runbook for backups, upgrades and the Mautic release cadence your team will follow
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends
- Retainer scope can cover Mautic patch and minor upgrades, plugin upkeep and cron health checks
- Ask for the support hours, response expectations and upgrade responsibilities to be written into the quote
