> ## Documentation Index > Fetch the complete documentation index at: https://notifizz.com/llms.txt > Use this file to discover all available pages before exploring further. # Migrate Your Existing Email Templates > Import the emails you already own — Mailgun, Mailchimp, Klaviyo, an export folder — into your Notifizz email library: what the analysis produces, what the migration creates, and what stays yours to finish. # 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. **This page needs two people, briefly.** A developer (or whoever holds the provider credentials) runs the assistant and fetches the templates. Someone on the marketing side answers the one question in the middle — how faithful versus how simple the library should be. Everything else is automatic. ## 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 | | | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Your templates | Reachable at their provider, or as a folder of HTML. The assistant fetches them with **your** credentials — those never reach Notifizz. | | An AI assistant | Connected to Notifizz over MCP — see [connect your AI tool](/docs/ai/connect-your-ai-tool). The connection is set up from **Settings → AI tools**. | | Your brand colour | Set it in your brand settings **first** — see [why](#set-your-brand-colour-first) below. | | A rough idea of your library | Nothing to prepare; the plan opens with an inventory of the layouts, sections and assets you already have. | 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 ```mermaid theme={null} flowchart LR P["Your provider
or export folder"] --> C["1 · Collect
every template"] C --> A["2 · Analyse
whole corpus, at once"] A --> R["3 · The plan
assets, layouts, sections"] R --> G{"4 · Your call
faithful or compact?"} G --> B["5 · Create
brand, assets, layouts, sections"] B --> V["6 · You review
and publish"] ``` ### 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. **Never analyse templates one at a time.** Deduplication only sees the templates analysed together — one call per template yields one component per template, and a library nobody wants to clean up. ### 3 · Read the plan What comes back is compact and readable by a human: | Part of the plan | What it tells you | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Corpus** | How many templates were read, and how many section placements they contain in total | | **Assets** | Every distinct image and icon, how many templates use it, and **whether it can actually be fetched** | | **Layouts** | The distinct envelopes found — footer background, social links, whether there is a logo, the distinctive footer lines that make each one its own thing, and — when only a handful use it — which templates those are | | **Sections — to create** | The forms that genuinely need a component: how often each is placed, in how many templates, how many raw variants folded into it, how many placements sit behind a templating condition, and a sample of its text | | **Sections — already covered** | The forms a **built-in block already handles**, with which one and why | | **Findings** | Everything a human must arbitrate or supply | 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: Set in your brand settings, so the built-in button renders in your brand everywhere — instead of a hard-coded hex that severs the link and survives your next rebrand. Uploaded into your gallery, so layouts and sections can point at real URLs. **Identical images are recognised and reused**, so a second run leaves the gallery unchanged. Created as envelopes, with the dominant one marked as your default. Only the forms the plan marked as needing a component — with their default values and their private brand properties frozen together. 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](/docs/concepts/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](/docs/concepts/email-library#lifecycle-editing-then-live). ## Troubleshooting Two usual causes. Either the granularity answer was *distinct* on a corpus with a lot of style drift — ask for the *merged* count and compare. Or the plan's **already covered** list was skipped and the assistant is rebuilding text, list, link and button blocks that ship with Notifizz. Ask it to create only the forms the plan marks as needing a component. It has no unsubscribe link, or it has two. A layout needs exactly one footer link pointing at the reserved unsubscribe placeholder — a hard-coded link to your own preference page does not qualify, because Notifizz has to fill it per recipient and remove it entirely on transactional sends. Migrated footers almost always carry the previous provider's tag instead; rewrite that one link. A component must render with nothing but its own default values — that is checked, through the real send engine, before anything is stored. The error names the cause. The usual one is a property with no sensible default: an image with no placeholder, a list with nothing in it. Its code reaches for something an email component may not use — most often raw HTML injection, which is how inline SVG icons get smuggled in. Icons are images. The other refusals are imports beyond React and the email component library. Check the plan's asset list: an image marked as unreachable was never imported, on purpose, and is waiting for you to supply the file. If it was imported but looks wrong, it is probably a vector that was extracted rather than rendered — render the source to PNG and upload that. Layouts, sections and stored images are capped by your plan, counted live. Archive the components you are not keeping, delete the images you no longer need — archiving an image hides it but keeps its bytes — and re-run. Nothing already created is affected. See [what your plan caps](/docs/concepts/email-library#what-your-plan-caps). It is valid for about an hour by design, and only for the analysis step. Ask for the migration plan again; the new one carries a fresh ticket, and the inventory it opens with is up to date with whatever you already created. Yes. The analysis reads HTML, and treats the provider only as the place the HTML came from — anything that can be exported as HTML works, including a folder of files. Where a provider declares the templating engine it used, that declaration is used instead of a guess. ## See also Layouts, sections, assets — what the migration is filling. Where the brand colour the migration relies on is set. The one-time setup the migration runs on. Where the migrated blocks are composed into an actual email.