Migrating contactsisn't the same asmigrating email flows

In short

In a planned migration to Shopify, there was a very large base of email contacts and several running automations, for example for abandoned carts and back-in-stock alerts. The expectation was: all of that comes along. The contacts, yes. The automations, not so easily. They hang on events in the store system, and those events have different names in Shopify or work differently. So we planned contacts and automations separately and priced the flows as a separate service.

The case

A contact list is a table: name, address, consent status. It can be exported and imported. An automation, on the other hand, is a rule: “When this happens, send that.” The “when” comes from the store system. If the system changes, every rule has to be connected to the new events, and some events don't exist in the same form at all.

Two tasks, two plans

Which flows are hit hardest

• Cart and checkout abandonment: tied directly to store events.
• Back in stock: needs a connection to inventory.
• Post-purchase: depends on order and shipping status.
• Welcome flow: usually the easiest, because it only depends on the signup.

What to take away

• Contacts are data, automations are logic. Plan them separately.
• Bring the consent status along. Who opted in and who didn't has to be just as accurate in the new system.
• Expect to rebuild the flows. Copy can be carried over, triggers usually can't.
• Test every flow after the migration. A silent automation only gets noticed when the revenue is missing.
• Large lists affect the choice of tool. Tools that bill per contact get expensive fast with large lists.

Planning a migration with lots of contacts and running automations? We separate data and logic and make sure every flow runs again in the new store.