If you thought choosing the new email service provider was a daunting task, now you\u2019re on to the next one, which might be just as daunting: Making the switch.
\nBelow is a short list of what you\u2019ll likely need to move over (and how) to help you get started with your migration\u2026well prepared. Because the smoother, easier and faster it happens, the sooner you\u2019ll be up and running with your new ESP! <\/p>\n
(One note of caution before you start: Keep in mind that a lot of what happens first is figuring out what<\/strong> to move by documenting your assets and evaluating which ones will go with you.)<\/p>\n Obviously you\u2019ll want to export your in-house email lists to the new ESP. Keep in mind this includes any segmented lists within your lists. All of your list, segmentation and data structure should be determined and built before any migration of data. This also means all attributes from the lists exported from your old email service provider must be added to your new email service provider. <\/p>\n Once the attributes are added, then you can import your lists and map them within the new ESP. While preparing for the move, be sure to record both static and dynamic segments so these segments can be re-created in your new email service provider<\/a>.<\/p>\n For consistency during the move, we recommend keeping the same naming convention on all lists. In addition, one last list hygiene check is also in order just before you move your lists. We recommend cleaning lists via a third-party tool such as BriteVerify<\/strong> or Email Answers<\/strong> before exporting.<\/p>\n The next task is deciding which email content and templates (both HTML and text) you want to port over to new email service provider. As with the lists, we recommend keeping the same naming convention on all assets, for consistency during the move.<\/p>\n You\u2019ll need to determine if the emails in the old ESP are to be created in the new ESP as HTML or as templates. If you\u2019re planning on creating new templates, make sure you have the internal resources or a partner lined up to the help with that.<\/p>\n If you prefer HTML, the code for those HTML emails to be ported over must be copied and pasted into a text app or an HTML file. These then need to be copied and pasted into the content section of templates in the new ESP.<\/p>\n Within your templates, all system-generated links (such as \u201cview as a web page,\u201d unsubscribe, etc.) need to updated with the new ESP\u2019s equivalents. Also, all new image paths must be updated and integrated into the HTML where appropriate.<\/p>\n Finally, figure out how you want to handle the header and footer: custom, default or hardcoded into each HTML template? Or choose to set these up as content that\u2019s selected based on delivery profiles.<\/p>\n You\u2019ll want all of your old data too, so export all historical performance data from old ESP and store it. Then document the email reporting you used with the old ESP and replicate it in the new ESP, but also take this opportunity to think through the kind of email analysis you were doing and see if it\u2019s time to change your reporting.<\/p>\n As part of the document inventory that you do before starting the migration<\/a>, figure out which images need to move from the old ESP to the new one. At ClickMail, we recommend that you keep the same naming convention for consistency and to eliminate any chance of confusion. To move the images, simply download the images you\u2019re migrating and then upload them to the new email service provider which will create new image paths.<\/p>\n Moving your important email integrations<\/a> is a bit more complicated compared to moving your images. Inventory all instances of your existing marketing technology stack where there is an API connector <\/a>with the old ESP. <\/p>\n Remember to include everything: your CRM system, web analytics, ecommerce, content management system, and any social platform integrations like with Facebook or Twitter. Next, emulate points of integration via new the ESP\u2019s APIs\/web services calls as appropriate. <\/p>\n As with template creation, before starting on this, be sure you have the internal resources to do it, the new ESP scheduled to help, or an external email technology partner lined up.<\/p>\n Inventory all existing automation before the migration. This includes any drip marketing, lifecycle messaging, trigger-based and event-driven emails\/campaigns, click stream, forms (sign-up pages), social campaigns, cross-channel messaging such as SMS and tweets, and auto-responders. <\/p>\n Be thorough in your documentation as automated marketing can easily be overlooked. Set up these automated emails and campaigns and test them in the new platform before the switchover is made.<\/p>\n You must export your unsubscribes from the old ESP and into the new one. Make sure you distinguish list-specific unsubscribes from universal unsubscribes. Unsubscribes should be processed a second time, preferably 30 days and again 45 days after the last time an email is sent through your old ESP to ensure capture of any stragglers. Include hard bounces in this process. <\/p>\n<\/span>Migrating your email lists<\/span><\/h2>\n
<\/span>Content and templates<\/span><\/h2>\n
<\/span>Reports<\/span><\/h2>\n
<\/span>Migrating images to your new ESP<\/span><\/h2>\n
<\/span>Integrations<\/span><\/h2>\n
<\/span>Marketing automation<\/span><\/h2>\n
<\/span>Unsubscribes<\/span><\/h2>\n
<\/span>Migrating to a new ESP<\/span><\/h2>\n