Move without losing your list, number or templates.
Eight cutover playbooks. Suppression lists first, DNS last, 72-hour rollback window.
Free migration
Contacts, templates, automations and WhatsApp number. 48 hours typical.
Migrate from Mailchimp
Contacts, templates, automations and suppression lists move in a fixed order, with the sending domain authenticated before DNS is switched.
Read the playbook
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.
Read the playbook
Migrate from Zoho Campaigns
Zoho CRM stays connected through the native integration while campaigns, templates and unsubscribe state move to a domain you authenticate.
Read the playbook
Migrate from SendGrid
Transactional templates, webhooks and event consumers are rebuilt and tested trigger by trigger, with warm-up before marketing traffic follows.
Read the playbook
Migrate from Klaviyo
Shopify catalog sync is verified first, then abandoned cart, welcome and post-purchase flows are rebuilt and measured against the old baseline.
Read the playbook
Migrate from HubSpot
HubSpot can remain the CRM while campaign execution moves out; contacts sync with lifecycle stage and consent instead of being duplicated.
Read the playbook
Migrate from AiSensy
Display name and template approvals travel with the number when the BSP changes, so the opt-out list has to land before any send.
Read the playbook
Migrate from Interakt
WhatsApp automations and Shopify flows are rebuilt before the number moves, so existing template approvals survive the cutover.
Read the playbook
The short version
- A migration moves four things at different speeds: contacts and consent in an afternoon, templates in a few days, automations over one to two weeks, and send history not at all.
- Suppression loading comes before the first campaign, not after it. Importing a clean list and then mailing it is the single most common way a switch damages a domain.
- Domain authentication, WhatsApp template re-approval and TRAI DLT registration are the three queues outside anyone’s control. Start them on day zero and plan around them.
- Budget one overlapping billing month. Keep the old platform active and read-only for 72 hours after cutover; cancel on day four, not on cutover night.
- LoopNow imports contacts, custom fields, consent state, suppression lists, templates and your WhatsApp number. It does not import another vendor’s campaign history, event logs or lead scores.
- The quick path is real: a clean list with an already-authenticated domain can be live in about 48 hours. The full path, with automations rebuilt and verified, is closer to two weeks.
What a platform migration actually moves
People describe a migration as a copy, and that description is where most projects go wrong. What is really happening is that four different assets move at four different speeds, and only one of them behaves like a file transfer. Contact records and consent flags move quickly because they are rows in a table with a known shape. Message templates move more slowly because each one has to be rebuilt in a new editor and, on WhatsApp, sent back through an approval queue that belongs to Meta rather than to either vendor. Automation logic moves slowest of all, because an automation is a decision tree that has absorbed two years of small corrections, and those corrections live in the head of whoever built it.
The fourth asset does not move at all. Send history, per-recipient event logs, deliverability reputations attached to a specific IP, A/B test results, lead scores and internal notes held against a campaign are all tied to the platform that produced them. You can export some of it as CSV for your own records, and you should, but you cannot load it into a new system and expect it to mean the same thing. A migration plan that promises to preserve reporting continuity is either misunderstanding the problem or selling you something. Plan to start reporting from the cutover date and keep the old dashboard as an archive for the quarter.
This is why the honest shape of a migration is a sequence of checkpoints rather than one long task. Each checkpoint has a pass condition you can state in a sentence: the suppression list is loaded and matched, the domain passes authentication, the seed test lands in the inbox at three providers, the first rebuilt automation produces the same outcome as the old one on a fixed test case. If a checkpoint fails, you stop and fix it before the next one starts, because every later step assumes the earlier one held. That discipline is worth more than any tool.
The four inventories to take before you touch anything
Every migration that runs late skipped the inventory. The inventory is not a spreadsheet of contact counts. It is four lists that answer the question of what you currently depend on, written down by someone who has actually used the account in the last month. The first list is people: how many contacts, which fields, which of those fields are used in a template or a segment, and how many are unsubscribed or suppressed. The second is content, meaning every template and campaign that is still in rotation, with the variables it expects and who owns it.
The third list is behaviour, and it is the one teams underestimate. Write down each automation with three facts attached: what triggers it, what it sends, and what would visibly break in the business if it stopped. That third column is how you decide what must be rebuilt before cutover and what can wait in a backlog. The fourth list is plumbing: sending domains and subdomains, every DNS record that touches mail, API keys and who holds them, webhook endpoints and the systems behind them, any dedicated IP, and the person who can change DNS at nine on a Monday morning without filing a ticket.
Take the inventory in the vendor dashboard rather than from memory, because memory is generous about what is still running. Anything you cannot see and cannot export, write down as unverified and plan to check by sending a test through it. The inventory takes an afternoon for a small account and two days for one with a decade of accumulated campaigns. It is the cheapest part of the project and the only part that makes the estimate credible.
Deciding whether to migrate at all
Not every account should move, and a migration guide that cannot say so is a sales document. There are clear cases where staying is the better decision. If you need a very large global template library and a mature drag-and-drop editor, a specialist email product will serve you better than a runtime that treats email as one channel among five. If your work is entirely WhatsApp broadcasts with a simple chatbot and price is the deciding factor, a single-channel platform with a lower entry point is the rational purchase. If procurement requires European data residency and a GDPR-first paper trail, a platform built around that requirement is the lower-risk answer.
The case for moving is usually not about a missing feature. It is about the cost of the seams between tools: three consent states that disagree, a CRM that never learns what happened on WhatsApp, a report that has to be assembled by hand every Monday. Those seams are invisible on a pricing page and expensive in payroll. If your team spends a day a week reconciling channels, the migration is really an integration project and should be judged on that basis rather than on a per-message price comparison.
There is also a middle path that many teams should take and few consider: migrate the execution layer and leave the system of record alone. Keep the CRM you already pay for, move campaigns, WhatsApp and voice onto the new runtime, and connect the two with a sync instead of a data migration. That halves the risk, keeps the sales team’s pipeline intact and usually gets you most of the benefit. We recommend it more often than a full replacement, including when the CRM is a competitor’s product.
The working plan, day by day
A realistic small-account plan fits in ten working days and has five checkpoints. Day zero is access and inventory: create the new workspace, invite the two people who will actually run it, take the four inventories, and start the three queues that depend on other people. That last item matters more than the rest, because Meta template review, TRAI DLT registration and DNS propagation all run on someone else’s clock, and starting them on day six is how a ten-day plan becomes a three-week plan.
Days one and two are data. Export contacts with every field you intend to keep, map the fields into the new schema, and load the suppression list first as a separate step so you can prove it matched. Then load contacts in batches small enough that a mistake is recoverable, and spot-check twenty records by hand against the source. Days three to five are content and identity: authenticate the sending domain, rebuild the templates that are actually in rotation, and rebuild the first automation end to end with a fixed test case that produces a known outcome.
Days six to eight are rehearsal. Run a seed test to Gmail, Outlook and a Rediff or Yahoo address, because Indian consumer inboxes behave differently from corporate ones. Send a real campaign to an internal list of staff and one friendly customer. Replay a webhook into the downstream system and confirm the record lands where the sales team expects it. Days nine and ten are cutover and watch. The full sequence with pass conditions is below, and the version with automations rebuilt rather than duplicated is closer to two weeks.
Domain authentication decides your week
If you send email, the domain is the project. Authentication is not a LoopNow-specific setting; it is the set of DNS records that tell receiving providers your mail is allowed to carry your name. You need a DKIM key published at a selector, an SPF record that authorises the new sender without exceeding the ten-lookup limit, and a DMARC policy that tells providers what to do when both fail. Get the order wrong and your first campaign lands in spam while everyone blames the new platform.
The safe sequence is boring and it works. Lower the TTL on the records you are about to change to five minutes and wait for the old TTL to expire. Publish the new DKIM key on a subdomain you control, verify it with a test send, then add the new sender to SPF, then move DMARC to p=none with a reporting address you actually read. Only after a week of clean reports should you tighten to quarantine. Never delete the old DKIM record on cutover night; leave it for a month so in-flight mail still validates.
The most expensive mistake is editing the root domain’s mail records when you only meant to change marketing mail. If your company email runs on the same root domain, send marketing from a subdomain such as mail or news, authenticate that subdomain separately, and leave the root MX and SPF untouched. This costs one extra DNS zone and saves you an outage in which nobody in the company can receive email. Write the record changes down before you make them, and have a second person read them.
Consent, suppression and erasure under DPDP
Under the Digital Personal Data Protection Act, consent has to be free, specific, informed and unambiguous, and it has to be demonstrable. In practice that means a boolean column is not enough. For each contact you want the timestamp of consent, the source it came from, the wording the person actually saw, and the channels that consent covers. A person who opted in to order updates on WhatsApp has not thereby agreed to marketing email. If you cannot reconstruct that from your current platform, the honest position is that the evidence is partial, and the migration is the moment to fix it rather than to copy the gap forward. Keeping that ledger in the same workspace as the channels, on AWS Mumbai in ap-south-1, also means the answer to where the evidence lives is one sentence rather than a tour of four tools.
Suppression is a separate list from unsubscription and should be loaded before anything else. Hard bounces, spam complaints, manual blocks, erasure requests and people who asked to be left alone by phone call all belong there. Load it first, then load contacts, then run a match report that tells you how many imported records were suppressed on arrival. If that number is zero on an account with a few years of history, the import is wrong, not the account. Matching should use normalised email plus normalised phone, because the same human appears twice with two spellings.
Erasure is the requirement teams forget until a request arrives. When someone withdraws consent, the record should stop receiving messages immediately, and the erasure workflow should remove or anonymise their personal data within the period your policy states while keeping the minimum audit trail that proves you did it. That means backups matter: an erasure that leaves the person in last month’s CSV export is not an erasure. Keep a do-not-contact list of hashed identifiers that survives deletion, so a future import cannot quietly resurrect them, and test the workflow once with a staff address before you need it.
The two approval queues you cannot skip
Two of the items on your critical path do not belong to LoopNow or to your current vendor. The first is Meta’s template review for WhatsApp. Templates are reviewed against category rules, and the category determines both the price and the rejection risk. A message that reads like a promotion but is submitted as utility will be reclassified or rejected, and a rejected template blocks the campaign that depends on it. Submit early, submit the exact variables you will use, and expect at least one round of edits on a large library.
The second is TRAI’s DLT regime for SMS. Commercial SMS in India has to be sent against a registered header and a registered template, and the registration happens through a portal operated by the telecom ecosystem rather than inside your marketing tool. If you have never sent SMS from your own header, this is a three-to-seven day task you cannot compress by paying more. If you already have a registered header, confirm the new sender is permitted to use it and that the template IDs will still resolve.
Plan the rest of the project around these two queues rather than in parallel with them. The tempting move is to schedule cutover for the day the data is ready, then discover that the template the whole campaign depends on is still in review. Put the approval start date on day zero, keep a list of which templates are approved, pending and rejected, and treat a rejection as a content problem to solve rather than a vendor problem to escalate. Neither Meta nor TRAI has a support line that responds to urgency.
Billing, GST and the month you pay twice
Every migration has one month where two invoices arrive and only one of them is producing revenue. Budget for it openly instead of discovering it in a finance review. The old platform’s billing cycle rarely aligns with your cutover date, and cancelling early to save a few thousand rupees is how teams lose the rollback option they end up needing. Keep the old account on its cheapest viable plan through the overlap, then cancel once the new sender has run cleanly for a week.
On the LoopNow side, prices are in rupees and exclusive of eighteen percent GST, with a GSTIN invoice on every payment and payment by UPI, netbanking, card or NEFT for annual plans. If you are registered, that GST is input credit rather than a cost, but only if the invoice carries your correct GSTIN and legal name, so fix the billing profile before the first payment rather than after it. Annual billing carries a twenty percent discount and a twelve-month price lock, which is worth taking only once you have run a full quarter and know your real volumes.
Watch the allowance rather than the sticker price. Overage is billed at the published rate, which for email is three paise per delivered message and for voice two rupees twenty per connected minute, and the spend cap is on by default so a runaway campaign stops instead of producing a surprise invoice. A team that sends a large festive campaign in one week can exceed a monthly email allowance without doing anything wrong, so model your peak week rather than your average month before choosing a plan tier.
Rollback: write it before you need it
A rollback plan is not pessimism, it is the thing that lets you cut over on a Thursday afternoon instead of waiting for a quiet weekend that never comes. Write down four facts before cutover. Which DNS records change and what their exact previous values were. Which API keys or webhook URLs move and who holds the old ones. Where the suppression snapshot lives, with a timestamp. And what the old platform will still let you do once you stop sending from it, because most vendors keep data readable for a period and almost none keep it sendable indefinitely.
The practical rollback is rarely a full reversal. If the new sender is producing bounces on one domain while the rest is clean, you fix the domain rather than abandoning the migration. If WhatsApp templates are stuck in review, you keep the old BSP sending that one campaign and move the rest. Partial rollback is normal and should be designed in: keep the old sending path warm for the channels that are still transitioning, and define in advance which single metric would trigger a reversal rather than an argument at midnight.
The line that ends the rollback window is not arbitrary. After seventy-two hours, enough mail has been sent from the new domain and enough replies have landed in the new inbox that going back costs more than fixing forward. Publish that line to the team at the start, along with the name of the person who can call it. A migration with no stated rollback window tends to acquire one by accident, three weeks later, when someone re-enables an old automation and half the list gets a duplicate message.
Post-cutover checks for the first 72 hours
The cutover is not the finish line, it is the start of the only period where problems are cheap to fix. Work through a fixed checklist rather than waiting to feel that something is wrong. Send the seed test again from the live configuration, not from the test configuration, and check that it lands in the inbox at Gmail, Outlook and one Indian consumer domain. Confirm the DKIM signature validates and DMARC passes, because a record that verified in staging can still be wrong once the live selector is used.
Then check the boring plumbing that nobody enjoys testing. Does an unsubscribe actually stop the next send, and does it write back to the CRM or only to the new platform. Do click and UTM parameters survive into analytics, or is every visit now attributed to direct. Do webhooks fire once rather than twice, and does a failed delivery retry instead of vanishing. Does the WhatsApp quality rating hold, and are template replies landing in the shared inbox rather than a single agent’s screen. Each of these is a five-minute check and a two-day repair if found late.
Keep a written log for the three days: volume sent, bounce rate by domain, complaint count, unsubscribes, replies, and anything a human flagged. A short log is what turns an argument about whether the migration worked into a comparison against the old baseline. At the end of the window, archive the old account’s exports somewhere your team can reach without a login, cancel the old plan, and write a one-page note on what you would do differently. That note is worth more to the next migration than any vendor documentation.
What takes an afternoon and what takes two weeks
Effort estimates for migrations are usually wrong in the optimistic direction because they describe the data move and not the rebuild. Be concrete about the split. Loading a clean contact list with mapped fields and a suppression list is an afternoon for a few thousand records and a day for a large account, provided the source export is tidy. Publishing DKIM and SPF records is twenty minutes of work plus whatever propagation takes. Creating a workspace, inviting the team and setting a billing profile with a GSTIN is under an hour.
The expensive items are the ones with human judgement inside them. Rebuilding a template library of forty pieces is several days even with a good editor, because each one needs its variables checked and its copy read. Rebuilding the automations that matter takes one to three days each if they are simple, and closer to a week if they branch on CRM state, wait for a human, or call an external API. Writing consent evidence that will survive an audit is a project in itself for an account that never recorded it. None of this is LoopNow-specific; it is the cost of the logic you already own.
Say plainly what cannot be imported, because a failed expectation costs more trust than a limitation. LoopNow cannot import another platform’s campaign history, per-recipient event stream, lead scoring model, A/B test results or the internal notes attached to them. It cannot bring across a dedicated IP’s reputation, and no vendor can. It cannot recreate a proprietary chatbot builder’s exact flow graph, only the behaviour you describe and it rebuilds. Anything you cannot find in an export is not a migration item; it is a rebuild item, and it should be scheduled as one.
Frequently asked questions
How long does a migration actually take?
A clean contact list with an already-authenticated sending domain can be live in about 48 hours, which is the figure most vendors quote. That covers data, domain and a first campaign. Rebuilding automations, re-approving a WhatsApp template library and completing DLT registration is closer to two weeks of elapsed time, most of it waiting on external review rather than on work.
What can LoopNow import from another platform?
Contacts, custom fields, consent state, unsubscribe and suppression lists, templates as content to rebuild, and your WhatsApp Business number through a BSP transfer. WhatsApp templates have to be resubmitted because approval belongs to Meta. Anything not present in an export, such as campaign history or lead scores, cannot be imported and should be treated as a rebuild item.
Do I have to move my CRM as well?
No, and usually you should not. Keeping HubSpot, Zoho, Salesforce or Freshsales as the system of record and moving only campaigns, WhatsApp and voice is the lower-risk path. It halves the data work and keeps the sales team’s pipeline untouched. LoopNow connects to the CRM rather than requiring you to replace it.
When should the suppression list be loaded?
Before any contact is mailed, and as its own step so you can verify it. Load unsubscribes, hard bounces, complaints, manual blocks and erasure requests first, then load contacts, then run a match report. If nothing matches on an account with years of history, the import is wrong. Mailing a freshly imported list without suppression is the most common cause of deliverability damage during a switch.
What happens to my WhatsApp templates?
They are rebuilt and resubmitted to Meta for approval, with the same category and the same variables. The approval decision belongs to Meta, not to either vendor, so no migration can preserve an approval it does not own. Keep the old template IDs on hand during the transition, because messages already in flight may still reference them.
Can I run both platforms at the same time?
For email, yes, and you should for a short window while you compare results. For WhatsApp, a number can only be attached to one Business Solution Provider at a time, so parallel running means a separate test number rather than the production one. Plan the number transfer as an ordered step with a verification checkpoint, not as a background task.
Is my data stored in India?
LoopNow runs on AWS Mumbai, ap-south-1, which is the residency position most Indian buyers are asked to evidence. If your own obligations require a specific region, private VPC or a signed data processing agreement, that is an Enterprise conversation. Ask for the sub-processor list and read it before you sign rather than after.
What does the migration cost?
Migration help is included rather than priced as a professional services line, and you pay only for the plan you run on. The real cost is the overlapping month where two platforms are billed and the internal hours spent rebuilding automations. Budget one month of double billing and between five and fifteen working days of somebody’s time, depending on how much automation you own.
How do I handle GST invoices during the overlap?
Set the billing profile with your legal name, address and GSTIN before the first payment, so the invoice is claimable as input credit rather than a cost. Keep both vendors’ invoices for the overlap month. If you switch to annual billing for the twenty percent discount, do it after a quarter of real volume so the tier matches your peak week.
What is the single biggest cause of a failed migration?
Sending before suppression is loaded, usually because the data move looked finished and the team wanted to prove the new platform worked. The second most common is changing root domain mail records when only marketing mail needed to move. Both are process failures rather than product failures, and both are prevented by a written checkpoint that someone other than the sender signs off.