Implementation worksheet · 7 min read
An Engagement Platform Rollout Plan for the First 30 Days
Spend days 1 to 7 on data and consent rather than journeys: the events and identity rules your first journey needs, a reconciled import of every opt-out and consent record with its timestamp and source, and authenticated channels. Days 8 to 14 build one journey and run it in shadow, on live events without sending. Days 15 to 21 send it to a random slice of eligible users with a holdout, with the legacy version suppressed for the same people. Days 22 to 30 expand, hold or roll back against criteria written on day one, and set the date the legacy journey switches off. The month ends with one journey live and measured, not fourteen rebuilt at once.
Scope: the lifecycle lead and one engineer rolling out a multi-channel customer engagement platform (email, push, in-app, SMS) while a legacy tool is still sending. Starting state: a signed contract, events in a warehouse or CDP, consent records in the legacy tool. Boundary: the first 30 days and the first journey; deliverability engineering and the full migration are separate work. Intended outcome: one production journey with a holdout, a verified consent import, and a legacy switch-off plan.
Put it into practice
1. Days 1-7: an event contract for one journey
Pick the first journey (onboarding or a single triggered flow is a manageable first choice) and define only the events and properties it needs, plus the identity key that joins anonymous and known users. Send test events and check they arrive with the expected fields before anyone builds a message.
2. Days 1-7: import consent and opt-outs, then reconcile
Every opt-out and consent record from the legacy tool, per channel, with its timestamp and source rather than a bare subscribed flag. Under the GDPR, where processing is based on consent the controller must be able to demonstrate it (Article 7(1)), and a flag without its origin demonstrates little. Reconcile the counts channel by channel: the FTC's CAN-SPAM guidance requires email opt-outs to be honored within 10 business days, and a record lost in the move is an opt-out not honored.
3. Days 1-7: authenticate each channel
Sending domain authentication, push credentials, and SMS sender registration where your provider requires it. For email, Google's sender guidelines (as of September 2026) require SPF, DKIM and DMARC from senders of more than 5,000 messages a day to Gmail accounts, and recommend that high-volume senders start with low volume to engaged users and increase it slowly.
4. Days 8-14: run the first journey in shadow
Build it in the new platform and let it evaluate live events without sending. Compare its daily entries with the number of people the legacy journey entered on the same days. A gap beyond the tolerance you set on day one is a data or identity problem, and it's cheapest to find now.
5. Days 15-21: live on a slice, with a holdout
Send to a random share of eligible users (a fifth is a reasonable starting point, not a rule), keep a random holdout, and suppress the legacy version for exactly those users, by user ID. Check every working day: entries, sends, failures, complaints, unsubscribes, and any user who received both versions.
6. Days 22-30: decide against day-one criteria
Expand to all eligible users, hold at the slice, or roll back, using the criteria written before launch: entries within tolerance, zero opt-out leaks, zero double sends, complaints no higher than the legacy journey's. Then schedule the legacy switch-off so its unsubscribe links keep working: the same FTC guidance says an opt-out mechanism must be able to process requests for at least 30 days after you send a message.
7. Worked example (illustrative, synthetic numbers)
A subscription app exports 42,000 opt-out records across email and SMS from its legacy tool; the first import shows 41,873. The missing 127 were SMS STOP replies stored in a separate field, found on day 5 and imported with their timestamps. In shadow, the new onboarding journey entered 3,180 users in a week against the legacy tool's 3,420, a 7% gap traced to how anonymous and known profiles merged, and fixed on day 12. The slice ran from day 15; on day 28 every criterion was met, and the legacy onboarding journey was scheduled to switch off on day 35.
30-day rollout plan
Copy this structure into your review document and record your observed result for each row.
| Days | Workstream | Deliverable | Exit criterion | Owner |
|---|---|---|---|---|
| 1-7 | Event contract | Events, properties and identity key for the first journey | Test events arrive with the expected fields | Engineer |
| 1-7 | Consent and opt-outs | Imported records with timestamp and source, per channel | New counts equal legacy counts, channel by channel | Lifecycle ops |
| 1-7 | Channel setup | Authenticated sending domain, push credentials, SMS sender | A test message delivered on every channel | Lifecycle ops |
| 8-14 | Shadow journey | First journey evaluating live events without sending | Daily entries within tolerance of legacy | Lifecycle marketer |
| 15-21 | Live slice | Random slice with holdout; legacy suppressed by user ID | No double sends and no opt-out leaks | Lifecycle marketer |
| 15-21 | Daily monitoring | Entries, sends, failures, complaints, unsubscribes | Reviewed every working day | On-duty marketer |
| 22-30 | Expansion decision | Go, hold or roll back against day-one criteria | Decision logged with its reasons | Lifecycle lead |
| 22-30 | Legacy switch-off plan | Date, steps, and the unsubscribe handling that keeps running afterwards | Plan signed off | Lifecycle lead |
A failure worth checking
Rebuilding everything in month one. A team rebuilds fourteen journeys in parallel and switches the legacy tool off on day 30. Three journeys never ran in shadow. One depends on an event the product had renamed and enters nobody for two weeks, and the dashboard shows no errors, because a journey with no entries has nothing to fail. Verification: before any legacy journey switches off, its replacement must show daily entries within tolerance of the legacy journey's for the same days, and a journey with zero entries should raise an alert rather than sit silent.
Common questions
Why not migrate every journey at once?
Because every journey depends on the same events, identity rules and consent data. The first journey surfaces problems in all three, and fixing them once, before thirteen more journeys rely on them, is cheaper than fixing them fourteen times.
How long should the legacy and new journeys overlap?
Until the new one passes its criteria at full volume. While both run, suppress by user ID so nobody is eligible for both; suppression by segment name breaks the first time someone renames a segment.
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.