Migration · Brevo

Migrate from Brevo

Email, SMS and CRM data consolidate into one workspace billed in INR, with opt-out and bounce state preserved through the attribute mapping.

Book the migration See pricing

Timeline

48 hours typical

Suppression first. DNS last. Keep the old platform read-only for 72 hours.

Step 1

Export

Export contacts, lists, attributes, transactional templates and automation definitions.

Step 2

Map

Map Brevo attributes to LoopNow fields. Preserve opt-out and bounce state.

Step 3

Test

Run a seed test to Gmail, Outlook and Rediff before switching production traffic.

Step 4

Switch

Update DNS and API keys. Keep the old account active for 72 hours for rollback.

A stack of flat-packed cardboard on a concrete floor, tape roll beside it.

The short version

Brevo holds email, SMS, a CRM and live chat in one bill. Only contacts, attributes, consent, suppression and email content move cleanly; the rest is rebuild or leave behind.
The attribute map is the real project. Map only the fields that templates, segments and automations actually reference, then spot-check twenty records by hand.
Bounce and opt-out state must arrive as suppression records on the send path, not as a list you promise to exclude. Load them before contacts.
Transactional templates are rebuilt and every trigger retested. Marketing templates can wait; a password reset cannot.
If your procurement needs European residency, Brevo is the better answer and this migration is the wrong one. LoopNow runs on AWS Mumbai, ap-south-1.
Budget an overlap month. Card billing in euros becomes UPI or netbanking in rupees with an 18% GST invoice, and the old account stays active for 72 hours.

Three products in one account, and only two of them move

A Brevo account is usually three things wearing one login: an email platform, an SMS channel and a small CRM with live chat attached. That bundling is the reason teams pick it, and it is also the reason migrations from it get scoped badly. The email side is portable in the ordinary sense, because contacts, attributes and consent are rows you can export and reload. The CRM side is a decision rather than a task. The SMS side needs a regulatory registration that has nothing to do with either vendor.

Start by deciding what you are actually replacing. If the CRM is where the sales team works, keep it and connect it; migrating deals, notes and pipeline stages is a different project with a different owner and a much higher cost of error. If the CRM was only ever a place where contact properties accumulated, then it is not a CRM in use and its data belongs in the contact import. Write that decision down on day zero, because it determines whether you are moving one system or three.

Figure 1. One login, four different jobs. Only the left-hand pair behaves like data during a migration; the other two are decisions.

The live chat history is the part people forget to ask about. Transcripts are usually exportable as records but not importable as a working inbox, so a support team that relied on searching old conversations loses that search. Decide in advance whether the team needs read-only access to the old account for a quarter, and if so, keep the cheapest plan that preserves it. That line item is small and it prevents an argument in month two.

The attribute map is the whole migration

Attribute mapping sounds like clerical work and behaves like architecture. Every attribute in the old account is either used by a template, used by a segment, used by an automation condition, or dead. The dead ones are most of them, and importing all of them creates a schema nobody can explain six months later. Go through the list and mark the references. Anything with no reference gets archived in the export and left out of the new schema.

The mapping itself needs three columns, not two: old name, new name, and what depends on it. A first name is straightforward. A date of birth is not, because the format in the export may be day-first while the new field expects an ISO date, and a silent parse failure turns a birthday campaign into a message that says your birthday is invalid. A phone number is not, because the country code may be missing on half the records. A dropdown is not, because the option labels may not match the new picklist and unknown values fall to empty.

Figure 2. Three columns and a dependency note. The dependency column is what stops you deleting a field that a live template still references.

Do the mapping on paper, then import twenty records and look at them in the interface rather than in a spreadsheet. Spreadsheets hide type coercion; interfaces do not. If a field shows as blank or as a date in 1970, the mapping is wrong and you have found it cheaply. Only after those twenty records look correct should you import the rest, in batches small enough that a bad batch can be deleted without unpicking a week of work.

Suppression and bounce state, loaded before anything else

The most damaging import is the one that succeeds. Contacts arrive, the dashboard looks healthy, someone schedules a campaign, and eleven percent of the list is people who unsubscribed or hard-bounced two years ago. That single send can set a new domain’s reputation back months, and recovering it takes longer than the migration did. Suppression is therefore a separate, verified step, performed before contacts are loaded rather than after.

Treat the old account’s state as four distinct things, because they mean different things downstream. An unsubscribe is a withdrawn consent and must block all marketing. A hard bounce is an invalid address and must block everything including transactional mail. A complaint is a reputational signal and must block marketing permanently. A soft bounce is temporary and should not be imported as a block at all, or you will suppress working addresses. Collapsing these into one do-not-mail flag loses the distinction you need later.

Figure 3. Suppression sits between the import and every send. A blocklist consulted by the campaign builder is not the same thing and will eventually be bypassed.

Then run a match report. Import suppression first, import contacts second, and count how many contacts were suppressed at arrival. Compare that number against the old account’s blocked count. A small difference is explainable by normalisation; a large one means the match key is wrong. Keep the report, because it is the evidence that you did this correctly if a complaint ever arrives from someone who insists they unsubscribed.

Transactional templates are rebuilt, not copied

A transactional template is a contract with a trigger. The password reset expects a token, the order confirmation expects a line-item loop, the invoice expects a currency and a tax line. When you rebuild it in a new editor, the copy is the easy part and the variables are where it breaks. Every placeholder has to exist in the payload the trigger sends, with the same name and the same shape, or the message goes out with a blank where the amount should be.

Work through the triggers rather than the templates. List every event that causes a send, then reproduce the event and read the message. Password reset, email verification, order confirmation, shipping update, invoice, refund, failed payment, account deletion. Each one is a five-minute test and a support ticket if it fails in production. Do this before cutover, on the live configuration, and keep a dated screenshot of each message as evidence.

Figure 4. Triggers first, templates second. Testing the event rather than the template is what catches a variable that the payload never sends.

Two details cost more time than they should. The first is the plain-text part, which many builders generate automatically and many migrations drop, leaving a message that scores worse with spam filters and reads badly in a terminal. The second is the sender identity: the from name, the reply-to and the physical address in the footer are not cosmetic, and a mismatch between the old and new message is the kind of thing a customer notices and a compliance reviewer asks about.

Automation definitions and the logic they hide

What you can export from an automation is a definition: the steps, the waits, the conditions, the branch labels. What you cannot export is the behaviour, because behaviour lives in the interaction between the definition and the data. A wait of three days, a condition on a field that was renamed last year, a goal event that fires twice for the same contact, and an exit rule added after a complaint all combine into something the diagram does not show. Rebuilding from the diagram alone reproduces the picture, not the outcome.

Pick the automations that carry revenue or obligation, and rebuild those first. A welcome series and an abandoned cart are revenue. A renewal reminder and a payment failure sequence are obligation. Everything else goes into a backlog with a date, not into the cutover plan. Rebuilding five automations properly beats rebuilding fifteen approximately, because an approximate automation that fires twice is worse than one that does not exist.

Figure 5. Revenue and obligation come first. Anything else is a backlog item, and some of it should simply be switched off.

For each rebuilt automation, write one fixed test case with a known input and a known expected output, and run it before and after. If the old system sends three messages over five days and the new one sends four, you have found a duplicate trigger rather than a design choice. Keep those test cases; they are the regression suite you will want the next time somebody edits a wait step at eleven at night.

Two senders, one domain: authentication during the overlap

During the overlap you will have two platforms that both claim to send as you. DNS has to say both are allowed, or one of them starts failing authentication the moment you publish the new records. The SPF record is where this gets tight, because each included sender costs a DNS lookup and the protocol allows ten. Adding a fourth include to a record that already has three is a silent recipe for permerror, and a permerror looks exactly like a deliverability problem with no obvious cause.

The cleaner pattern is to stop sharing the root. Send marketing from a subdomain such as news or mail, authenticate that subdomain with its own DKIM selector and its own SPF record, and leave the root domain’s records for company mail alone. DMARC then aligns on the subdomain, which means a marketing mistake cannot damage the reputation of the address your invoices come from. The cost is one extra zone and twenty minutes of work, and the benefit is that a bad campaign is a bad campaign rather than a company-wide email outage.

Figure 6. The subdomain costs one DNS zone and protects the address your invoices come from. The root is simpler until the first bad campaign.

Whatever you choose, keep the old DKIM record published for at least a month after cutover. Mail already in flight, forwarded copies and providers with cached DNS all still validate against it, and deleting it on cutover night is how a clean migration produces a spike of unauthenticated mail the next morning. Note the exact record values before you change anything, with a timestamp, so a rollback is a copy and paste rather than an archaeology exercise.

Warming a domain that already has a reputation

A domain with three years of clean sending history is an asset, but the asset does not transfer intact. Reputation is built from the combination of domain, sending IP and the behaviour receivers observed over time, and the new platform sends from different infrastructure. Receivers will treat the first week cautiously regardless of what your domain did last month. Warming is the process of giving them evidence quickly without giving them a reason to throttle you.

Move traffic in the order of how much the recipient wants it. Transactional mail first, because people open password resets and order confirmations and that engagement is the strongest signal available. Then the engaged segment of the marketing list, meaning people who opened or clicked in the last ninety days. Then the broader list, then the cold tail. Skipping to the full list on day one is the most common self-inflicted wound in a migration, and it usually happens because a campaign was already scheduled.

Figure 7. The order is the plan. Each stage earns the right to the next one, and any stage can be held if the reports turn.

Watch two reports daily during the ramp and stop if either turns. Bounce rate tells you whether the list is as clean as the suppression report suggested. Complaint rate tells you whether the audience remembers opting in. Neither needs a dashboard; both need somebody to look every morning and the authority to pause. If you publish a ramp plan with dates and volumes, publish the pause condition next to it, so pausing is a decision the plan already anticipated rather than an argument.

Residency: European today, Mumbai after

Brevo’s residency story is European, which is exactly right for a company whose customers, contracts or regulator sit in the EU. LoopNow runs on AWS Mumbai, ap-south-1. Neither position is universally better, and the migration is a good moment to decide which one your business actually needs rather than inheriting the one you bought three years ago for a different customer base. If your procurement questionnaire says GDPR and your data subjects are in Germany, moving to Mumbai is a downgrade you will have to explain.

For Indian teams the calculation usually runs the other way. Under the DPDP framework, the obligations that matter are purpose limitation, notice, consent records, erasure and reasonable security safeguards, and buyers increasingly ask where the data physically sits as part of that evidence. Keeping personal data in an Indian region simplifies the answer and shortens the conversation with a security reviewer. It does not remove the need for a data processing agreement, a sub-processor list and a retention policy, and no vendor should suggest otherwise.

Figure 8. Storage region is one line of the answer. Support access, backups and sub-processors are the lines a security reviewer asks about next.

Read the sub-processor list before you sign, not after. A platform can store records in Mumbai and still send data to a support tool, an analytics vendor or a model provider elsewhere. If your own customer contracts require approval before a new sub-processor is engaged, the migration is a change you may have to notify. That is a legal workstream running in parallel with the technical one, and it is the item most likely to be discovered late.

The invoice switch from card in euros to UPI in rupees

The billing change is small on paper and annoying in practice. A card billed in euros carries a foreign exchange markup that never appears as a line item, and the GST treatment of an imported service is a conversation with your accountant rather than a checkbox. Moving to rupee billing with an eighteen percent GST invoice and payment by UPI, netbanking, card or NEFT for annual plans removes the FX line and gives you an input credit you can actually claim, provided the invoice carries the right legal name and GSTIN.

Set the billing profile before the first payment. Correct entity name, registered address, GSTIN and a billing contact who reads email. An invoice with a misspelt entity is not a catastrophe, but reissuing one across a finance close is a nuisance that lands on somebody’s Friday. If you are not GST-registered, the tax is simply a cost, and the comparison against a foreign card charge is closer than the headline numbers suggest.

Figure 9. Published monthly price plus 18% GST, for budgeting only. Annual billing is twenty percent lower again with a twelve-month lock.

Annual billing carries a twenty percent discount and locks the price for twelve months, which is worth taking once you know your real volumes and not before. The risk of prepaying is choosing a tier based on a quiet month and then paying overage all year. Spend cap is on by default and overage is billed at the published rate, so the worst case is bounded, but a bounded surprise is still a surprise. Run a quarter on monthly billing first.

Cutover, then 72 hours of reading bounces

The cutover sequence is short and should feel anticlimactic. Freeze scheduled campaigns, confirm the suppression report, then send the seed test to Gmail, Outlook and Rediff from the live configuration. Rediff matters because Indian consumer inboxes do not behave like corporate ones, and a message that looks perfect in Gmail can arrive with a broken layout or a clipped subject line there. Only after the seed test passes do you publish the DNS change and swap the API keys in the systems that send transactional mail.

Keep the old account active for seventy-two hours. Not because you expect to go back, but because a customer will reply to an old thread, a template reference will turn out to be missing, and a report someone needs will be in the old dashboard. Read-only access is cheap and it removes the pressure to fix everything in the first hour. Cancel on day four with a written note of what was archived and where it lives.

The LoopNow workflow canvas showing a rebuilt lifecycle automation with a wait step, a branch and an exit condition. — **Figure 10.** A rebuilt automation on the canvas. The exit condition is the part teams forget to recreate, and it is the part that prevents duplicate sends.

During those three days, read bounces rather than totals. A bounce report tells you which domain is failing, which is usually a suppression gap or an authentication problem rather than a content problem. Read complaints too, because a complaint from an address that should have been suppressed is evidence that the import was incomplete. Log both daily, and compare against the last month of the old platform so the conversation about whether it worked has a baseline.

What stays behind, and what to keep paying for

Some things do not move and should not be pretended otherwise. Campaign history and per-recipient event logs stay in the old account, because the events describe a system that no longer exists. A/B test results stay for the same reason. The IP reputation your old account earned stays with that infrastructure. Template identifiers stay with the old account even after the content is rebuilt. If any of these appear in a migration plan as deliverables, the plan is wrong.

The SMS side deserves its own sentence, because it is regulated rather than portable. Commercial SMS in India runs against a registered header and registered templates under the TRAI DLT regime, and that registration belongs to your entity rather than to a platform. If you already have a header, confirm the new sender may use it and that each template is registered under the same entity. If you do not have one, this is a three-to-seven day task that no amount of platform spend can accelerate.

Figure 11. Four things that stay behind by nature rather than by choice. Plan what to export for the record, and what to pay to keep readable.

Finally, decide deliberately what to keep paying for. A quarter of read-only access to the old account is often worth the smallest plan, because support staff will search an old thread and finance will want the last invoice. After that quarter, export the contacts, bounces and campaign summaries to a folder your team can reach without a login, and close the account. Leaving it open indefinitely because nobody wants to decide is how organisations end up with four email platforms and no single answer to what the customer was sent.

Frequently asked questions

How long does a Brevo migration take?

Contacts, attributes, suppression and a first campaign can be live in about two days if the export is clean and the domain is already authenticated. Rebuilding transactional templates, retesting every trigger and reconstructing three automations takes one to two weeks of elapsed time. The SMS registration, if you need a new header, is a separate three-to-seven day queue that runs outside both platforms.

Can I keep Brevo for transactional email and use LoopNow for marketing?

Yes, and for some teams it is the right interim state. Split the streams by subdomain so each platform has its own DKIM and SPF, and keep the transactional triggers in one place so you do not create two sources of truth for a password reset. Running two senders permanently doubles the places where suppression has to be correct, so treat it as a stage rather than a destination.

What can actually be imported?

Contacts, custom attributes, consent state, unsubscribe and bounce suppression, and template content as material to rebuild. Automation definitions come across as documentation rather than as working logic. Campaign history, per-recipient events, A/B results and IP reputation do not transfer, and any plan that lists them is describing something the vendor cannot do.

How do I move bounce and opt-out state correctly?

As suppression records, not tags. Classify each entry as withdrawn consent, hard bounce, complaint or soft bounce, because they block different things. Import suppression before contacts, then run a match report and compare the suppressed-at-arrival count against the old account’s blocked count. A large gap means the match key is wrong, and the fix is normalising email and phone before anything is sent.

Is LoopNow suitable if my customers are in Europe?

Sometimes, but be honest about the trade. Brevo’s European residency is a genuine advantage for GDPR-first procurement, and LoopNow runs on AWS Mumbai. If European residency is a contractual requirement rather than a preference, staying is the lower-risk decision. If only part of your business is European, the residency question is worth a legal conversation rather than an assumption either way.

What happens to my SMS templates?

They are registered against a header under the TRAI DLT regime, and that registration belongs to your entity. The templates themselves have to be registered for the new sender, and the header must permit it. Confirm the current requirements with your operator or DLT registrar, because this is a regulated process with its own review time and it does not move at the speed of a software migration.

How do GST invoices work after the switch?

Prices are in rupees and exclusive of eighteen percent GST, with a GSTIN invoice issued on every payment and payment accepted by UPI, netbanking, card or NEFT for annual plans. Give the correct legal name, address and GSTIN before the first payment so the credit is claimable. Foreign card billing in euros usually carries an FX markup that never appears as a line, which is part of why the rupee invoice is easier to reconcile.

Do I need to rebuild every automation?

No. Rebuild the ones that carry revenue or a legal or contractual obligation, and put the rest in a dated backlog. Five rebuilt automations with fixed test cases are safer than fifteen approximate ones, because an automation that fires twice or skips a wait is worse than one that is switched off. Retire anything nobody can explain, and say so in the cutover note.

What is the biggest risk in this migration?

Sending to the full list on day one of a new sending infrastructure, usually because a campaign was already scheduled. Warm in the order of recipient interest: transactional first, then engaged contacts, then the broader list, then the cold tail. Publish a pause condition next to the ramp plan so stopping is an anticipated decision rather than an argument with the person who booked the campaign.

Should I keep the old account open?

For 72 hours at minimum, read-only, so a reply to an old thread or a missing report does not become an emergency. A quarter of cheap read-only access is often worth it for support and finance. After that, export contacts, bounce reports and campaign summaries to a shared folder that does not require a login, and close the account rather than letting it renew by habit.