Relationship One has helped a number of clients migrate from one ESP (Email Service Provider) to another, and we have frequently heard, and used, the phrase “lift and shift.”  These migrations are intended to be an exact replica of the existing platform.  While this sort of migration project is on the more straightforward end of the spectrum, there is always more effort than copy / paste.  

ESPs may share a common function of helping you to get communications to your customers, but how they operate under the hood can vary dramatically.  When migrating from one ESP to another, no matter how closely architected they are, there will never be a 1:1 replication.  Even when merging separate instances of disparate business units into a single instance of Eloqua, things like image links, forms, tracking will need to be updated, and historical data cannot be transferred into the new system.

  • Things to consider as you’re analyzing the migration:
    • Data Structure. Does the existing platform support one-to-many or many-to-many data structures? Do any processes require relational data tables?  These aspects may require an entirely new data structure and may play into decisions about which ESP can actually support these structures.
    • Data Compartmentalization.  Do separate business units need to be housed in different data objects?  Will there need to be separate profile lists for different brands (which is required in Responsys)?  Is there a need to implement contact level security, where groups of contacts are only visible to specific lines of business?
    • Data Transformation. Are there data transformation processes that occur in the old platform that will need to be replicated in the new platform?  There may be limitations with how these can be supported depending on the ESP.
    • Process Improvements.  Are there opportunities to improve upon existing processes?  For example, data that has traditionally been transferred via a file could potentially be transferred more real-time via API or data integrations. With Oracle products, customer activity could even be transferred via Infinity Streams.
    • Third Party Integrations. Are you using any third party tools?  This will need to be analyzed to ensure that your tech stack is compatible with the system you’re migrating to, and they will need to be configured in the new platform.
    • Contact Management.  Now is also the time to think about your overall contact database.  Is there missing data on your contact records that could be filled in more completely? Also consider if there are inactive contacts who should not be included in the migration. Now is also the time to re-evaluate your targeting, messaging, trigger-based campaigns, and lead management process.

Even if you’re merging into the same platform, from one instance of Eloqua to another as an example, there are some considerations to plan for:

  • Email sending sub-domains and microsite sub-domains will need to be unique between platforms.
  • Images will need to be hosted in the new platform and assets (emails, landing pages) referencing these images will need to be updated.
  • Forms will need to be built in the new instance and any that are hosted on external pages will need to be updated to point to the form(s) in the new instance.
  • Campaigns and programs will need to be rebuilt, so plan ahead to determine your priorities.
  • The new system (and new IPs) will need to be warmed for deliverability, so choose timing when you can pause message cadence or have a clean cutover from the old to the new messaging platforms.
  • Reporting and activity data cannot be transferred from the old instance to the new instance.

No matter how close you can get to replicating existing architecture, be sure to take some time to think through legacy processes and determine if there are things to improve.  Relationship One is here to help with your next migration project.