Skip to main content
You already have emails somewhere. Maybe a proper design system in Figma, with variables and components. Maybe a folder of HTML templates on your machine. Maybe they live inside your ESP as templates and campaigns. Either way, the question is whether they can come across to Email Love, how much of them, and what it costs. Point Claude or OpenAI Codex at your emails. Two workflows run one after the other. The first is read-only: it audits what you have and produces a report you can share internally. The second uses that report to rebuild your library as a working Email Love design system in a new Figma file. You review between batches. Your original source is never touched.
Prefer this done for you, design review included? That is Email Love Enterprise onboarding. Email hello@emaillove.com.

​
Where your emails can come from

You pick one of thirteen sources at the start, and the migration adapts to it. All of them produce the same output: a working Email Love design system in a new Figma file, ready for you to build against. Files and Figma:
  • Figma file. Your existing design system or template library in Figma. The richest source, because the audit can read your components, styles, and variables directly. Cross-source deduplication for free. Recommended when you have one.
  • Local folder. A folder of .html files, .eml exports from your ESP, or PNG screenshots. Works when you have your emails saved anywhere on disk. Requires Claude Code or Codex CLI (either agent needs local file access).
  • Google Drive folder. A Drive folder of the same file types via the Google Drive MCP. Works from any Claude or Codex surface with MCP support; no local file access needed. Watch the OAuth scope: drive.file only sees files opened via a Google file picker, so use drive.readonly to walk arbitrary folders.
  • SharePoint folder. A SharePoint site folder via a Microsoft Graph MCP. Same file types as Local Folder and Drive. Heads-up: enterprise IT often blocks third-party OAuth into SharePoint, so confirm your admin allows the Graph MCP’s app registration before assuming setup will work.
ESPs:
  • Klaviyo. Your Klaviyo templates via the official Klaviyo MCP. Discover walks your templates by last-updated; you filter down and approve which to migrate.
  • Marketo. Your Marketo templates via direct REST API calls. No Marketo MCP exists yet, so the migration uses your Marketo OAuth 2.0 credentials (Munchkin ID, client ID, client secret from a LaunchPoint service). Rate-limited to serial fetches, but a full library takes minutes.
  • Customer.io. Your Customer.io Templates and Newsletters via the Customer.io MCP. You pick which of the two pools to walk.
  • Brevo. Your Brevo templates via the official Brevo MCP. Heads-up: a Brevo API key grants full account access; treat it as a high-privilege secret.
  • Kit (formerly ConvertKit). Broadcasts, sequences, or templates via the official Kit MCP. You pick which of the three pools to walk.
  • ActiveCampaign. Your ActiveCampaign campaigns, automations, or templates via the official ActiveCampaign MCP. Drag-and-drop templates convert more cleanly than raw HTML.
  • Iterable. Your Iterable templates and campaigns via the official Iterable MCP. Currently beta, read-only by default, self-hosted via npm.
  • Omnisend. Your Omnisend campaigns, automations, or templates via the official Omnisend MCP. Ecommerce-focused: product blocks that pull live product data lose that wiring on migration and need rebuilding in the target ESP.
  • HubSpot. Your HubSpot marketing emails or email templates via the official HubSpot MCP. Smart content blocks render only their default variant, and CTA-library links do not survive migration verbatim; both would be rebuilt in the target ESP.
For sources other than Figma, the audit report is slimmer (no verdict rollup or scale-factor detection, since those come from Figma-only signals). What you always get: a per-template inventory, brand foundations extracted from the first few items, and an effort estimate. One honest caveat, worth naming up front for the ESP sources. v1 pulls the primary template pool (or the pool combination the adapter surfaces) for each ESP. If your active production content mostly lives in a pool the adapter does not walk, the migration will get your design system foundations right but miss the campaign-level content. Each ESP adapter names its own scope up front: Klaviyo (templates only, not flows/campaigns), Marketo (templates only, not Emails/Content Blocks), Customer.io (Templates and Newsletters, not Automations/Design Studio), and so on. Tell the migration where your active content lives so you do not end up with a partial library and think it is the whole library. v1.1 will extend most of these to their fuller content models.

​
Setup

For any source, you need Claude or Codex with the official Figma MCP connected to a target Figma file. That is where the rebuilt design system lands. Same Figma setup as building emails with the agent, so if you have not done that yet, start there: Build with the Figma MCP. For ESP sources, you also need to connect that ESP’s MCP (or provide REST credentials for Marketo, which does not have an MCP yet). For cloud sources (Google Drive, SharePoint), you connect that provider’s MCP. The migration walks you through this at Step 0.

​
What the audit gives you

Kicked off in Claude or Codex, the audit reads your file (nothing else) and produces one markdown report. It runs in minutes. The report tells you:
  • What your library actually reduces to. Finished emails are built from a handful of reusable blocks (a hero, a copy row, a footer) repeated in different orders. The audit finds those blocks, deduplicates them, and shows the real count. In one recent migration, six emails came out as nine distinct modules, so the work was building nine things once, not rebuilding six emails.
  • What happens to each block in email. Most convert as live, selectable text. Some become editable images (composed art where text and imagery genuinely interleave). A few will not translate to email at all (carousels, hover states, viewport-relative layouts), and the report says what would replace them.
  • Your brand foundations. Type ramp mapped to email-safe fallbacks, palette, spacing, buttons, and the email width your version gets built at.
  • What a designer should look at. Fonts you cannot use in email, component masters living in a library file that was not shared, inconsistent widths, image-heavy blocks that need alt text.
  • Effort as a range. Counts per module type and designer-days as a range, firming up after the first converted batch.
The report is written for both your team and ours, so it doubles as the scoping document if you want us to run the migration for you.

​
What the conversion does

Once you approve the audit, the same agent uses it to rebuild your library in a new Figma file. It runs in two phases: foundations once, then modules in batches with design review between them. Foundations is the scaffold: your type ramp as text styles on email-safe fallbacks, your buttons as real email components, your spacing, your logo and recurring imagery, plus a documented file structure (cover, getting started page, foundations sheet, type specimen, one page per module category). A teammate who did not build it can open the file and get to work. Module batches work down the audit’s list a handful at a time, one component per module. For each block: the agent screenshots your source, generates the correct email structure, transcribes it into the target file, wires up the mobile version, turns it into a component with properties for what a marketer will actually change, and verifies against the original. Between the module build and the design review, the agent uploads the batch to your plugin library provisionally and renders it through the plugin’s own mobile preview. That is the check that catches column widths breaking words mid-string on phones, aspect ratios stretching, or a stacked column carrying its desktop gutter as a stray indent. Figma’s canvas cannot show any of those, so we render them from the actual exporter instead. A design review gates the next batch. This is where the theme colors get confirmed, where the type mapping meets real copy, and where you catch anything wrong before it multiplies. Converting a whole library in one unreviewed pass is how you end up redoing all of it.

​
Two things you will see in the built library

Both are intentional, both save you a step, and both surprise people who do not know to expect them. Fonts on the standard email-safe stack render in Arimo. If your fallback stack is Helvetica Neue, Helvetica, Arial, sans-serif, or any subset of it, the built library uses Arimo on the Figma canvas. Arimo is a metrically identical clone of Arial (same character widths, same line heights) and it exists in Figma’s font environment where Helvetica and Arial do not. Your exported HTML says font-family: Arimo until you or your ESP swap it for Arial at send time. The foundations report states this so it is not a surprise. The footer unsubscribe link is unsubscribe.com. The plugin substitutes that magic value with your ESP’s actual unsubscribe merge tag at export time, whichever ESP you pick. That way the design system stays portable across ESPs: one library, correct unsubscribe on every send. If you already know the specific merge tag you want ({{unsubscribe_url}} in one ESP, [unsubscribe_link] in another), you can hand-type it and the exporter preserves it. See Unsubscribe links.

​
Your source file is never touched

The audit only inspects. The conversion screenshots, downloads assets, and builds everything in a separate target file, either one your team designates or a new one named for the customer. Nothing in your current library gets renamed, restructured, or deleted.

​
Your file does not need to be tidy

Both a pristine email-native library and a messy older file convert. What changes is which parts get carried across. If your file is drawn at real email widths with proper styles and margins, its geometry is preserved as your spec. If it was eyeballed years ago, your brand and structure carry across but the geometry gets rebuilt to clean email standards (600 wide, body copy at 16, spacing in multiples of 8). The audit tells you which kind of file you have, and you can overrule the call.

​
How long this takes

  • The audit is minutes. It reads and creates nothing, so it finishes quickly regardless of library complexity.
  • Foundations is a single pass, roughly one batch of modules in length.
  • A first batch of about five modules takes tens of minutes. On an unstructured source file, longer.
  • A full library of a hundred modules or more takes multiple sessions. Batching with review between is the design, not a limitation.
The bottleneck is round trips to Figma, not the AI. Almost every node the agent creates or reads is a separate call, so a large module takes proportionally longer than a small one.

​
Install

Choose your agent. Claude installs one Email Love plugin carrying the audit, the converter, and the campaign builder. Codex installs one Email Love plugin containing the whole migration workflow.
One install carries all three skills: /email-love:migration-audit, /email-love:eds-converter, and /email-love:figma-builder. Inside an interactive claude session, the same commands work as /plugin slash commands. (Installed one of the old per-skill plugins? It still updates, and its description points you at this bundle.)
The audit needs only read access to your file. The conversion also needs the Email Love plugin installed in the target file.

​
What to expect

  • Start with the audit, always. It is read-only and cheap, and it answers the question everyone actually has: what this costs.
  • Your library is probably smaller than it looks. The audit sizes the job by distinct modules, not finished designs.
  • Verdicts can change on contact. A module classified as clean live text can turn out to be layered art during conversion, and the batch report will say so.
  • Do not skip the design review between batches. Batch 1 always surfaces something.
  • Plan it as a project, not an afternoon. The audit is minutes, a first batch is tens of minutes, a full library runs across several sessions with review in between.
  • Saving modules into a design system needs a paid plan. The audit and the conversion both work on any plan; the Upload control in the plugin’s Assets panel only appears for subscribers.

​
Need help?

Email hello@emaillove.com and we’ll respond within a business day.