How a team moves off Klaviyo and onto Mautic without losing its contact base
Profiles and consent can be exported from Klaviyo to CSV and imported into Mautic, but events, message history and automations must be rebuilt. Teams usually start this move at a renewal, when a data residency requirement applies, or when leadership wants the contact database under its own control. The contact base is the part worth protecting, so the first deliverable is a clean profile file with email addresses, subscription status and the consent evidence that goes with each address. Everything that describes how a customer behaved in the store is a different problem and does not travel in the same file.
Marketing operations usually owns the move, because they know the lists, segments and sending rules that must survive. An engineer is needed for the parts that are not marketing work: provisioning a VPS or dedicated server (Mautic is not meant for shared hosting), installing Mautic, setting up the cron jobs that drive segment and campaign updates, and wiring the store's order and product data back into Mautic. Before any import, confirm which fields in your Klaviyo export map to Mautic contact fields, and decide how unsubscribed and suppressed addresses will be marked so they are never mailed again.
The effort is driven less by the contact count than by how many flows, forms and SMS sending numbers the business runs. Ask your Mautic hosting provider or internal team to confirm the installation path and the supported PHP and database versions for the release you choose, and plan a parallel run in which both platforms are checked against the same test contacts. Keep the Klaviyo account active until the new sends are verified and the SMS number porting question is answered, because some of that data cannot be recovered once the subscription ends.
Which Klaviyo capabilities map to Mautic, and which need rework
This table maps each main Klaviyo capability to its closest Mautic equivalent and labels the migration effort as clean, needs rework or gap. Read it as a planning checklist, then confirm each item against the Mautic version you plan to run, since plugin and feature support changes between releases.
| Klaviyo capability | Mautic equivalent | Migration note |
|---|---|---|
| Profiles and lists | Contacts and segments imported from CSV | Clean for basic fields. Map custom properties to Mautic contact fields before import and check for duplicate emails. |
| Consent and suppression | Contact do-not-contact and channel preferences | Needs rework. Export consent status and dates from Klaviyo, then confirm how Mautic records each channel before importing anything you will email. |
| Segments | Segments built on contact fields and behavior | Needs rework. Klaviyo segments built on e-commerce events must be rebuilt on fields you import or on data your store sends to Mautic. |
| Flows (event-triggered automations) | Campaigns with triggers and actions | Needs rework. Flows must be rebuilt by hand. Mautic campaign timing depends on cron jobs that you must schedule and monitor. |
| Campaigns and templates | Emails and broadcast segment emails | Needs rework. Templates are not exported in a portable form, so recreate them in Mautic's editor and test rendering across clients. |
| Sign-up forms and landing pages | Forms and landing pages | Needs rework. Rebuild each form, its double opt-in step and its embed code, then update every site that loads the old Klaviyo script. |
| SMS | No native SMS channel in the core product. Use a plugin or your own SMS provider | Gap or dependency. Confirm which SMS integration your Mautic version supports, and plan number porting with your provider, not Klaviyo. |
| Store data (e-commerce events and product feeds) | Contact activity and data sent by your store integration or API | Gap. Klaviyo builds order and browse events natively. Mautic needs an integration or custom connector to receive them. |
| Analytics and message history | Mautic's built-in email and campaign reporting for new sends only | Gap. Past event and message history does not transfer, so archive Klaviyo reports before cancelling. |
What exports to CSV, what stays behind, and what to reconnect
Klaviyo data falls into four groups with different exit paths. Profiles and consent move as files, while event history, message history, SMS numbers and store connections need separate decisions. Settle each group before you cancel, because some of it cannot be recovered later.
Profiles and consent
Export profile lists and segments from Klaviyo as CSV, including the consent status and timestamps your compliance team needs to keep. In Mautic, import the file through the user interface, where columns are mapped to contact fields automatically, then correct any mismatches before the import runs. For large files, Mautic recommends a background import with the mautic:import console command run by cron, processed in batches of 100 rows by default. Confirm the Klaviyo export limits for your own account, since column counts and file sizes depend on the list. Check that opt-in and opt-out status carried over correctly, and do not import contacts who lack a documented basis to email them.
Event and message history
Klaviyo's event feed, placed orders, profile activity and past message sends are generally not carried into Mautic as a file you can import. Decide which of this history your compliance, support or audit needs will require, and archive it before the account closes. Export reports or raw data you can access, and store them in a retention system you control. Plan for the fact that Mautic starts with a clean activity timeline, so campaign and suppression logic will rely only on what you migrate or what the new system records from cut-over onward.
SMS numbers
Phone numbers can be migrated only if the messaging provider on each side supports it, and the process depends on the carrier and the new SMS provider you choose. Mautic does not own your SMS numbers, so the number must be ported or moved through the provider that holds it. Ask the new provider and your current carrier whether porting is possible, how long it takes, and whether opt-in records transfer with the number. Keep sending on the old number until the port is complete, and check which subscribers have granted SMS consent before you reactivate messaging.
Store integrations and event feed
Your e-commerce platform connections, product feeds, abandoned cart triggers and order events must be rebuilt in Mautic rather than copied across. Mautic relies on its own API, webhooks or middleware to receive store events, so map each Klaviyo trigger to a Mautic campaign or an external workflow before cut-over. Test order, cart and refund events in a staging environment. Ask whether your platform has an existing Mautic connector, and confirm which events it sends and at what frequency. Your team will also need the cron jobs for segments and campaigns running reliably to process these events.
The migration sequence from inventory to decommission
This sequence moves Klaviyo sending to Mautic in controlled stages, so each list, consent record and flow is proven in Mautic before any live message depends on it. It ends with a Klaviyo account that is closed only after your retention exports are complete and checked.
Inventory every list, consent source and flow
Your team, with whoever owns the Klaviyo account, lists every profile list, segment, flow, sign-up form, SMS number and store feed in use, and records where each consent came from and how it was captured. Include sending domains, sender authentication settings and the suppression reasons you rely on. The step is done when every active sending path has an owner and a named Mautic replacement, and anything without one is flagged for a decision.
Export and pilot a sample list
Export one representative profile list to CSV from Klaviyo and import it into a separate Mautic test instance, using the web importer for a small file. Check that Mautic maps each column to the correct contact field, that consent and subscription status arrive as intended, and that suppressed or unsubscribed addresses stay suppressed. Your team signs off the mapping in writing. The step is done when a sample of records, chosen by the team, matches the Klaviyo source field by field.
Run a controlled parallel send
Build the equivalent campaign and one automated flow in Mautic, then send both versions to a small, controlled segment that is excluded from the live Klaviyo sends for the same message. Compare inbox placement, bounce and complaint signals, unsubscribe handling and link tracking across the two systems. Confirm that Mautic's cron jobs and the messenger consumer run on schedule, since queued email and segment updates depend on them. The step is done when results are reviewed and every gap has a fix or an accepted risk.
Cut over sending and re-point inputs
Move each list and flow to Mautic in a planned order, and switch sign-up forms, landing pages and store event feeds so new subscribers and purchase events reach Mautic. Port SMS numbers only through a process your SMS provider confirms, and keep Klaviyo paused for any path not yet moved. Watch sends and form submissions closely for the first cycle after each switch. The step is done when no active send or input still points to Klaviyo, and a checklist signed by the owner confirms it.
Archive exports and close Klaviyo
Before closing the account, export what Klaviyo allows, including lists, segments and templates, and store the files in your own retention system with access controls. Record what could not be exported, such as event and message history, so your compliance owner can decide whether that gap is acceptable. Confirm the retention requirements with your legal and compliance teams before deleting anything. The step is done when the archive is verified, the gaps are documented and the Klaviyo account is closed.
What drives the cost and duration of the move
This table lists the factors that change how long the move takes and what it costs, with one-time and recurring effects noted in each row. Use it to scope the work before requesting a quote, since most of the variation comes from list size, consent history and how many flows and forms must be rebuilt. The main takeaway is that the data you can export cleanly is only part of the job, and the rebuild and hosting work usually dominates.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| List count and size | Each list and segment must be exported, mapped and recreated in Mautic, and large contact sets need background imports run by cron rather than the browser upload. | Consolidate duplicate lists and archive inactive segments before export so only active audiences are moved. |
| Consent records and their sources | Consent status and the source of each opt-in must travel with the contact, and Klaviyo's export does not give you a complete audit trail of how consent was captured. | Export consent fields for every list, document the sign-up source per form, and suppress contacts with unclear consent instead of importing them as opted in. |
| Number of flows and forms | Each Klaviyo flow is rebuilt by hand as a Mautic campaign, and each form and landing page is recreated, so the rebuild effort grows with the count. | Inventory flows by business purpose, retire unused ones, and rebuild the top revenue flows first. |
| SMS number porting | Phone numbers and opt-in records for SMS depend on the carrier and SMS provider, and Mautic does not take over a Klaviyo SMS number on its own. | Confirm porting timelines and ownership of the number with your SMS provider before cancelling Klaviyo. |
| Store integration complexity | Product, order and cart data that drives Klaviyo segments must be reconnected to Mautic through your store's API or a connector, which is custom work. | List every store event and property your segments use, then map each to a Mautic field or integration before cutover. |
| Custom fields | Each custom profile property needs a matching Mautic contact field with a compatible type, and mismatches cause import errors or lost values. | Create the field map in a spreadsheet and agree it with the implementer before the test import. |
| Event history retention needs | Klaviyo event and message history cannot be exported in full, so any reporting or audit need for past activity requires a decision on what to archive and where. | Export the analytics and history you need for reporting in advance and store it in your own warehouse or archive. |
| Team hosting skills | Mautic runs on a PHP and database stack with cron jobs and a messenger consumer, so patching, backups and queue monitoring need someone who can operate it. | Confirm internal ownership of the server, or contract ongoing operations, and document the cron schedule from day one. |
What usually goes wrong and how to prevent it
Most failed Klaviyo exits do not fail on the import itself. They fail on consent that was not carried over, sending infrastructure that was not ready, and background jobs that nobody watched after go-live. Each card below names one risk and the check that prevents it.
Consent and suppressions lost on import
A CSV of profiles does not carry Klaviyo's suppression history or consent records unless you export them deliberately. Before importing, export unsubscribes, bounces and spam complaints as separate files and map their consent status explicitly in Mautic. Import suppressions before any marketing contacts so previously opted-out people are never mailed again. Confirm with a small test batch that do-not-contact flags landed on the right records.
Sending from a new domain unprepared
Moving sending to Mautic usually means a new sending domain or a changed envelope, and mailbox providers judge that domain from scratch. Configure SPF, DKIM and DMARC for the sending domain before the first live send, and ask your mail provider what warm-up schedule it recommends. Start with your most engaged contacts rather than the full list, and watch bounce and complaint rates closely during the first sends.
Flows rebuilt without exit logic
Klaviyo flows carry exit conditions, such as leaving a welcome series after a purchase, that are easy to lose when rebuilding them as Mautic campaigns. Document each source flow, its trigger, its goal and its exit rule before you rebuild anything. Test each campaign with internal seed contacts who meet and then leave each condition, and confirm that a contact who converts stops receiving the remaining steps.
Cron jobs that stop running
Mautic updates segments, campaign membership and campaign triggers through cron jobs, and it sends segment emails through a broadcasts command. If those jobs stop, segments go stale and campaigns stall without any visible error on the dashboard. Stagger the cron schedule as the Mautic documentation advises, add monitoring that alerts when the jobs stop, and confirm that the messenger consumer runs whenever emails are queued.
SMS numbers lapsing during porting
A Klaviyo SMS number is tied to your account and carrier relationship, and a number that lapses during a port can stop inbound opt-outs and replies. Ask Klaviyo for its number-porting procedure before you cancel, and confirm with your SMS provider whether the number can move. Keep the old account active until the port completes, and reconcile opt-out keywords on the new route before any SMS campaign runs from Mautic.
Missing event history for audits
Klaviyo does not export the event and message history, so questions about when a customer opted in, what they were sent or what they bought may have no answer after cancellation. Export what Klaviyo does provide, including analytics and template files, and store them with a dated record of the migration. Ask your compliance team which records they must retain and for how long before the old account closes.
What the Mautic side needs before the first import
Decide where Mautic will run before anything is exported from Klaviyo. The hosting requirements are the first gate: 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 a web server such as Apache, Nginx or IIS. npm is also required from Mautic 5.0 onward, so the build tooling must be installed on the server or on the build host. The project states that Mautic should not be installed on shared hosting and recommends a VPS or dedicated server. Confirm these details against the Mautic requirements page for the exact version you plan to deploy, because the supported PHP range changes between releases.
Plan the background processing as part of the platform, not as an afterthought. Segment updates, campaign updates and campaign triggers run from cron jobs that the documentation says should be staggered, and scheduled broadcasts need a broadcasts command. When emails are queued, a messenger consumer must also run, or sends will stall without an obvious error. For the initial load, do not rely on the browser upload for a large Klaviyo export. Run the mautic:import console command in the background, since it processes rows in batches of 100 by default. Test the import on a copy of a small file first, then confirm that segments rebuild and that a test campaign triggers as expected before you move any live audience.
Choose the Mautic version to match how long you intend to run it. Mautic 7.2 (Absolunto) has active and security support until 30 September 2026, which suits a short transition. Mautic 7.3 is planned as the long-term support release, with security support through 31 December 2027, so it is the stronger choice if the platform will run for several years. Confirm the status of 7.3 on the Mautic releases page before you commit, since a planned release can change. Whichever version you select, schedule the upgrade path in advance, and budget for the operations work that recurs: patching, backups, cron monitoring and mail delivery management.
How the move differs by list size and starting point
A store with a modest contact list, a welcome series and an abandoned cart flow usually has the smallest migration. The main work is moving the list and consent records cleanly, then rebuilding two or three automations in Mautic and checking that they fire as expected. Because the flow count is low, one person can often own the full cutover, but the loss of Klaviyo's event and message history still needs to be planned for.
- Scope: Export the profile list and consent status to CSV, then confirm which fields map to Mautic contact fields before importing.
- Sequencing: Import contacts first, set up forms and the welcome series second, and move the abandoned cart logic last, since it depends on live store events.
- Testing: Send test messages to internal addresses and trigger each flow with a test cart before going live.
- Overlap: Run both platforms for a short period so the old flows finish their queued messages before you cancel.
- Records: Keep a dated copy of the exported consent data and the Klaviyo history you can still access.
Confirm with your team whether your current Klaviyo plan offers a fuller export of the lists you need, and whether your store platform can send the cart events Mautic will depend on.
A store with a large contact base, many overlapping flows and active SMS programs needs a phased plan. Mautic handles segments, campaigns and cron-driven processing, but each flow must be rebuilt and tested against the segments it reads. SMS is the most sensitive part, because sender numbers, opt-in records and carrier registration all determine whether messages keep flowing after the switch.
- Scope: Inventory every flow, segment and SMS program, then decide which ones to rebuild, simplify or retire.
- Sequencing: Migrate one flow family at a time, starting with low-risk campaigns, and move SMS only after consent records are verified.
- Testing: Check segment membership counts in Mautic against Klaviyo exports before enabling any send.
- Scheduling: Plan background imports and the cron jobs that update segments and campaigns so large runs do not compete with live sends.
- SMS: Confirm with your SMS provider how number porting and sender registration work, since this can take longer than the software work.
Confirm your SMS provider's porting timeline and any carrier registration requirements in writing before you schedule the cutover.
A team that already sends profile and event data to Klaviyo from a warehouse or custom backend has a different problem. The contact list is only part of the job. The real dependency is the feed that keeps profiles, properties and events current, so the migration is mainly an integration project. Mautic can receive contacts through its import tools and API integrations, but the team must decide which source becomes the system of record during the transition.
- Scope: Map every field the feeds send to Klaviyo and decide where each one lives in Mautic or in your warehouse.
- Sequencing: Point the feeds at Mautic in a staging instance first, then switch production feeds one source at a time.
- Testing: Compare contact counts and key attribute values between the warehouse and Mautic after each feed moves.
- Event data: Treat the Klaviyo event history as lost unless you exported it earlier, and rebuild any triggers from the source data instead.
- Ownership: Name one team responsible for the feed logic, since duplicate or conflicting updates are the usual cause of wrong messages.
Confirm which integrations your engineers can build and maintain in Mautic, and whether the warehouse already holds the consent and event history you need.
Questions buyers ask before moving from Klaviyo to Mautic
How much does moving from Klaviyo to Mautic cost?
The cost is driven by components, not a single license fee, because Mautic has no paid edition of the software itself. The main costs are the hosting you provision (a VPS or dedicated server, since the project advises against shared hosting), the engineering time to install, configure and connect Mautic to your store, the rebuilding of flows and forms, the SMS provider contract, and ongoing operations such as upgrades and backups. Setup costs are largely one-time, while hosting, SMS fees and maintenance recur. Ask any quote to split these components, state who pays the SMS provider directly, and show what is included in ongoing support. DeployOpen does not publish prices; a quote follows from a written scope.
How long does a Klaviyo to Mautic migration take?
The pace depends on the volume of profiles and consent records, how many flows, segments and forms need rebuilding, how cleanly your store data maps to Mautic, and how many channels you move at once. Large CSV imports are best run as background jobs using the mautic:import console command under cron, which processes rows in batches of 100 by default, so import size affects scheduling. SMS number porting depends on your carrier and SMS provider, so confirm that lead time early. Ask for a written timeline tied to the agreed scope rather than a generic estimate.
Can our internal team migrate from Klaviyo to Mautic without outside help?
Yes, a team with server administration and PHP experience can install Mautic and import contacts, but the work is broader than a data export. Mautic depends on cron jobs for segment updates, campaign updates and triggers, a broadcasts command for segment emails, and a messenger consumer when emails are queued, all of which need monitoring. The team also has to rebuild flows and forms and reconnect store events, which Klaviyo handles in its own platform. Assess your team's capacity for ongoing operations honestly, and consider a fixed-scope engagement for setup and a retainer for upgrades if in-house time is limited.
What does the marketing team and the engineering team each need to provide?
Marketing owns the content and logic: templates, segment definitions, consent wording, campaign calendars and the list of flows to rebuild, along with sign-off on test sends. Engineering owns the infrastructure and integration: provisioning the server, the database and the mail transport, scheduling cron and the messenger consumer, connecting the store's order and browsing data, and setting up backups and access control. Both teams should agree early on which Klaviyo data is authoritative, since the exported CSV files do not carry everything Klaviyo holds.
Can Klaviyo event history be carried over to Mautic?
Event history generally cannot be carried over as a complete record through a standard CSV export of profiles and lists, so confirm this with Klaviyo's own export documentation before you cancel. Profile, list and consent data can be exported to CSV and imported into Mautic, while the historical event stream and message history typically stay behind. Plan to keep a dated archive of exports for reference, and rebuild the behavioral triggers you still need from your store and event sources going forward. Decide which historical data your compliance or marketing teams actually need before you assume it will be available in Mautic.
Do SMS numbers and consent records transfer to Mautic?
Consent records can move as data if you export them and import them with their status and dates, but you must verify that each record's consent basis is clear enough for Mautic's import and for your legal obligations. SMS numbers are a different matter: porting depends on your carrier and your SMS provider, and the number's registration and opt-in history must be confirmed in each system. Mautic does not hold your SMS number on your behalf, so the provider relationship and opt-in evidence need to be planned explicitly. Ask your counsel and your SMS provider to confirm what they require before cutover.
Does DeployOpen handle the whole migration and its compliance evidence?
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. DeployOpen can prepare systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Ongoing support, upgrades and continuous testing are available as retainers.
How DeployOpen scopes, runs and supports a Klaviyo to Mautic move
DeployOpen is a Chainscore Labs company that plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Klaviyo to Mautic move, we start with a written scope that covers the profile, consent, flow and store data your team needs to carry across.
How we scope
- Inventory profiles, consent records, lists, segments, flows, forms and SMS numbers that the written scope must cover.
- Confirm what Klaviyo can export and record which event and message history stays in the archive.
- Agree in writing which store integrations, domains and sending infrastructure move in the engagement.
How we build
- Install Mautic in your own cloud account or data center, following the supported PHP and database requirements for the chosen release.
- Map CSV columns to Mautic fields and import consent flags with tests on a sample before the full load.
- Rebuild flows, forms and cron-driven segment and campaign jobs, then test each one against the agreed acceptance criteria.
How we hand over
- Deliver runbooks for cron jobs, the broadcasts command and the messenger consumer, with staggered schedules documented.
- Provide an import and mapping record that shows how each Klaviyo field was carried over or deliberately left out.
- Walk your team through the rebuilt flows and the list of items that could not be exported from Klaviyo.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, with the scope agreed in writing.
- Plan Mautic upgrades against the published release and support dates, and confirm the target version with your team.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.

