Planning to convert your campaign platform
Overview
When deploying a new campaign orchestration tool, several factors must be taken into account. One crucial consideration is the campaign migration strategy, which involves transferring campaigns from one platform to another. Unfortunately, there is usually no conversion tool that facilitates this process automatically. Therefore, it is necessary to establish a systematic process for migration, which is what this document will cover. The process outlined here is the generic approach and will need to be tailored to each company transitioning between platforms.
This document assumes that the decision has been made to migrate from one platform to another, and the stakeholders and resources are known and aligned.
MVP approach to campaign migration
Taking a minimum viable product (MVP) approach to campaign migration allows you to…
Define a set of representative campaigns that illustrate the functionality of the full set of campaigns required for migration.
From there, you follow the steps to document the campaigns in detail and determine the requirements to deploy the campaign in the new platform.
Using that set of campaigns, you will refine a deployment plan for the remainder of the campaigns.
As part of the MVP process, you should include documenting the approach to the campaign configuration for the MVP campaigns so that you can apply that to the remainder of the campaigns.
You will use what was learned from the MVP campaigns to refine the remainder of your deployment plan based on your findings with the MVP set.
Considerations for selecting an MVP campaign set
When selecting a set of campaigns to use as MVP, the goal is to represent each distinct requirement for all campaigns. Consider the following when you identify this set:
Are there any unique requirements?
Coupon or certificate assignment
Integrating with internal marketing channel deployments
Some companies have built custom email connectors or mobile apps that need to be integrated with the campaign process.
Compliance or regulatory requirements to consider
Transactional vs. marketing message requirements
For example, order confirmation needs to go out within x number of minutes.
Integrating with the product's native connectors
For example, if you have an existing SFMC account, how do you best integrate the orchestration tool with the 3rd party tool.
Links and tracking
What metadata needs to be captured and appended to URL for tracking?
Do you need URL shortening functionality?
Do you have campaigns of varying complexity?
As a part of the campaign inventory process you should assign t-shirt sizing (small, medium, large) to each of the campaigns based on overall size/complexity. Your MVP approach should consider at least one campaign of each size.
Are there different audiences?
Are you marketing to unique individuals, unique households, loyalty accounts, or patient accounts?
Are you using multiple channels?
Use at least one campaign for each channel.
High-level migration approach
Below are the high-level steps to establish and execute a migration plan. These steps are broken into further detail later in this document. This is an extensive list of the steps for migration for thoroughness, but the level of detail required for each of these steps will need to be determined by each business independently.
Discovery: campaign inventory and technical assessment
Planning: migration plan and planning considerations
Solution deployment and configuration: accessing the environment, creating/modifying the data model, loading data, and configuring new campaign environment
MVP campaign builds: building campaigns, quality assurance (QA), user acceptance testing (UAT), and documentation and cross-training
Launch solution: go-live and cut-over, and post-launch validation
Post-MVP launch: expand functionality, and review and optimization
Migration planning details
Below you will find additional detail on each of the high-level steps that are listed above.
The first step of the process is to determine what is being migrated by documenting a detailed picture of all the campaigns that you plan to migrate along with the associated components like business rules, data usage, and content, if applicable.
From this detailed picture, you will identify a set of MVP campaigns that you will use to go through the overall process end to end.
From there you can refine the migration plan for the remaining campaigns.
1. Discovery
Campaign inventory
Generate an inventory of the existing active campaigns and their associated requirements.
Determine the data required to support segmentation, campaign execution, and personalization.
Establish intended channels to be supported by the solution and each campaign.
Determine reporting requirements, campaign metadata, and associated data elements to support campaign analytics.
Campaign inventory sample
Here is a short example of what a campaign inventory table could look like:
Name | Description | Type | Frequency | Complexity | Channels | Personalization | Channel execution | Data source requirements |
|---|---|---|---|---|---|---|---|---|
Welcome Campaign | Add new signups to the welcome series of messages | Journey | Daily | Medium | Email & direct mail | Yes
|
| Customer data
|
Newsletter | Send monthly newsletter | Single Message | Monthly | Small | No |
| Customer data
Transaction data
|
Campaign components
Now that you have a list of campaigns, you can review them each to identify the objects required to build the campaign. Some of these components are generic regardless of the system you are migrating to, like channel or schedule, whereas a selection rule is more specific to Redpoint Interaction (RPI) vs. other tools.
Although this doc is generally applicable, we will start to call out more items from this point forward that may be specific to RPI.
The objects are related to:
Audience requirements
Selections rules
Suppressions
Segmentation
Metadata
Channel information
Channel type
Content
Personalization
Extract layout
Campaign details
Campaign types
Marketing
One-off
Journey or multi-touch
Transactional/trigger-based
Order confirmation
Appointment reminder
Schedule
Manual one-time execution
Apology message
Scheduled
One-time execution
Recurring
Triggered
Action-based campaign execution
Data components
Based on the list of campaign components already determined, what are the data elements that are required for things like the following:
Selection rules
Personalization
Attributes
Smart asset criteria (dynamic content)
Channel requirements
Recipient address (email, phone, address, etc.)
Extract details
Destination
File naming convention
File layouts
Reporting components
Different campaigns may have different reporting requirements.
What type of reporting requirements does each campaign have?
What metrics need to get captured as a part of the campaign execution to be able to perform post-execution analysis on the campaign?
In addition to the outbound campaign data, there will also be other data that is required for reporting, such as channel dispositions, transactions, and redemptions.
Various data components used for reporting:
Channel disposition data
Email
Open
Click
Bounce
Unsub
etc.
SMS
Delivered
Click
Unsub
etc.
Direct mail
Not mailed
Scrubbed
Bad address
Transaction data
Purchase data
Claim data
Electronic medical records (EMR) data
Redemption data
Coupon, certificates, or vouchers
Control groups
Other
Technical assessment
This document assumes that you have performed a technical assessment and determined that the new orchestration product meets or exceeds your general technical requirements. This section covers some additional technical considerations that could impact timelines, like data readiness, as well as other aspects that should be considered for the plan. This is starting point, but not an exhaustive list.
Data audit
After you have inventoried the campaigns, you will have an idea of the data required to support them.
Identify the sources of the required data to initiate a plan for where the data currently resides and where it needs to be for RPI to have access to it.
Consider any additional data sources that may be a part of new campaign strategies but are not in the existing set of campaigns.
Determine a plan to align data availability with the campaign deployment plan and align the prioritization of loading the data to support the campaign requirements.
Data readiness
You will need to make various decisions related to data storage and structure in order to satisfy your campaign requirements. This will depend on your Redpoint deployment model and on how and where your data is currently stored. You may need to migrate the data into a different database technology or into a different type of data model to achieve the requirements of your target campaigns.
In addition to loading the data to a data model that suits your needs, you will need to ensure the quality of the data so that the campaigns are executed effectively and efficiently. This includes things like standardizing fields and identifying any gaps or inconsistencies in the data and addressing them as needed.
Acquiring, loading, transforming, and validating the data in general and evaluating its fitness for purpose is likely to be an iterative process and typically requires more effort than initially anticipated. This can have an adverse impact on the plan duration; you should plan a contingency in the schedule to minimize the impact of extended data effort against the overall migration timeframe.
Digital asset audit
Digital assets, like HTML content, landing pages, and images, etc. need to be identified for migration. Some items like images may not need to be migrated unless they are hosted in the legacy campaign solution.
User groups
What are the different types of user groups that exist currently, if any?
How do those existing groups compare to the permissions and access for the new platform?
Define a set of user groups and permissions. Ensure that the user group and permission strategy accounts for functionality permissions, object permissions, and data access and usage permissions.
Users
Determine the set of users and their associated groups that need to be created for the new platform.
2. Planning
You now have an inventory of the campaigns and associated assets, and can use that to construct a more detailed deployment plan, along with the additional information below.
Complete migration plan
Now that you have the campaign and other technical details related to the campaigns you are ready to plan out the migration. There are a few key components to the planning:
Availability of data needed for the campaigns
Environment availability (deployment and configuration)
Level of effort (LOE) to build the campaigns
We recommend that you assess the complexity of your campaigns using “t-shirt sizing” (small, medium, or large), where you define your own size benchmarks to associate a standard number of days to complete the campaign build. For example, a simple campaign (small) could take one day to configure, a moderately complex campaign (medium) could take three days, and a complex campaign (large) could take five days. This will help define a rough timeline for the effort to migrate the campaigns.Any other requirements to support the campaigns, like content and channel configurations
Use the campaign LOE estimates, data availability estimates, reporting configuration, and testing requirements to define a full migration plan and timeline. Then start with the MVP campaigns and use the feedback from their deployment to update and refine the plan for the remainder of the campaigns.
Additional planning considerations
Consider what types of activities can be done in parallel to minimize the duration of the overall timeline for the migration. For example, you could load the data needed for the MVP campaigns before you load the data required for the remaining campaigns.
Another factor in the timeline is the number of resources that are available for the project. Increasing the resources may allow for the timeline to be shortened, but keep in mind that just adding additional resources may not impact the timeline linearly. For many reasons, you may see an incremental decline in the amount of reduction in the timeline as you add more and more resources (diminishing returns). For example, if you have a plan for 2 resources and 8 weeks and you add 2 more resources for a total of 4, that most likely will not reduce your timeline to 4 weeks, but it may to something like 6 weeks. This impact of additional resources will vary project-by-project.
3. Solution deployment and configuration
Ensure access to the environment
This document assumes that you will have access to the software, and that it is deployed in a way that meets your technical needs.
If you’re hosting the software yourself then you will need to provision the software based on what you have purchased and what supporting technologies are required.
If this is a SaaS solution, then the software will be available and you will not need to worry about as many details as you would for a customer-specific deployment.
Create/modify data model
The hosting model and what currently exists for a data model will drive the effort for this step.
If you are building a new data model to support the orchestration platform, this is going to take longer than modifying/enhancing an existing data model.
If you’re migrating to the Redpoint SaaS solution, the data model is predefined, and you will only need to load data and address any extended attributes that you have that are not in the standard model.
Loading data
The hosting model and what currently exists for a data model will drive the effort for this step as well. Also, some data may be quick to load, like store or product data, whereas other data may take longer based on the volume of data, such as transaction data.
Configure new campaign environment
Configure RPI and any additional supporting technologies.
Create user groups and users
Configure settings and components
Configure channels
Configure database performance
Etc.
4. MVP campaign builds
Now you can start on the end-to-end MVP campaign builds.
Validate counts and accuracy
Are the counts of the new campaigns within a reasonable tolerance of the existing campaigns?
Are the correct records getting identified?
Refine
Build campaigns
Build out the selection rules, audiences, interactions, and offers to support each of the campaigns. Perform some initial functional testing to ensure they are fulfilling the requirements of the campaign.
Quality assurance (QA)
Validate counts and accuracy of the new campaigns.
Are the counts of the new campaigns within a reasonable tolerance of the existing campaigns? The platform and the data are both being updated here, so there has to be a reasonable percent of deviation between the two campaigns that is still considered acceptable (plus or minus 5% is generally a good rule of thumb).
Are the correct records getting identified?
Counts don’t tell the whole picture; although the counts may be within the tolerance, the data that is targeted may not be the correct set, and that needs to be validated.
User acceptance testing (UAT)
After QA is performed, you can provide the results and any additional information to whomever is performing the UAT. This process will likely be iterative, as the approver may have feedback that requires adjustment and additional testing before the campaign is accepted.
Be sure to budget time to perform the iterative process of UAT. Assume that the more complex the campaign, the more time you should budget for this step. Also, the data can be a significant factor in this process, and may require that the data itself be reloaded or standardized (and not just the campaign that needs to be adjusted).
Documentation and cross-training
Once the MVP campaigns are approved, then you can fully document the configuration of those campaigns and define an approach to the configuration of the remaining campaigns based on the findings in the MVP process.
Using the MVP campaigns and associated documentation, you can train additional resources to support building out the remainder of the campaigns.
5. Launch solution
Now that the MVP campaigns are built and passed UAT, they are ready to go live in the new platform. This will require them to be cut over from the old platform (shutdown) to the new platform (turned on).
Go-live and cut-over
Campaign cut-overs can be simple as stopping them in one platform and starting them in another. In other cases, it is more complex and needs to be done in an incremental process where they are dialed down in the old platform and ramped up in the new platform. A good example of this is when you are using a new email provider or account in the new platform and you need to warm up the IPs for the new provider/account. To ensure everyone is getting the expected messages while the IPs are warmed, this may require that the campaign is run in both systems for a duration of time until the full volume is being executed out of the new platform.
Factors like email warming duration need to be considered, as it will have an impact on the over all deployment timeline.
If you need to run the same campaign in both platforms for a duration to support things like IP warming, you may need to consider maintaining the targeting and response data across the platforms during the parallel execution to ensure all data is captured and consistent across systems.
Post-launch validation
Now that the MVP campaigns are executing in production mode, they need to be monitored for a duration of time to ensure that they continue to execute accurately and efficiently; if they are not, address the issues accordingly.
6. Post-MVP launch
Once the MVP campaign process is complete, you can continue to migrate the remainder of the campaigns using the same process as the MVP campaigns and applying any learnings from them. In addition, you can adjust the timelines accordingly based on your experience with the MVP campaigns.
After completing the migration of the existing campaigns, you can begin to look at expanding the use of the new platform.
Expand functionality
In most cases, there is a reason you are moving from one campaign platform to another; one of these reasons is new functionality. After you have migrated your existing campaigns, you can start to look into additional new campaigns to take advantage of new functionality.
The platform is regularly enhanced, so track new releases to see what features you can leverage.
Review and optimization
After the platform is up and running, you should regularly review your campaigns for performance optimization and see if there are any new features you can take advantage of to streamline or enhance an existing campaign.
Conclusion
When deploying a new campaign orchestration tool, there are a lot of things to account for and consider, the process outlined in this topic should help to streamline the effort. As mentioned in the beginning, the process will vary based on the company and the amount of campaigns and complexity of the existing solution.