Migrate From Customer.io to Brew

​

Concepts

​

1. Export Profiles From Customer.io

​

2. Map Your CSV

• Customer.io reserves five names that won’t map 1:1 to Brew’s own reserved names: id, email, phone, created_at, unsubscribed. Rename collisions before mapping
• Brew’s reserved names are created_at, updated_at, email, first_name, last_name, source, subscribed

{{ customer.first_name | default: "there" }}   →   {{ firstName | there }}

• {% if %}...{% else %}...{% endif %} conditional blocks
• Journey attributes ({{ journey.attribute }}), temporary values scoped to a single workflow run, which have no Brew equivalent
• Object and relationship loops ({% for class in objects.online_classes %}), tied to Customer.io’s Objects data model, which Brew doesn’t have
• Snippets ({{ snippets.footer }}), reusable blocks, which you rebuild as standing instructions on your brand instead

​

3. Import Into Brew

​

4. Rebuild Segmentation

1. Write the derived signal onto the contact as a custom property, using an automation or the API on whatever cadence fits.
2. Build your Brew Audience on that property, not on the raw event.

​

5. Rebuild Templates

​

6. Rebuild Automations

​

7. Swap the API Calls in Your Code

await cio.identify(userId, {
  email: user.email,
  first_name: user.firstName,
});
await cio.track(userId, {
  name: "trial_started",
  data: { plan: "pro" },
});

await fetch('https://brew.new/api/v1/contacts', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.BREW_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ email: user.email, firstName: user.firstName }),
});

await fetch(
  `https://brew.new/api/v1/automations/triggers/${process.env.BREW_TRIAL_STARTED_TRIGGER_ID}/fire`,
  {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.BREW_API_KEY}`,
      'Content-Type': 'application/json',
      'Idempotency-Key': `trial-started-${subscription.id}`,
    },
    body: JSON.stringify({
      payload: { email: user.email, plan: "pro" },
    }),
  },
);

// Transactional
await cioApp.sendEmail({
  transactional_message_id: "welcome",
  identifiers: { email: user.email },
  message_data: { first_name: user.firstName, login_url: loginUrl },
});

// API-triggered broadcast
await cioApp.triggerBroadcast(broadcastId, {
  data: { first_name: user.firstName },
  recipients: { segment: { id: segmentId } },
});

await fetch(
  `https://brew.new/api/v1/automations/triggers/${process.env.BREW_WELCOME_TRIGGER_ID}/fire`,
  {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.BREW_API_KEY}`,
      'Content-Type': 'application/json',
      'Idempotency-Key': `welcome-${user.id}`,
    },
    body: JSON.stringify({
      payload: { email: user.email, firstName: user.firstName, loginUrl },
    }),
  },
);

​

8. Cut Over

1. Warm up your Brew sending domain before any real volume. Send to your most engaged contacts first and ramp over several days. Gradual send does the ramping for you.
2. Rebuild contacts, segments, templates, and automations while Customer.io keeps sending normally.
3. Move one message type at a time. A reasonable order is broadcasts first, then automations, then transactional.
4. Give single-recipient, account-critical messages extra care, whichever category they’re in. A password reset or a receipt qualifies.
5. Watch each moved type in analytics before you move the next.
6. Confirm recreated segments’ membership counts before their automations go live. See Step 4.
7. Point signup forms, event tracking, and inbound integrations at Brew once everything upstream is verified.
8. Keep Customer.io active but unused for a couple of weeks as a fallback, then downgrade or cancel.

​

Quick Reference

​

Need Help?