​

Migrate your existing email templates

You already own emails. They live at a provider or in an export folder, they carry your brand, and re-drawing them one by one in a new tool is the reason most template migrations never happen. Notifizz migrates them as a corpus, not as files. It reads every template at once, works out which envelopes and which content blocks they are actually made of, folds the duplicates together, and proposes a small library — then stops and asks you a question only you can answer. The whole path runs through an AI assistant connected to Notifizz over MCP. The assistant drives; the analysis and the writes are Notifizz’s.

​

TL;DR

• Ask your assistant to migrate your existing email templates. It calls a read-only tool that returns a guided plan, already carrying an inventory of what your library holds today.
• The analysis is deterministic and costs no AI credits. Notifizz parses the HTML, not the model — so the same corpus always produces the same catalogue.
• Deduplication is on form, not content. Two headings with different words are one block placed twice. Sizes are snapped to a scale and near-identical colours folded into roles, so export drift does not inflate the catalogue.
• The whole corpus goes in one pass. Template-by-template analysis produces one component per template — exactly what the migration exists to avoid.
• You decide the granularity. Sizes and tones can become properties of one block, or distinct blocks. You get the count both ways before anything is created.
• Everything lands in Editing. The assistant never publishes for you.
• Re-running never duplicates. Blocks update on their key; identical images are recognised and reused.
• Some things stay yours to finish: your brand colour, the footer unsubscribe link, any image the export could not reach, the icons that were vectors — and publishing.

​

Before you start

Start it by asking in plain words — “migrate our Mailchimp templates into Notifizz”. In Claude Code, the Notifizz plugin ships the same thing as the /notifizz:email-templates-migration command.

​

The path

​

1 · Collect

Every template, not a sample — cross-template deduplication is the entire value, and it can only see what it is given. Providers that declare the templating engine they used are believed rather than guessed at.

​

2 · Analyse

The HTML is normalised and planned by Notifizz, deterministically. This is not the assistant reading your markup and forming an opinion: machine-generated email HTML fails in a dozen specific and well-known ways — typography hidden on the innermost element under a zero-size container, a section’s background carried by a wrapper rather than the block, a templating loop that closes inside the last leaf, malformed markup the parser has to recover from — and each of those is handled by code covered by tests. An agent re-deriving that each run would produce a different, quietly wrong catalogue every time. Two consequences worth knowing:

• It costs no AI credits. No model is involved in the analysis.
• For a real corpus, the HTML never enters the conversation. The assistant sends it straight to Notifizz from your shell, using a short-lived ticket the plan carries — minted for this migration, valid about an hour, and good for the analysis step and nothing else. If it lapses, restarting the migration mints a fresh one. Nothing about the corpus is stored: the analysis is a pure computation and only the plan comes back.

​

3 · Read the plan

What comes back is compact and readable by a human: The already covered list is the one to read first. A paragraph, a bulleted list, a bold lead-in and an inline link are all markdown, so they are one built-in Text block, not four components. A button already renders in your brand colour. What genuinely needs a new component is what markdown cannot express: a styled heading, and anything sitting on a coloured block background. Findings you should expect to see, and act on:

• how many of the forms found are already covered, and therefore how many components actually remain to create;
• images the export cannot reach — a relative path such as img/9f2c.png means nothing outside its original host — with the templates they affect;
• components that appear exactly once, the first candidates to drop or merge;
• anomalies in your own source templates: a social icon whose glyph contradicts the link it points at, a block whose styling was lost to malformed markup. You are looking at the first pass that has ever read all your templates at once; that information is worth keeping.

​

4 · The gate — your call

The assistant stops here and asks one question, because it is genuinely yours:

Sizes and tones can become properties of one component — a smaller library, slightly less faithful — or distinct components — a larger library, more faithful. Which do you want?

You get the number both ways, counted after subtracting what the built-in blocks already cover. Three sizes of body text are one block with a size setting, or three entries in the palette. There is no right answer; there is your brand’s tolerance for drift versus your team’s tolerance for a crowded palette. If you keep sizes distinct, insist that the size appears in each block’s name — Text 14, Text 16. A fine-grained catalogue nobody can choose from is a burden, not fidelity.

​

5 · Create

Nothing is written before you confirm. Then the order is fixed, because each step depends on the one before: Everything is created in Editing. Every component passes the same two checks as a hand-written one: the code check and a render through the send path, both before anything is stored — so the migration cannot leave you with a block that previews and then fails on send.

​

6 · Review and publish

Open Settings → Layouts and Settings → Sections, look at what came in, and publish what you want to use. Publishing is a human act, always: the assistant has no way to do it for you.

​

What stays yours to finish

The migration is honest about its boundary. These five things are not oversights — they are decisions or inputs that only you have.

​

Set your brand colour first

Not after. A component built before your brand colour exists tends to carry a hard-coded hex, and a hard-coded hex is a component that will not follow your next rebrand. Set the colour, then migrate.

​

The footer unsubscribe link

Your old templates carry the previous provider’s unsubscribe tag — or nothing at all, because that tool injected the link at send time. Neither works here. Every layout needs exactly one footer link whose destination is Notifizz’s reserved unsubscribe placeholder, filled per recipient and stripped entirely on transactional mail. A migrated layout saves without it, but will not publish. If a layout refuses to go live, this is almost always why.

​

Images the export could not reach

They are listed for you to supply, and deliberately not replaced with a stand-in. A component with a silently empty image passes review and breaks in the recipient’s inbox — strictly worse than a component that is visibly missing. Vector sources need one manual step too: render the SVG to PNG and upload that. SVG uploads are refused on purpose, and pulling the raster image out of an SVG usually yields bytes that only decode inside their parent — a logo that looks fine in the gallery and arrives truncated.

​

Icons are images, never inline markup

Inline SVG is rejected by the code check, and Gmail strips it anyway. Every icon becomes a PNG in your gallery.

​

Composition, subjects and data binding

The migration builds the library — the reusable blocks. It does not create campaigns.

• Subject lines belong to a campaign’s email step, not to the library.
• Placing blocks into an email is a separate step, in the campaign.
• The merge variables of your old engine are not mapped across. Dynamic values become typed properties on the components; binding those properties to live event or enricher data happens in the campaign, where the orchestrator does it.
• Loops and conditionals from your old engine do not survive as syntax. A repeated block becomes one list property; a block that only some sends include becomes an on/off property. The plan tells you how many placements sat behind a condition so you can spot them.

​

What a good outcome looks like

A corpus of seventy templates does not need seventy layouts. It needs two or three envelopes and a small set of blocks placed hundreds of times. If the plan proposes forty sections, something upstream is wrong — usually the granularity choice, or look-alikes of blocks that are already built in. A bloated library is worse than no migration: it is what you will spend the following week deleting by hand. The count to judge is components to create, never forms found.

​

Running it again

The migration is designed to be re-run — after fixing the source templates, after supplying the missing images, after changing your mind about granularity:

• Components update on their key. A second run edits the same block instead of creating a twin.
• Assets are recognised by their content. Re-uploading the same bytes returns the image already in your gallery.
• The plan opens with your current library — the layouts, sections and assets you already own — so the assistant updates what exists instead of recreating it.

The one thing a re-run does not cover is a block you have already published. Publishing freezes a component, so a migration that tries to rewrite one is refused — defaults are frozen once the component is published. Re-run before you publish, or open a new version of the block first; see versions and pinning.

​

Troubleshooting

​

See also