Moving email templates into (or out of) Salesforce: a survival guide

When we talk with Marketing Cloud and Account Engagement (formerly Pardot) teams about moving into Salesforce from tools like Mailchimp or HubSpot, or out of it toward tools like Slate or Iterable, the same worry comes up again and again. 

Contacts, data, and automations are all planned for, while the templates usually get attention only when the first campaign on the new platform is already late, and someone is staring at a newsletter that looked perfect in the old tool. Those conversations keep pointing to the same two problems. During the move, layouts break, personalization stops working, footers go missing, and someone ends up rebuilding emails by hand that were supposed to simply move across. After the move, the same template now lives in two places, and the two versions slowly fall out of sync, affecting even teams with no plans to leave Salesforce.

This guide to Salesforce email template migration explains why both problems happen, which habits prevent them, and how to move a template library in either direction, including out of Salesforce, a direction that rarely gets written about. Your templates are far easier to migrate, maintain, and reuse when the design lives in one place, separate from the platform that sends it. 

Problem 1: templates break on the way into or out of Salesforce

The most common shortcut is to copy the HTML from the old platform and paste it into the new one. Sometimes that works fine, but it often causes problems, especially when the code was written for a different editor. Every platform handles code in its own way, sometimes adding to it and sometimes stripping parts of it out, so a template that looked fine before can arrive with broken spacing, missing images, or a layout that no longer adapts to mobile screens. With hundreds of lines of HTML per email, finding the exact cause takes time.

These are the parts that usually need the most attention.

• Responsive layouts. Columns that stacked neatly on mobile in your old tool may stop doing so after the move, a problem some teams have run into in Account Engagement, so test your templates across the email clients and devices your audience actually uses.
• Personalization. Merge tags, the placeholders that pull in a contact’s name or other data, use a different syntax on each platform, so every one of them needs to be checked and adapted. AMPscript takes more work because, as the scripting language Marketing Cloud uses for more advanced personalization, it only runs inside Marketing Cloud, so any logic built with it has to be rebuilt with the new platform’s tools.
• Special sections. Elements like preference centers often have to be rebuilt on the new platform. One news organization we spoke with hosts its preference center in Marketing Cloud but sends some emails from Account Engagement. Because the preference link requires data from both platforms, the team has to swap in its own footer code whenever an email is sent to Account Engagement.
• Platform limits. Salesforce’s Lightning email templates have a 10,000-character limit per component, which longer or more complex emails can easily exceed.

So it pays to give the template work its own place in the migration plan, with time set aside for it, so it doesn’t get squeezed into the last week. Whoever ends up fixing the footer the night before launch will thank you.

Problem 2: the same template ends up in two places

Let’s say the migration went well and your templates now work on the new platform. There’s a quieter problem that tends to show up once the day-to-day work starts.

Many teams design their emails in a separate tool and then export them to Salesforce. That’s a good setup, until someone fixes a typo or swaps a link directly in Marketing Cloud or Account Engagement because it’s faster. That change stays in Salesforce and never travels back to the design tool, so you now have two versions of the same template. Access makes this more likely, because giving more people access to Marketing Cloud typically means paying for more seats. The people who design or write your emails often can’t reach the platform that sends them, so quick fixes get made by whoever can, directly in Salesforce.

Editing in Salesforce can also change the code itself. If your team turns an exported design into a Marketing Cloud template and then edits it in the drag-and-drop editor, Salesforce rewrites the HTML, and the new version isn’t optimized for Outlook, which can introduce rendering issues.

Some connectors, like RGE Studio’s for Marketing Cloud, let you overwrite the version you exported earlier, which keeps your folders tidy. Overwriting still works in one direction only, though, so a fix that exists only in Salesforce won’t survive the next update from the design tool. Over time, someone has to compare versions, figure out which one is right, and copy changes from one place to the other. It’s the email version of two people editing the same document offline, and it usually ends about as well.

If an email is already part of an active journey in Journey Builder, where Marketing Cloud runs automated, multi-step campaigns, an updated export won’t replace it automatically, so you need to reassign the new version inside the journey yourself. The simplest fix is a rule your whole team agrees on, that changes to the design happen in one place only and everything else is a copy of it. At Minnesota State Mankato, for example, a small group handles sending in Account Engagement, while 32 people across 44 departments design emails in RGE Studio (see how their workflow works). Only the final, approved version goes into Salesforce.

How to build templates that survive the move

The two problems have different triggers. Templates break when the sending platform adds code to them or strips parts of it out, or when they rely on features and syntax the new platform doesn’t support. They fall out of sync when edits have no single source of truth. What each platform does to your code is out of your hands, so these habits focus on what you can control, from where the design lives to how it’s built and when the platform-specific pieces go in. Personalization, footers, and automations will always depend on where you send, so the goal is to keep those parts as small as possible. 

1. Keep the design in one place, and write down the rules. Pick one tool as the home for your templates and treat it as the only source of truth. Every edit starts there, and Salesforce receives a finished copy. Then note who edits, who exports, and who will need access after a move, in a short shared document the whole team can find.
2. Build with reusable modules. Save headers, content blocks, and CTAs as modules your team can reuse in every new email. When something changes, like a logo or a brand color, you update it once.
3. Prepare a standard footer. Marketing Cloud requires an unsubscribe link, a profile center link, and a physical mailing address in commercial sends, and Account Engagement requires an address and an unsubscribe option. Other platforms and countries have their own rules, so check them for each one, then save a footer module that already includes everything, along with the merge tags your platform needs. Some design tools also let you save merge tags and special links once, so your team picks them from a dropdown and never has to retype the syntax.
4. Add personalization last. Merge tags and AMPscript are tied to a specific platform. Adding them at the final step keeps the rest of the template platform-neutral, so you only rewrite a small part if you move again.
5. Run the final test from the sending platform. A preview in your design tool shows the design. A test send from Marketing Cloud or Account Engagement shows what your contacts will actually receive, with real data and real rendering.

Moving in and moving out, in practice

To see how these habits work with a real tool, we’ll use RGE Studio as the example of a design tool connected to Salesforce. The same questions apply to any tool you’re evaluating.

Moving into Salesforce. The HTML Importer, available on paid plans, turns the templates you already have into editable designs in RGE Studio. Expect a few light fixes, and add merge tags and AMPscript back after the import, as the Help Center recommends. The Marketing Cloud and Account Engagement connectors then export them to Salesforce. Setup varies by account, from Content Builder access and IP allowlisting to the Classic editor in Account Engagement, so loop in your Salesforce admin early and keep the RGE Studio and Salesforce FAQ close.

Moving out of Salesforce. When your templates were built inside Salesforce and you’re the one leaving, the work usually follows the same steps. This route assumes you’re bringing them into a separate design tool on the way, which is one option among several, and to make it concrete, say you have 50 of them to move.

1. Take inventory. List the templates you still use and the journeys or automations they belong to, then decide which ones to migrate as they are, which to rebuild from scratch, and which to archive. Moving 20 templates is a very different project from moving 50.
2. Save the HTML. The HTML stored in Salesforce is your starting point, so save a copy of every template you’re keeping before you lose access. Before importing, check that each file meets your design tool’s import requirements, such as file size and publicly accessible images.
3. Turn it into editable designs. Import each file into your design tool and expect a few minor fixes after each. In RGE Studio, the HTML Importer has a monthly allowance based on your plan (4 imports on Professional, 10 on Business, custom on Enterprise), so a large library needs a realistic schedule.
4. Check where your images live. Imported emails keep pointing to the original image URLs. If those images are hosted in Salesforce, confirm they’ll remain accessible after the move. If they won’t, rehost them and update the links.
5. Replace what only works in Salesforce. Merge tags need the new platform’s syntax, AMPscript logic needs to be rebuilt, and unsubscribe and preference center links have to point to the new platform. Some platforms also change where personalization lives. In Slate, for example, templates can’t contain merge fields, because there’s no recipient yet, so they’re added when you set up each mailing.
6. Export and test. RGE Studio also connects to platforms like Slate, Iterable, HubSpot, Adobe Marketo Engage, and Braze. Check that every template is connected to the correct campaign or automation, then run tests on the new platform before you switch anything off.

If your designs already live outside Salesforce, you may not need to save and rebuild them at all. Just check that your original designs include any changes made directly in Salesforce, and that their images will stay accessible after the move.

Your pre-migration checklist

The table summarizes what happens to each part of a template when it changes platforms and what you need to do about it.

Before you start, run through these questions with your team.

• Where do our templates live today, and where will the design live after the move?
• Which emails rely on personalization or AMPscript that will need rewriting?
• Which emails are part of active journeys or automations?
• Where are our images hosted, and will they stay online after the move?
• Who will edit, export, and send emails, and do they all have access?

Templates outlast platforms

Templates break during a move when the new platform changes their code or doesn’t support what they rely on, and they fall out of sync afterward when edits happen in more than one place. 

If you’re planning a move, start with the checklist above, then pick one template and take it through every step before moving on to the rest. It’s the quickest way to find out what your migration will actually involve.

Your sending platform may change more than once over the years, but your templates are the part of your email program you keep reusing every time. If the design lives in one place, separate from where you send, the next migration means far less rebuilding, and far fewer people end up staring at a broken newsletter the week of launch. If you’d like to see how RGE Studio could fit into your own move, into Salesforce or out of it, our team is happy to talk it through.