DO NOT SWITCH OFF THE OLD SYSTEM YET
Name an owner and a rollback plan. Verify a small set of controlled test records and complete each critical workflow before routing live customers through the new setup. This is a proposed test procedure, not a claim that we have performed it.
Before you connect a live store
- Owner: who can approve the change, check failed sends, and restore the old setup?
- Timing: avoid an important launch or peak sales window. Reserve time for follow-up checks.
- Backup: export the data and configuration you need using the provider’s supported procedures. Restrict access to customer data.
- Budget: include overlap, remaining contract commitments, rebuilding, and QA in the cost model.
- Rollback trigger: decide what would cause you to pause the change. Define it before results arrive.
Build a small, controlled test set
Use test addresses you control and synthetic records where the integration permits them. Never invent purchases from real customers, manufacture consent, or send test campaigns to an unverified audience. Separate test mode from production before connecting anything that can trigger a message.
| Test record | What to verify | Evidence to retain |
|---|---|---|
| Opted-in contact | Correct status, properties, and eligible workflow behavior. | Before/after status and the expected test message. |
| Opted-out or suppressed contact | No marketing send; restrictions survive migration. | Status mapping and negative test result. |
| Purchase or cart test event | Correct event, values, timing, and one intended flow entry. | Event payload and execution log, with sensitive data redacted. |
| Existing flow participant | No unintended replay, duplicate offer, or abandoned sequence. | Documented cutover rule for in-flight participants. |
| Integration-dependent record | Required fields and events arrive from the connected app. | Observed mapping and a completed scenario. |
Check each layer, not just the template
- Consent and exclusions
Map subscription statuses before importing. Verify opt-outs, suppression, and deletion requirements. Ask the provider when status semantics differ.
- Sender and domain
Follow current provider instructions for domain authentication. Test the sender identity, reply address, unsubscribe route, and rendering in your target inboxes.
- Forms and checkout
Check the real storefront’s placements, consent wording, duplicate pop-ups, and the properties created by each signup route.
- Automation behavior
Test triggers, filters, delays, exits, coupon behavior, links, and messages that must not send. A similar-looking flow is not evidence of equivalent behavior.
- Campaign operations
Have the regular operator create, segment, preview, and approve a campaign. Record new manual steps and maintenance work.
- Measurement
Document attribution windows, event definitions, time zones, and reporting delays. Do not compare dashboards as if their numbers were automatically equivalent.
Make the cutover explicit
Write a short change log: the exact date, which forms changed, which flows were stopped or started, who checked them, and how in-flight customers are handled. Avoid simultaneously running equivalent live flows in both systems. Keep the rollback route available until the agreed acceptance period ends.
Only after verification should you remove old forms, disconnect integrations, or cancel the old subscription. Confirm what cancellation does to exports, historical reports, billing, and any legacy terms.
Keep a record that another person can follow
For each check, record: requirement → expected behavior → observed behavior → evidence → owner → pass/fail → next action. Store evidence securely in your own workspace. This website does not receive or store your customer records.
For provider-specific starting instructions, consult Omnisend’s Klaviyo migration guide and current in-product documentation. Our checklist supplements those instructions; it does not replace them or certify compliance.
Not ready to move?
That is a valid result. Return to the requirements and cost decision before changing a working system.
Review the switching decision →Method and evidence
Prepared September 5, 2026. This checklist is an editorial acceptance framework, informed by the vendor’s migration instructions. No hands-on migration, delivery benchmark, or live-store outcome has been completed by this publication.