Implementation worksheet · 7 min read
A Customer Engagement Migration Risk Register
Register the risks that harm customers or create legal exposure first, then the ones that only cost time. For an engagement platform migration those are: opt-outs and consent not carried over, the same person messaged by both platforms during the overlap, people partway through a journey dropped or restarted, identity merges that differ between platforms, personalization fields that render empty, event names that silently stop matching, sender reputation on new sending infrastructure, and push registrations that don't transfer. Each row gets an owner, an early signal you can watch, a mitigation completed before cutover, and a rollback trigger agreed in advance. Review the register daily during cutover week.
Scope: the lifecycle lead and engineer moving live journeys across email, push, in-app and SMS from one engagement platform to another. Starting state: a signed contract with the new platform and a legacy platform still sending. Boundary: the migration window, from first import to legacy switch-off plus the opt-out tail; building new journeys is separate work. Intended outcome: every row closed or accepted by a named owner before cutover, and nobody messaged against their wishes along the way.
Put it into practice
1. Seed the register with customer-harm risks
Consent and opt-outs, double messaging, disrupted journeys, broken personalization. These go first because they reach customers and can't be recalled. Risks that only cost time, such as a break in reporting, go below them.
2. Score each row on a simple scale, and call it simple
Likelihood and impact from 1 to 3 is a convention for ordering the work, not a measurement. Add the early signal (what you would see first), the mitigation (done before cutover), the rollback trigger (what makes you stop) and the owner.
3. Close the consent rows with counts and timing
Reconcile opt-outs and consent records per channel between the platforms. Keep the legacy platform's unsubscribe handling working after it stops sending: the FTC's CAN-SPAM guidance says an opt-out mechanism must be able to process requests for at least 30 days after you send a message, and opt-outs must be honored within 10 business days. Sync any opt-out the legacy platform receives into the new one for that whole tail.
4. Decide mid-journey handling per journey
For each live journey: let people finish in the legacy platform, map them to the equivalent step in the new one, or exit them. Restarting everyone at step one is what happens when nobody decides.
5. Suppress by user ID across both platforms
During the overlap nobody should be eligible in both. Suppression by segment name breaks when a segment is renamed; suppression by user ID doesn't.
6. Treat new sending infrastructure as new
A new sending domain or IP has no reputation yet. Authenticate it, and follow Google's recommendation for high-volume senders (as of September 2026): start with low volume to engaged users and increase slowly, watching the spam rate, which Gmail requires to stay below 0.3%.
7. Worked example (illustrative, synthetic numbers)
At cutover, 8,400 users are partway through the legacy onboarding journey. The register's decision: they finish in the legacy platform, which takes at most 14 days, and only signups after the cutover date enter the new journey. The legacy platform's last marketing send is on 3 November, so its unsubscribe links stay live, syncing to the new platform, until at least 3 December. Daily checks in cutover week find 11 users who received both welcome emails, traced to a segment renamed on day 2. The rollback trigger fires as designed: the new welcome journey pauses, suppression moves to user ID, and it resumes the next day.
Migration risk register (illustrative)
Copy this structure into your review document and record your observed result for each row.
| Risk | Likelihood / impact (1-3) | Early signal | Mitigation before cutover | Rollback trigger |
|---|---|---|---|---|
| Opt-outs or consent not carried over | 2 / 3 | Imported counts differ from legacy, per channel | Reconcile per channel; keep legacy unsubscribe links working and syncing for 30+ days after its last send | Any message to an opted-out contact |
| Double messaging during the overlap | 3 / 2 | The same user ID in both platforms' send logs | Suppress by user ID in both platforms | Any duplicate send in the daily check |
| Mid-journey users dropped or restarted | 3 / 2 | Step counts reset at cutover | Per journey: finish in legacy, map to a step, or exit | Users receiving step one twice |
| Identity merges differ | 2 / 2 | Profile counts per email address differ between platforms | Compare merge rules; test known merged profiles | An unexplained profile-count gap above tolerance |
| Personalization renders empty | 2 / 2 | Test sends to sparse profiles show blank fields | A fallback value for every merge field | Any blank field in QA renders |
| Event names stop matching | 2 / 3 | Journey entries drop against legacy | Event mapping sheet and a shadow run | Entries below tolerance for a day |
| Sender reputation on new infrastructure | 2 / 3 | Rising deferrals or spam rate in Postmaster Tools | Authenticate; start with low volume to engaged users | Spam rate approaching Gmail's 0.3% limit |
| Push registrations don't transfer | 2 / 2 | Reachable push audience falls after cutover | Confirm the token import or re-registration path in a test app build | Push reach below plan |
| Reporting series breaks | 3 / 1 | Metric definitions differ between platforms | Report both during the overlap; document definitions | Not a rollback risk: annotate the reports |
A failure worth checking
Cancelling the legacy platform the day after cutover. Messages sent in its final weeks still carry legacy unsubscribe links, and those links now fail or record opt-outs nowhere. Recipients who click them keep receiving mail from the new platform. The FTC's CAN-SPAM guidance requires the opt-out mechanism to work for at least 30 days after a message is sent, so the legacy contract's end date has to follow the last send, not the cutover. Verification: list the last send date per legacy channel, keep unsubscribe processing and its sync to the new platform running for at least 30 days after it, and test a link from the final send on day 29.
Common questions
Should we migrate historical message logs?
Migrate what you need for consent evidence, suppression and reporting continuity, and decide the rest deliberately. The GDPR's data minimisation and storage limitation principles (Article 5(1)(c) and (e)) are a reason not to copy everything by default.
How long should the two platforms overlap?
As long as the longest journey you let finish in the legacy platform, plus the 30-day opt-out tail after its last send. The same person should never be eligible to receive the same message from both at once.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.