Mautic campaign import and export

The export ZIP is the unit you move between instances, so know what it contains before you plan a transfer. Mautic's export function produces a ZIP that includes campaign data, external assets and dynamic content, and Mautic recommends importing these exports over hand-built files. That recommendation matters because a campaign is rarely one record. Its events, decision branches, timing and the content those events send are stored together, and rebuilding them by hand on a second instance invites small differences that are hard to spot later. Keep each export tied to the source instance and the date it was made, so you can show which version of a campaign reached production.

Before you import, confirm what the target instance already holds. A campaign refers to other objects, such as segments that define its audience, forms that capture submissions, email templates that supply content, and custom fields that hold contact attributes. Make an inventory of every dependency the source campaign uses, then check each one on the target by name and identifier. An object that exists with the same name but a different identifier can leave the imported campaign pointing at the wrong thing. An object that does not exist at all can leave a reference broken or cause the import to fail. Do not assume that a dependency missing from the target will be created for you.

Verify what the file carries instead of assuming it. Run a test import into a non-production instance that holds the objects you inventoried. Then open each imported campaign and check every event, every decision path, each linked email or form, and the segment used as the audience. Confirm whether assets arrive as copies on the target or still refer back to the source. Record what came across intact, what was dropped and what needed rewiring. Name the person who signs off the test, and decide in advance whether a gap is fixed by creating the object on the target with the same identifier, by editing the campaign, or by delaying the move.

Plan the gaps and the activation step together. Whoever recreates missing segments, forms and templates on the target needs permission to do so, so check the roles on the target before the test, not during the production window. Import through the interface accepts ZIP files only, while the command line and API can also take correctly structured JSON, so confirm the format you will use if the move is scripted. Keep imported campaigns inactive until the checks pass. Campaign updates and triggers depend on scheduled cron jobs, so confirm those jobs run on the target before you expect any campaign to act on contacts.

An imported campaign can look finished in the Mautic interface and still send nothing. The reason is that Mautic does not move contacts through a campaign on its own. It relies on scheduled cron jobs to update segments, update campaigns and fire campaign triggers, and the Mautic cron jobs documentation says these jobs should be staggered so they do not all run at the same moment. A campaign that was exported from a working instance carries its structure, assets and dynamic content, but it carries none of the scheduling that makes it run. Until the target instance has those jobs configured and running, the import is inert, however correct the steps look on screen.

Email delivery adds a second dependency. Segment emails are sent by a broadcasts command, which is a separate scheduled task from the campaign jobs. When emails are queued rather than sent immediately, a messenger consumer must be running to pick them up and deliver them. If that worker is not running, messages will appear as queued or pending, and the campaign report may show activity that never reaches a recipient. This is the failure most likely to be missed during a staging-to-production move, because the contact counts and campaign diagram still look healthy while the queue grows.

Before the first live trigger, confirm three things on the production server, not only in the staging copy. First, check the cron schedule for each Mautic job, including the frequency and the offsets between jobs, against the current cron jobs documentation for your release line. Second, confirm that the messenger consumer and the broadcasts command are running under a process supervisor or service definition that restarts them after a failure or reboot, and that the worker user has the file permissions it needs. Third, verify that the email transport settings on production point at the intended sending service. Ask your team who owns each of these settings and where they are recorded.

Then prove the path end to end with one campaign before enabling the full set. Choose a single test contact or internal test segment, a campaign with one trigger and one email, and watch the event through each stage: segment membership is updated, the trigger fires, the email is queued, the consumer delivers it, and the send is visible in the contact timeline. Record the time each step took and the log entries that show it. If any stage stalls, fix the scheduling or worker issue first, because adding more campaigns will only multiply the queue. Once one path behaves as expected, repeat the check for each distinct trigger type in the imported set.

The first failure pattern is a campaign that imports cleanly but points at a segment, form, asset or dynamic content item that has a different name, or no equivalent, on production. The import itself may not flag this, so the review has to start inside the campaign builder. Open each decision and action that references another object and confirm that it resolves to a named object on the target, with no empty field showing. Compare the referenced names against a list taken from production before any campaign is enabled. Record each mismatch in a remap log with the source name, the target object, the person who approved the substitution, and whether the campaign should be rebuilt or the object renamed.

The second pattern is a release mismatch between source and target. An export made on one release can carry campaign structure that another release handles differently, and the failures are not always visible on the import screen. Before the import, record the exact version shown on each instance and check its release line against the Mautic releases page, since a target on a line near the end of its support window carries its own risk. After the import, look for campaign nodes that display as unrecognized, action types that are missing, or steps that do not run when tested with a sample contact. Record both version strings, the import date, and the decision to align versions or re-export from a matching source before trying again.

The third pattern is an import into a live instance during active sends. The campaign may be correct, yet contacts start moving through it while the team is still checking it, or emails from an earlier campaign are still queued to contacts the new one now targets. Review the timestamps in the campaign's contact and event history against the import time, and check whether any broadcast or email jobs were running at that moment. Confirm the published state of the campaign and compare the number of contacts added to it with the size of the segment you expected. Record the import time, the sends in progress before and after the import, contact counts per campaign step, and who authorized enabling the campaign, so that any later complaint can be traced.

The fourth pattern is the quietest: the campaign looks correct, but its triggers never fire because cron is not configured on the target. Mautic depends on scheduled jobs for segment updates, campaign updates and campaign triggers, and its cron jobs documentation says these jobs should be staggered. A fresh server or a rebuilt instance may have none of them in place. Check the scheduler on the target for each job, then confirm that the last-run times advance over a full day, not just once after setup. Enroll a test contact that meets the entry condition and watch whether it moves to the next step. If queued emails are involved, confirm that the messenger consumer is running. Record each job's owner, schedule, last successful run and the result of the test contact, and repeat this check after every server change.