Migrate from Brevo to Volanea: A Developer’s Guide

Migrate from Brevo to Volanea without treating it as a simple API-key swap. The sending call is usually the smallest part of the work; the real migration is preserving authenticated sending, event processing, recipient protections, and the operational confidence your team has built around email.

Brevo is a broad customer-engagement platform, with transactional email alongside contacts, campaigns, automation, SMS, WhatsApp, CRM, and more. Volanea is a developer-focused email infrastructure option for teams that want to operate transactional and campaign sending through SMTP or an API-oriented workflow. That difference matters: moving only application-generated email can be straightforward, while moving workflows that depend on Brevo’s marketing, contact, automation, or multi-channel features requires a deliberate replacement plan.

This guide focuses on a safe developer migration. It assumes you already send account emails, password resets, receipts, alerts, invitations, invoices, or similar messages through Brevo, and want to move those flows to Volanea without creating duplicate sends, breaking unsubscribe handling, or damaging domain reputation.

What a Brevo-to-Volanea migration actually includes

A production email integration is more than a request that returns a message ID. Your current Brevo implementation likely spans several layers, whether they all live in code or are split between application services and the Brevo dashboard.

At minimum, inventory these layers before changing anything:

• Sending integration: API calls, SMTP credentials, SDK packages, environment variables, retry logic, queues, and rate controls.
• Identity and DNS: From addresses, reply-to addresses, sending subdomains, SPF, DKIM, DMARC, return-path behavior, and any dedicated-IP setup.
• Content: inline HTML, plain-text fallbacks, attachments, templates, template variables, localization, and tracking links.
• Recipient safety: bounced addresses, complaints, unsubscribes, internal blocklists, consent records, and address-validation rules.
• Delivery lifecycle: webhook endpoints, signature verification, event normalization, message status storage, alerts, dashboards, and support tooling.
• Brevo platform dependencies: contact attributes, lists, campaign templates, automations, SMS or WhatsApp steps, CRM data, ecommerce data, and inbound parsing.

The first four are relevant to nearly every transactional-email migration. The last category is where scope can expand quickly. Brevo’s API supports a much wider platform than email sending alone, so do not assume every resource or workflow has a direct Volanea equivalent.

A useful planning question is: what does the application need from the email provider at the moment it sends? If the answer is “accept a message, deliver it, and report lifecycle events,” you can keep the cutover tight. If the answer includes “look up a Brevo contact, apply contact attributes, enroll the person in an automation, update a CRM record, and coordinate a WhatsApp follow-up,” break those concerns apart before migrating.

Start with an email-flow inventory

Do not begin by replacing a package import. First, list every email-producing path in the repository and every email-related workflow outside it.

Separate transactional, campaign, and lifecycle use cases

Transactional email tends to originate from a specific application event: a user requests a password reset, an order is completed, or an administrator invites a teammate. The application usually owns the recipient, payload, content version, and timing.

Campaign email is different. It may rely on an audience, segments, opt-in status, visual templates, scheduling, frequency controls, and campaign reporting. Lifecycle email can sit between the two: it may be triggered by product behavior but depend on a contact database and automation rules.

Create a migration table with one row per flow. Include the trigger, sender address, recipient source, template owner, current Brevo template ID if applicable, attachments, expected volume, sensitivity, opt-out behavior, and dependent webhook events. For example:

This exercise prevents an all-or-nothing migration. You may move password resets and receipts first while retaining Brevo temporarily for campaigns or multi-channel automations that have not been redesigned.

Identify hidden senders and old credentials

Search for more than brevo and sendinblue. Look for the Brevo SMTP host, the api-key header, sendTransacEmail, templateId, sender addresses, old Sendinblue environment-variable names, and your company’s email domains.

Also inspect cron jobs, worker services, serverless functions, CI preview environments, support tools, billing systems, low-code automations, and plugins in ecommerce or CMS products. A migration that covers only the main Node application can leave a legacy sender active, causing confusing delivery logs and duplicate messages after cutover.

Choose the right integration boundary

The most maintainable migration is usually an internal mail abstraction. Instead of making application code depend directly on a provider SDK in dozens of files, concentrate provider-specific logic in one module.

A small boundary might expose functions such as sendPasswordReset, sendReceipt, and sendInvite. A more general boundary might expose sendEmail({ from, to, subject, html, text, tags, replyTo }). The right level depends on your application, but the key is that business code should not need to know whether a provider uses sender, from, htmlContent, or another field name.

This is also where you preserve behavior that is not an API feature:

1. Generate a deterministic idempotency key for event-driven sends.
2. Render and validate both HTML and plain-text bodies.
3. Add an internal correlation ID to your message metadata or headers where supported.
4. Check your own suppression and consent rules before submission.
5. Persist the provider submission result and enqueue retries only for retryable failures.

The provider should be one component of your message-delivery pipeline, not the only place your application remembers what happened.

For implementation details and current sending setup, use the email API reference and setup guides as the source of truth rather than copying credentials or DNS values from an older migration document.

Side-by-side code comparison: Brevo SDK before, Volanea SMTP after

Brevo’s current Node SDK exposes transactional sending through client.transactionalEmails.sendTransacEmail(). Its request shape uses fields such as sender, to, subject, and htmlContent.

Volanea supports SMTP sending, which can be a pragmatic migration target when you want to remove a provider SDK dependency while retaining a standard transport interface. The example below intentionally reads the Volanea SMTP hostname, port, and credentials from environment variables. Use the exact connection values issued for your Volanea account; do not guess them or reuse Brevo SMTP credentials.

Before: Brevo Node SDK

import { BrevoClient } from '@getbrevo/brevo';

const brevo = new BrevoClient({
  apiKey: process.env.BREVO_API_KEY!,
});

export async function sendPasswordResetEmail(input: {
  email: string;
  name?: string;
  resetUrl: string;
}) {
  const result = await brevo.transactionalEmails.sendTransacEmail({
    sender: {
      name: 'Acme Support',
      email: 'support@example.com',
    },
    to: [
      {
        email: input.email,
        name: input.name,
      },
    ],
    subject: 'Reset your password',
    htmlContent: `
      <p>Hello${input.name ? ` ${input.name}` : ''},</p>
      <p><a href="${input.resetUrl}">Reset your password</a></p>
      <p>This link expires in 30 minutes.</p>
    `,
    textContent: `Reset your password: ${input.resetUrl}`,
  });

  return result;
}

After: Volanea SMTP transport

import nodemailer from 'nodemailer';

const volaneaTransport = nodemailer.createTransport({
  host: process.env.VOLANEA_SMTP_HOST!,
  port: Number(process.env.VOLANEA_SMTP_PORT!),
  secure: process.env.VOLANEA_SMTP_SECURE === 'true',
  auth: {
    user: process.env.VOLANEA_SMTP_USERNAME!,
    pass: process.env.VOLANEA_SMTP_PASSWORD!,
  },
});

export async function sendPasswordResetEmail(input: {
  email: string;
  name?: string;
  resetUrl: string;
}) {
  const info = await volaneaTransport.sendMail({
    from: 'Acme Support <support@example.com>',
    to: input.name ? `${input.name} <${input.email}>` : input.email,
    subject: 'Reset your password',
    html: `
      <p>Hello${input.name ? ` ${input.name}` : ''},</p>
      <p><a href="${input.resetUrl}">Reset your password</a></p>
      <p>This link expires in 30 minutes.</p>
    `,
    text: `Reset your password: ${input.resetUrl}`,
    headers: {
      'X-Email-Category': 'password-reset',
    },
  });

  return {
    messageId: info.messageId,
    accepted: info.accepted,
    rejected: info.rejected,
  };
}

The application-level intent is the same: submit a password-reset message and retain a provider submission identifier. The object shapes are not the same. Brevo takes a structured sender object and recipient array; Nodemailer’s SMTP interface accepts RFC-style address strings or arrays and returns SMTP submission details.

Do not interpret accepted as delivered. In SMTP, it indicates acceptance by the relay for onward processing, not a recipient mailbox placement guarantee. Likewise, a Brevo API success response confirms acceptance by Brevo, not inbox placement. Delivery, bounce, complaint, and engagement outcomes belong in your webhook and operational monitoring pipeline.

Keep the provider switch behind one adapter

A direct mechanical replacement in every service creates future migration work. A simple adapter keeps the contract stable:

export type OutboundEmail = {
  from: string;
  to: string[];
  subject: string;
  html: string;
  text: string;
  replyTo?: string;
  category: 'password-reset' | 'receipt' | 'invite' | 'alert';
};

export interface EmailProvider {
  send(message: OutboundEmail): Promise<{ messageId: string }>;
}

Your Brevo implementation and Volanea implementation can both satisfy this interface during the migration. That enables controlled routing: route internal test mail to Volanea first, then a small percentage of a low-risk production flow, then one full category at a time.

Rebuild content deliberately instead of copying templates blindly

Brevo lets transactional sends use inline content, text content, or a pre-built template referenced by templateId. Those options are convenient, but they can hide a large amount of template behavior in the provider account.

Start by classifying each message:

• Inline templates in application code: usually easiest to move. Preserve HTML, text, assets, localization, and escaping rules.
• Brevo template IDs: export or retrieve the source content and move it into your application’s template system or rebuild it using the chosen Volanea workflow.
• Brevo contact-attribute templates: require special attention because values may come from Brevo contact records rather than the send call.
• Drag-and-drop assets: may reference images, fonts, links, or hosted files tied to existing tooling. Verify that each asset remains available after the migration.

Template syntax is a genuine migration cost

Template systems are not interchangeable. A Brevo template may use its own conventions for personalization, conditional content, contact attributes, event data, and localization. A Volanea implementation may instead render HTML in your application, use a different template mechanism, or accept a fully rendered MIME message over SMTP.

That is not necessarily worse; application-owned templates can improve version control, testing, and review. But it means you must move logic, not merely copy markup. Pay particular attention to:

• HTML escaping for user-controlled values.
• Date, currency, locale, and timezone formatting.
• Missing or blank contact fields.
• Conditional blocks and loops.
• Unsubscribe URLs and preference-center links.
• Link tracking parameters and redirect domains.
• Responsive layout and dark-mode behavior.

Build preview fixtures for realistic edge cases: long names, non-Latin scripts, empty optional fields, large order line items, and very long URLs. Send those previews to Gmail, Outlook, Apple Mail, and a mobile client before routing customer traffic.

Re-authenticate the domain; do not copy Brevo DNS values

Your sending domain is the identity recipients and mailbox providers evaluate. A Volanea migration requires Volanea-specific DNS records, even if the same visible From domain remains unchanged.

Do not delete existing Brevo DNS records on day one. Add the Volanea records, verify them, test, and keep the old configuration in place until all Brevo sending paths are fully retired. DNS records have different purposes, and coexistence is often possible when selectors and hostnames differ. However, always inspect the exact records before publishing changes because a duplicate or conflicting record can break authentication.

DNS and sender identity checklist

Re-verify each item rather than assuming a green domain status in one platform transfers to another:

• Add and verify the sending domain or sending subdomain in Volanea.
• Publish the exact Volanea-provided DKIM records. Do not replace them with Brevo’s DKIM records; DKIM selectors and values are provider-specific.
• Review the existing SPF TXT record at the relevant envelope-sender domain. SPF permits multiple mechanisms in one TXT record, but publishing multiple separate SPF records for one hostname can produce a permanent error.
• Add only the Volanea SPF mechanism or custom return-path configuration instructed for your account and sending model.
• Keep your DMARC record in place and confirm aligned authentication in real received-message headers after testing.
• Verify the visible From domain, DKIM d= domain, and envelope sender align appropriately for your DMARC policy.
• Confirm any custom tracking domain, if used, is configured for the new sending path.
• Confirm reply-to mailboxes are monitored and unchanged where required.
• Check that all intended From addresses are authorized for Volanea sending.
• Preserve Brevo records until Brevo traffic is demonstrably at zero and rollback is no longer needed.

Brevo documents its own sender and domain setup separately from transactional API use, and its domain-authentication records are specific to Brevo. Treat the new Volanea DNS values as an additional authenticated sending configuration, not as a rename of old records.

Use a dedicated transactional subdomain when appropriate

If your organization sends a mix of receipts, password resets, product notifications, newsletters, and sales outreach, separate domains or subdomains can make reputation and operational ownership clearer. For example, notify.example.com may be reserved for application mail while news.example.com handles campaigns.

This is an architectural decision, not a requirement for migration. Changing domains or subdomains during the same cutover increases variables: mail streams may build reputation differently, old allowlists can fail, and support teams need updated troubleshooting guidance. If the goal is low risk, keep the existing visible sender domain first and make domain-structure changes later under a separate plan.

Move webhook processing before production traffic

Brevo offers transactional webhooks and event types for the message lifecycle. Your Volanea event delivery may use a different event schema, retry policy, verification method, and endpoint configuration. The safe approach is to normalize both providers into your own internal event model.

For example, your database may store accepted, delivered, soft_bounced, hard_bounced, complained, opened, clicked, and unsubscribed. A provider adapter maps provider-specific names and payload fields into those states.

Webhook migration checklist

• Create the Volanea webhook endpoint using the exact destination and event configuration required by the account.
• Store the signing secret or verification material in a secret manager, not source control.
• Verify the raw request before parsing or transforming the payload when the provider’s verification scheme requires raw bytes.
• Make processing idempotent using an event ID, message ID plus event type, or another stable provider identifier.
• Return a fast success response after durable enqueueing; process slow work asynchronously.
• Handle retries safely. Webhook delivery is generally at-least-once, so duplicates are normal rather than exceptional.
• Map Volanea event names into your internal statuses and preserve the original event payload for debugging.
• Decide which events need alerts: authentication failures, complaint spikes, hard-bounce spikes, webhook signature failures, and unusual deferral rates are common candidates.
• Keep the Brevo webhook receiver active during the overlap period.
• Test an end-to-end event sequence using controlled inboxes before moving customer messages.

Do not make product logic depend exclusively on opens or clicks. Privacy protections and mailbox behavior can suppress, proxy, or distort those signals. Delivery and hard-bounce events are generally more useful operationally; engagement events can be directional metrics rather than ground truth.

Export and reconcile suppressions before cutover

Suppression handling is the part of an email migration that most deserves conservatism. Sending a new password reset to an address that previously hard bounced may be inconvenient. Re-mailing someone who made a complaint or opted out of marketing email can be a compliance and reputation problem.

Brevo may hold several recipient states: unsubscribes, hard bounces, soft bounces, blocked contacts, blacklisted contacts, and list or consent metadata. The exact source of truth may also be split between Brevo and your own database.

Build a canonical suppression model

Before export, decide which categories your application will enforce:

Export the Brevo lists available to your account, normalize email addresses conservatively, retain the original status and timestamp, deduplicate records, and import them into the Volanea-compatible workflow or your application-level suppression service. Keep an immutable export copy in controlled storage for audit and rollback purposes.

Large historical suppression lists can be harder to migrate than sending code. Files may contain stale records, inconsistent reason codes, conflicting states, missing timestamps, or data that should no longer be retained. Large imports can also require batching, validation, and reconciliation. Plan this as a data migration with checksums and counts, not as a dashboard upload performed at the last minute.

A useful validation report compares: total exported records, unique normalized addresses, records by reason, rows rejected during import, and sampled records verified in the destination. If you cannot prove where complaint and hard-bounce records went, do not declare the cutover complete.

For new signups or imported lists, use the free address verification tool before adding high-risk addresses to an active sending stream. Verification is not a substitute for consent or suppression handling, but it can reduce avoidable invalid-address sends.

Know which Brevo features do not map one-to-one

A fair migration guide should not imply that every Brevo feature is an email-API feature. Brevo can be the right choice when a team needs an integrated system for campaigns, audiences, automation, SMS, WhatsApp, CRM, conversations, or ecommerce data. Moving to Volanea may mean adopting separate tools or owning more logic in your application.

Assess these Brevo-specific or Brevo-adjacent capabilities explicitly:

• Contact database and attributes: if templates or automations read Brevo contact fields, decide whether your application database becomes the source of truth.
• Lists, segments, and campaign scheduling: transactional sending does not replace audience management and campaign operations.
• Visual campaign and drag-and-drop template workflows: teams may need a new content workflow, version-control process, or template editor.
• Marketing automations: recreate the trigger logic in your product, a customer-data platform, or another automation tool where necessary.
• SMS, WhatsApp, push, conversations, CRM, loyalty, and ecommerce modules: treat these as separate migrations, not email configuration tasks.
• Brevo transactional template IDs and dynamic attributes: rebuild template rendering and data binding where their syntax or source data differs.
• Dedicated IPs, IP pools, and sender-reputation controls: review the new provider’s available options and determine whether your existing sending architecture should change.
• Inbound email parsing: if your application receives replies or processes inbound messages, verify that the destination workflow is supported and tested independently.

The tradeoff is often clarity. A narrower email infrastructure layer can give developers more direct control over application messages, templates, and event data. A broader engagement platform can reduce the number of systems a marketing or operations team must manage. Neither approach is universally better; choose based on the workflows you actually operate.

Run a staged cutover, not a big-bang switch

The safest migration has an overlap period. Keep Brevo available as a rollback route while Volanea handles controlled traffic. Do not dual-send identical customer messages as a test strategy; recipients should not receive two password resets or receipts.

Instead, route messages deterministically. Examples include internal employee domains, test accounts, a feature-flag cohort, a low-risk notification category, or a small percentage of a non-critical flow. Record which provider handled each message so support staff can investigate a customer report without guessing.

Recommended rollout sequence

1. Prepare: complete DNS verification, credentials, templates, webhook handling, suppression import, dashboards, and runbooks.
2. Test with owned inboxes: send representative messages to controlled Gmail, Outlook, and other test inboxes. Inspect headers for authentication results and confirm webhooks arrive.
3. Enable internal traffic: route employee and QA accounts to Volanea while production customer traffic remains on Brevo.
4. Move one message category: start with a low-volume, low-risk transactional type, not a password reset during a major release.
5. Compare outcomes: review acceptance, bounce, complaint, delivery, latency, support tickets, and template rendering.
6. Expand by category: move receipts, invites, alerts, and other flows only after the previous category is stable.
7. Retire Brevo sending paths: remove keys and SMTP credentials only after scheduled jobs, integrations, and webhook overlap are fully resolved.

During overlap, keep a rollback flag. A rollback should route future messages to Brevo; it should not replay every queued message automatically. Automatic replay can create duplicate email when the first provider accepted the message but the application lost the response or timed out.

Test deliverability and operational behavior

A successful API response is not a complete test. Your pre-production test plan should exercise the entire lifecycle from sender authentication through event ingestion.

Minimum acceptance tests

• Send HTML and plain-text versions to multiple mailbox providers.
• Validate visible From, Reply-To, subject encoding, unsubscribe behavior, and branding.
• Inspect headers for SPF, DKIM, and DMARC outcomes.
• Send to a known invalid test address only where your testing policy permits and verify the bounce workflow.
• Verify webhook authenticity, idempotency, retries, and error handling.
• Send messages with attachments, long Unicode names, non-ASCII content, and multiple recipients if your application supports them.
• Confirm queue retry behavior does not create duplicate sends.
• Check that hard-bounced, complained, and opted-out test recipients are blocked as intended.
• Confirm support staff can locate a message by recipient, internal correlation ID, and provider message ID.

Measure baseline metrics from Brevo before moving traffic. You do not need to expect identical open rates, because tracking behavior and mailbox privacy controls vary, but you should investigate material changes in hard bounces, complaints, authentication failures, deferrals, or support reports.

What is harder than it looks

The hardest portions of a Brevo migration are typically not the send call.

First, historical suppression data may be large and imperfect. It needs careful classification, import validation, and durable retention of reasons. Second, template syntax and contact attributes may embed business logic in a provider-managed editor. Recreating conditions, loops, data formatting, and default values can take longer than expected.

Third, campaigns and automations are products in their own right. If your team relies on Brevo for segmentation, scheduled campaigns, workflows, or multi-channel messaging, moving transactional mail alone will not eliminate those dependencies. Fourth, deliverability continuity depends on authenticated domains, consistent sender behavior, low complaint rates, and thoughtful traffic ramping—not merely a new account.

Finally, operational ownership changes. When templates and recipient decisions move closer to application code, engineering may gain control and testability, but engineering also needs clear ownership for content releases, consent rules, incident response, and delivery monitoring.

Conclusion: make the migration reversible and evidence-driven

To migrate from Brevo to Volanea safely, treat sending code as one workstream within a broader email-system migration. Inventory every flow, isolate provider logic, authenticate the domain with Volanea-specific records, move webhook processing and suppression safeguards before customer traffic, and cut over gradually.

Be equally clear about scope. Transactional email workloads can be a focused move when your application owns data and content. Brevo’s broader contact, campaign, automation, and multi-channel capabilities may require separate tools or a separate project. The strongest migration is not the fastest key replacement; it is the one that keeps recipients protected, gives your team observability, and leaves a tested rollback path until the new flow has earned trust.

FAQ

How long does it take to migrate from Brevo to Volanea?

A simple transactional integration using inline templates can move in days once DNS access and credentials are available. A migration involving historical suppressions, provider-managed templates, campaigns, contact attributes, automations, or multiple applications may take weeks because data and workflow validation—not the send call—becomes the critical path.

Can I keep my existing From address after moving from Brevo?

Usually, yes, provided you authenticate the domain for Volanea and authorize the sender correctly. Do not assume existing Brevo verification transfers: publish and verify the Volanea-specific DNS records, then test real received messages for SPF, DKIM, and DMARC results.

Should I delete Brevo DNS records immediately?

No. Keep Brevo records during the staged rollout and rollback window unless a verified conflict requires a change. Remove unused records only after confirming that no Brevo API, SMTP, campaign, automation, or third-party integration continues to send mail.

Can I import Brevo unsubscribes and bounced addresses?

You should migrate the recipient-protection data needed for your policies, especially hard bounces, complaints, internal blocklists, and marketing opt-outs. Normalize, deduplicate, classify, import, and reconcile the data rather than treating it as an unverified spreadsheet export.

Does Volanea replace every Brevo feature?

Not necessarily. Volanea can serve developer email-infrastructure use cases, while Brevo also offers broader contact, campaign, automation, CRM, and multi-channel capabilities. Identify which Brevo features your organization uses and plan replacements or retain Brevo for those workflows until a separate migration is complete.