Email template migration: moving templates between ESPs without breaking them

Layout HTML is portable. Everything the platform adds on top is not.

• Personalization syntax. AMPscript in Salesforce Marketing Cloud, Liquid in Braze, and other languages elsewhere do not translate automatically.
• Data references. A lookup against a data extension has no direct equivalent in a platform built around user profiles. The data model has to be remapped first.
• Reusable blocks. Content Builder blocks, Braze Content Blocks and "snippets" differ in how they accept inputs.
• Tracking and links. Click tracking wrappers, UTM rules, unsubscribe and preference links are platform-specific.
• Editor behavior. Drag-and-drop editors add their own markup that does not port well. Code-first templates move more cleanly.

List every template in use, not every template that exists. Old accounts hold hundreds of orphans. For each live template record:

• Where it is used (which flows, campaigns, triggered sends).
• Whether it is code-built or editor-built.
• What dynamic logic it holds: conditional content, lookups, loops, API calls.
• Which shared blocks it includes.
• Last send date and volume.

Retire what is not used. Merge near-duplicates. This audit routinely turns "200 templates" into a much smaller number worth migrating.

Option	Best when	Watch out for
Port as-is	Clean, code-built HTML with little logic	Carrying over old bugs and outdated Outlook hacks
Rebuild on a new base	Messy markup, many one-offs, editor-generated code	More upfront time, but a cleaner result
Rebuild as components	You send many similar emails across flows	Needs an owner for the library

Many teams use the migration as the moment to consolidate into a component set. If you do, read the benefits of email component libraries and design systems and design system vs individual templates first.

For each piece of logic, write down what it does in plain language before translating it. "If the customer has a loyalty tier, show tier banner, else show join banner" is portable. The code that implemented it in the old system is not.

• Conditional blocks become if/else in the new language.
• Loops over products or order lines need the new platform's data shape, such as a Braze event property array or a Catalog.
• Every merge field needs a fallback value.
• API calls at send time (SSJS in SFMC, Connected Content in Braze) need their failure behavior decided.

A migrated template is a new template as far as risk goes. Run the full responsive email QA checklist: client rendering, dark mode, images, accessibility, and a seed-list send with awkward data (blank names, empty carts, long strings). Compare each migrated email side by side with the original for content and links, and check that unsubscribe and preference paths land in the right place.

1. Move low-risk, low-volume templates first to prove the process.
2. Run the old and new in parallel where you can, and compare results.
3. Move transactional and revenue-critical templates last, with a rollback plan.
4. Keep the old platform available for a defined period.

Platform-specific project lists are in the SFMC migration checklist and the Braze implementation checklist.

Template migration needs someone fluent in both the source and target personalization languages and in cross-client email HTML. For in-house teams that is often a specialist hire for a few months. For agencies it is often overflow work for a client project. We do this for brands and white-label for agencies; see email development and agency partners.