# Switch Your WhatsApp BSP Without Breaking Your Business
## 47-point India 2026 checklist · DPDP-ready · Meta-approval-aware

You signed up with your current WhatsApp Business Solution Provider (BSP) somewhere between 2022 and 2024. Pricing was reasonable, the dashboard looked clean, and Meta approval came through in a week. Then volumes grew. Per-conversation pricing crept up. Template approvals started slipping. Support tickets started bouncing between L1 agents. And now you are paying ₹40,000 to ₹4 lakh a month for a platform that you suspect is marking up Meta's pass-through rates and locking you into a contract you cannot read in plain English.

This 47-point checklist exists because we have helped over 60 Indian D2C, BFSI, fintech and SaaS teams switch BSPs without breaking a single template, losing a single contact, or burning a single rupee of Meta Quality Score. Every checkpoint below is something we ran into the hard way on a live migration. Skip a step and you will pay for it — sometimes in delivery rates, sometimes in DPDP non-compliance, sometimes in the dreaded Meta Business Manager phone-number transfer that gets stuck for 14 days.

Use this as a working document. Print it. Tick boxes. Assign owners. The checklist is organised in chronological order: audit first, export second, evaluate third, migrate fourth, comply fifth, cut over sixth, optimise seventh. Do not jump steps. Do not "merge" steps. Each checkpoint includes Why it matters, Owner, Time estimate, Tool or resource link, and a specific Action paragraph.

---

## Section 1 · Pre-switch audit (8 points)

### 1.1 Audit your real monthly BSP spend (all-in)
- **Why it matters:** If you only know the headline "₹0.115 per message" number, you are missing 60% of the actual bill. Platform fees, per-agent licences, DLT scrubbing fees, integration add-ons, and Meta pass-through markup all hide on separate invoice lines or get bundled into "platform subscription".
- **Owner:** Finance + Ops manager (joint)
- **Time:** 30 min
- **Tool:** Last 3 months of BSP invoices, your accounts payable ledger, your bank statement showing GST input credits
- **Action:** Open the last 3 invoices from your current BSP. List every line item. Separate Meta pass-through (utility, marketing, authentication, service conversations) from BSP platform fees from per-agent seats from integration add-ons (CRM connector, e-commerce plugin, IVR bridge). Add GST. Divide by the message volume to get your real cost per message. Most teams discover the true number is 2.3× to 4.1× the headline rate.

### 1.2 Pull a 90-day message volume report by category
- **Why it matters:** Meta charges four different rates (utility, marketing, authentication, service). If your BSP cannot break this down by category for the last 90 days, you cannot model what the switch will save you — and your new BSP will lowball the estimate.
- **Owner:** Ops manager
- **Time:** 1 hour
- **Tool:** BSP analytics dashboard, Meta Business Manager → WhatsApp Manager → Insights
- **Action:** Export message volumes split by Marketing, Utility, Authentication, and Service. Note the directionality (business-initiated vs user-initiated). Note delivery rate, read rate, and reply rate per category. Save as CSV. This becomes the baseline you measure the new BSP against in week 2 of cut-over.

### 1.3 Inventory every approved message template
- **Why it matters:** Template re-approval on a new BSP takes 24 hours to 7 days per template. If you have 80 templates and you only discover this on cut-over day, you will be sending raw text to a degrading Quality Score for two weeks.
- **Owner:** Ops manager + marketing lead
- **Time:** 2 hours
- **Tool:** Meta Business Manager → WhatsApp Manager → Message Templates (filter by Approved, Active)
- **Action:** Export the full template list. For each template note: name, category (marketing/utility/auth), language, header (text/image/video/document), body variables, footer, button types (CTA URL, quick reply, OTP), and last-30-day send volume. Flag templates that have been edited in the last 30 days — those need fresh approval anyway, so switch them first as a low-risk test.

### 1.4 Map your opt-in consent base by source
- **Why it matters:** Under the DPDP Act 2023 (operationalised 2025), every WhatsApp contact must have provable, granular, free-text consent that you can produce in a regulator audit. If your consent records live only inside your current BSP, you do not actually own them.
- **Owner:** Legal + Ops manager
- **Time:** 3 hours
- **Tool:** DPDP Act 2023 gazette, your CRM, your BSP contact list export
- **Action:** Pull your contact list and tag each contact by consent source: checkout opt-in, web form, landing page, IVR transfer, offline kiosk, imported from third party (red flag), purchased list (delete immediately). For each source, verify that you have stored: timestamp, IP or device ID, consent text shown verbatim, and link to the privacy notice version the user saw. Contacts without all four fields cannot legally be messaged in 2026 — flag them for re-consent campaign or deletion.

### 1.5 Catalogue your active flow automations
- **Why it matters:** Every chatbot flow, drip sequence, abandoned-cart recovery and post-purchase journey on your current BSP will need to be rebuilt — or migrated via JSON export if your new BSP supports it. Discovering a 14-step flow on day-of-switch is the #1 cause of cut-over rollback.
- **Owner:** Ops manager + automation lead
- **Time:** 4 hours
- **Tool:** Current BSP flow builder, screen recording software
- **Action:** Open every published flow. Screenshot or screen-record the full graph. Document each node: trigger condition, message body, variable substitutions, branching logic, delay timings, integration calls (CRM update, webhook fire). Save in a shared folder named `/flows-current-bsp-snapshot-{YYYY-MM-DD}/`. This becomes the build-spec for the new BSP.

### 1.6 List every integration touching the WhatsApp inbox
- **Why it matters:** Most teams have 4 to 11 external systems writing into or reading from their WhatsApp BSP — CRM, e-commerce, helpdesk, payment gateway, analytics, IVR, custom apps. Each one is an API key, a webhook URL, or a Zapier zap that breaks on switch day if you forget it.
- **Owner:** CTO / engineering lead
- **Time:** 2 hours
- **Tool:** Current BSP API key audit log, your Zapier/Make/n8n account, your CRM integration settings
- **Action:** Open the API keys section of your current BSP and list every active key with last-used timestamp. Cross-reference against your engineering team's known integrations. Find the ones nobody remembers (there will be at least two). Document for each: system name, owner, purpose, endpoints called, expected volume, fallback plan if the integration is down for 4 hours during cut-over.

### 1.7 Calculate your Meta Quality Score baseline and tier
- **Why it matters:** Switching BSPs does not reset your Quality Score (it is attached to the phone number, not the BSP), but a botched migration can crash it from High to Low in 48 hours, throttling your messaging tier from 100k to 1k/day.
- **Owner:** Ops manager
- **Time:** 15 min
- **Tool:** Meta Business Manager → WhatsApp Manager → Phone Numbers → Quality Rating
- **Action:** Screenshot today's Quality Rating (High/Medium/Low) and current messaging tier (1k, 10k, 100k, unlimited). Note the date. This becomes your "do no harm" benchmark — if Quality drops in the 14 days post-switch, you have a deliverability problem to fix before scaling marketing volume.

### 1.8 Read your current BSP contract for exit clauses
- **Why it matters:** Several Indian BSPs include 30-day to 90-day notice periods, data deletion windows (often 7 days after which exports are deleted), early-termination fees, or "platform fee non-refundable" clauses that cost lakhs on exit.
- **Owner:** Legal + Finance
- **Time:** 2 hours
- **Tool:** Your signed MSA + latest SoW, a coffee
- **Action:** Read the termination, data portability, and refund clauses. Note the exact notice period required, the format the notice must be served in (email vs registered post), the data-export window post-termination, and any auto-renewal triggers. Set a calendar reminder 7 days before the notice deadline. If the contract has a 12-month lock-in and you are 4 months in, calculate whether the switch ROI still beats the lock-in penalty.

---

## Section 2 · Data export (6 points)

### 2.1 Export the complete contact list with metadata
- **Why it matters:** Your contacts are your business. Some BSPs export only phone numbers; others export full metadata (name, opt-in date, tags, custom fields, conversation count). The difference is whether you arrive at the new BSP with a customer database or a phonebook.
- **Owner:** Ops manager
- **Time:** 1 hour
- **Tool:** Current BSP contact export (CSV), backup to your CRM
- **Action:** Trigger the full contact export from your current BSP. Verify the CSV includes: phone (E.164 format), name, opt-in source, opt-in timestamp, tags/labels, custom attributes, last-message timestamp, and lifetime conversation count. Re-import into your CRM first (so your CRM becomes the source of truth) and only push to the new BSP after the new BSP is provisioned.

### 2.2 Export opt-in consent records with audit trail
- **Why it matters:** Under DPDP Act 2023 Section 6, consent records must be portable and producible to the Data Protection Board for 7 years. If your current BSP "owns" the consent log and you cannot extract it in machine-readable format with timestamps and consent text, you are non-compliant the moment you switch.
- **Owner:** Legal + Ops
- **Time:** 4 hours
- **Tool:** Current BSP consent log API, DPDP Act 2023 Section 6 gazette
- **Action:** Request a full consent log export from your current BSP in JSON or CSV format including: phone, consent text shown verbatim, timestamp, IP/device ID, privacy notice version, opt-in channel, and any subsequent withdrawals. Store in encrypted cloud storage with access log. If your current BSP cannot produce this in a regulator-acceptable format, treat that as a compliance incident and document it.

### 2.3 Export the message template library as JSON
- **Why it matters:** Templates approved on the old BSP are tied to your Meta-verified business account, not the BSP — but the template content, variable maps, and category metadata live in the BSP. Without a clean export, you will rebuild from screenshots, introducing typos that fail re-approval.
- **Owner:** Ops manager
- **Time:** 1 hour
- **Tool:** Current BSP template API, plain-text editor for cleanup
- **Action:** Call the BSP template API and dump every template in JSON. Verify each template object includes name, language, category, components (header/body/footer/buttons), variable examples, and approval status. Save to version control (private repo) so you have an immutable migration source.

### 2.4 Export 90 days of conversation history
- **Why it matters:** Conversation history is needed for sales context (so agents do not ask the same question twice on the new BSP), customer service audits, and dispute resolution. Most Indian BSPs delete conversation history within 30 to 90 days of contract termination.
- **Owner:** Ops + Engineering
- **Time:** 4 hours to 2 days (depending on volume)
- **Tool:** Current BSP conversation export API or webhook log, S3/Azure Blob for storage
- **Action:** Pull conversation logs in JSON for the last 90 days, segmented by contact. Include inbound and outbound messages, timestamps, agent IDs, status (sent/delivered/read/failed), and any internal notes. Store in S3 with appropriate retention (recommend 13 months for GST audit alignment) and encryption-at-rest.

### 2.5 Export billing history for the last 12 months
- **Why it matters:** For GST input credit reconciliation, for board-level cost reporting, and for the "what did we actually pay" conversation with your new BSP, you need clean invoice data. Some BSPs delete invoice access 30 days after termination.
- **Owner:** Finance
- **Time:** 30 min
- **Tool:** Current BSP billing portal, your accounting software
- **Action:** Download all invoices (PDF + CSV line items) for the trailing 12 months. Verify GSTIN on every invoice matches your registered GSTIN. Cross-check input credit claimed vs invoice received. Save to your finance team's evergreen archive — not the BSP portal.

### 2.6 Export API logs and webhook delivery history
- **Why it matters:** When the new BSP says "we did not receive that order webhook", you need the old BSP's outbound webhook log to prove it was sent. API logs are the forensic record of every integration call.
- **Owner:** CTO / engineering lead
- **Time:** 2 hours
- **Tool:** Current BSP API audit log, your application server logs
- **Action:** Export the last 30 days of API audit logs from your current BSP. Cross-reference against your application server's inbound webhook receipt log. Identify any gaps (webhooks sent but never received, or received but not processed) — these are existing bugs that will mask new-BSP issues during cut-over. Fix the bugs before switching, not after.

---

## Section 3 · Provider evaluation (8 points)

### 3.1 Demand Meta pass-through pricing transparency
- **Why it matters:** Meta's per-conversation rates are public (e.g. ₹0.115 marketing in India 2026). Many Indian BSPs mark this up 30% to 80% and call it "platform fee included". You should see Meta's rate and the BSP's margin separately on every invoice.
- **Owner:** Finance + Ops
- **Time:** 1 hour (per shortlisted BSP)
- **Tool:** Meta WhatsApp Business Pricing page, BSP pricing sheet, BSP sample invoice
- **Action:** Ask every BSP on your shortlist for a sample invoice showing the Meta pass-through line item separately from the BSP platform fee. If they cannot or will not show this, eliminate them. Cross-check the Meta line against [Meta's published rates](https://developers.facebook.com/docs/whatsapp/pricing). Any markup above Meta's actual rate is BSP margin and should be called out as such.

### 3.2 Verify India data residency and India data centre
- **Why it matters:** DPDP Act 2023 plus RBI data-localisation circulars (for BFSI) plus IRDAI for insurance plus IT Rules 2021 Section 5 all push toward in-India processing. A BSP routing data through Singapore or Ireland creates a compliance grey zone that becomes red in an audit.
- **Owner:** Legal + CTO
- **Time:** 2 hours per BSP
- **Tool:** BSP infrastructure documentation, MEITY data-localisation guidance
- **Action:** Ask the BSP for: (a) primary data centre location and provider (AWS Mumbai? Azure Pune? Yotta?) (b) failover region (c) data-at-rest encryption (d) data-in-transit encryption (e) whether any PII is processed outside India. Get this in writing on letterhead, not in a sales deck.

### 3.3 Confirm DPDP audit-trail support on the BSP platform
- **Why it matters:** When the Data Protection Board requests consent records or data-access logs, you have 72 hours to produce them. If your new BSP cannot generate a consent audit-trail in regulator-acceptable format, you are the one fined — not the BSP.
- **Owner:** Legal
- **Time:** 1 hour per BSP
- **Tool:** DPDP Act 2023 Section 6 + Section 8, BSP compliance documentation
- **Action:** Ask the BSP to show you a live demo of: pulling consent records for a sample contact, producing a data-access report for a Data Principal request, and triggering data deletion (right to erasure) within statutory timelines. If the demo involves "we will build that for you in Q3", treat it as not available.

### 3.4 Test support SLA with a real ticket before signing
- **Why it matters:** Indian BSP support quality ranges from "founder picks up at 11pm" to "ticket open 14 days, three L1 agents, no resolution". You will only know which one your shortlisted BSP is by raising a real ticket during evaluation.
- **Owner:** Ops manager
- **Time:** 1 week (the evaluation window)
- **Tool:** A test WhatsApp number, a deliberately tricky question
- **Action:** Open a trial account with each shortlisted BSP. Raise a ticket asking something non-trivial (e.g. "how do I rebuild Quality Score after a 2-day drop"). Note: time to first human response, time to resolution, accuracy of the answer, and whether the response was templated or specific. Compare across BSPs. The cheapest BSP with bad support costs more than the mid-priced one with good support — every time.

### 3.5 Verify founder accessibility for enterprise accounts
- **Why it matters:** When something goes wrong at 9pm on a Diwali sale day, you do not want to wait for L1 → L2 → L3 escalation. The BSPs that win at the enterprise end have a founder or VP-Engineering on Slack/WhatsApp with you.
- **Owner:** Founder / CEO
- **Time:** 30 min
- **Tool:** LinkedIn, your network, a direct ask
- **Action:** Ask the BSP shortlist: "Can the founder or a VP be available on WhatsApp for P0 incidents?" Get the answer in writing. For accounts above ₹50k/month, this should be table stakes. If the BSP cannot offer it, you are an SMB account to them, not an enterprise account, and the support will reflect that.

### 3.6 Audit integration depth for your specific stack
- **Why it matters:** A BSP that integrates with Shopify but not your custom Laravel app, or with HubSpot but not your Zoho CRM, will require custom development that erodes the migration ROI.
- **Owner:** CTO
- **Time:** 2 hours per BSP
- **Tool:** BSP integration marketplace, your stack inventory from checkpoint 1.6
- **Action:** Map your stack (CRM, e-commerce, helpdesk, payment, analytics) against the BSP's native integration list. For every gap, get a written estimate of custom-integration effort. Factor that cost into the switch ROI calculation. Beware of "we have an API, build it yourself" — that is not an integration.

### 3.7 Check white-label and multi-tenant support if relevant
- **Why it matters:** Agencies, SaaS platforms, and multi-brand groups need white-label or multi-tenant capability. Retrofitting it later is painful; choosing a BSP that has it natively is cheap.
- **Owner:** Founder / Product
- **Time:** 1 hour per BSP
- **Tool:** BSP white-label documentation, live demo
- **Action:** If you operate multiple brands or sub-accounts, ask for a live demo of: branded subdomain, custom email sender, per-tenant billing, per-tenant API key isolation, and per-tenant Meta Business Manager link. Pricing for white-label should be transparent and not "contact sales".

### 3.8 Read the contract lock-in and exit clauses before signing
- **Why it matters:** You are switching because the last BSP locked you in. Do not repeat the mistake. Aim for month-to-month or 30-day notice, with data export guaranteed in writing.
- **Owner:** Legal + Founder
- **Time:** 3 hours
- **Tool:** Draft MSA from the new BSP, a redline tool (Google Docs, Word track changes)
- **Action:** Redline the new BSP's draft MSA. Push back on: minimum term, auto-renewal language, data deletion timeline post-termination, price escalation clauses, exclusivity, and any "platform fee non-refundable" wording. Add a clause guaranteeing data export in machine-readable format within 7 business days of termination request. If they will not move on these, that is your answer.

---

## Section 4 · Technical migration (10 points)

### 4.1 Initiate phone-number transfer in Meta Business Manager
- **Why it matters:** The phone number transfer between BSPs (technically an On-Behalf-Of asset reassignment in Meta Business Manager) is the highest-risk step in the entire migration. It can take 24 hours or 14 days depending on Meta's mood and your verification status, and during that window you cannot send messages.
- **Owner:** CTO + Ops manager (joint sign-off)
- **Time:** 1 day to 14 days (largely outside your control)
- **Tool:** [Meta Business Manager](https://business.facebook.com) → Business Settings → WhatsApp Accounts → Phone Numbers → Manage permissions
- **Action:** Before initiating transfer, ensure: (a) your business is Meta-verified (green tick or business-verified status) (b) the new BSP's Business Manager ID is shared with you in writing (c) two-factor authentication is set up on your Meta admin account (d) the transfer is scheduled in a low-traffic window (Tuesday 2am IST is a good default). Initiate the transfer, monitor Meta Business Manager every 4 hours, and have rollback plans ready.

### 4.2 Re-submit every approved template to the new BSP
- **Why it matters:** Templates do not transfer automatically. Each template must be re-submitted on the new BSP and re-approved by Meta. Approval typically takes 24 hours per template but can stretch to 7 days for marketing templates with media.
- **Owner:** Ops manager
- **Time:** 1 to 2 weeks (parallel-able)
- **Tool:** Template JSON export from checkpoint 2.3, new BSP template creation interface
- **Action:** Submit templates in priority order: utility (OTP, order confirmations) first because they are highest-volume and lowest-approval-risk, then authentication, then marketing. Submit in batches of 10 to stay under Meta's daily quota. Track approval status daily. For any template rejection, fix the content and resubmit within 24 hours so you do not lose momentum.

### 4.3 Update every webhook URL pointing to the old BSP
- **Why it matters:** Your application receives delivery receipts, inbound messages, and status updates via webhooks. If even one webhook still points at the old BSP after cut-over, you will lose those events forever.
- **Owner:** CTO
- **Time:** 2 hours
- **Tool:** Webhook inventory from checkpoint 1.6, new BSP webhook configuration
- **Action:** Configure the new BSP with your application's webhook endpoint (with HMAC signature verification — do not skip this). Update DNS or load-balancer rules if the webhook hits a dedicated subdomain. Test with a manual webhook ping from the new BSP before cut-over. Keep the old BSP's webhook firing in parallel for 48 hours post-cut-over so you can compare event streams.

### 4.4 Generate new API keys with least-privilege scope
- **Why it matters:** Rotating API keys at the BSP boundary is also a chance to fix the over-privileged "admin" keys you have been using since 2022. Least-privilege scoping limits blast radius if a key leaks.
- **Owner:** CTO + Security
- **Time:** 1 hour
- **Tool:** New BSP API key management interface, your secret manager (AWS Secrets Manager, Vault, etc.)
- **Action:** Create separate API keys per integration: one for the application (full send+receive), one for the CRM (contact sync only), one for the analytics pipeline (read-only). Store each key in your secret manager with rotation policy set to 90 days. Never commit keys to git. Never share keys via email or Slack.

### 4.5 Update CRM integration to point at new BSP
- **Why it matters:** Your CRM likely auto-creates contacts, pushes opt-in events, and reads conversation history from the BSP. Pointing it at the new BSP is straightforward in theory but every CRM has a quirk (Salesforce custom objects, HubSpot timeline events, Zoho workflows) that needs testing.
- **Owner:** CTO + CRM admin
- **Time:** 1 day
- **Tool:** New BSP CRM connector, CRM sandbox or test tenant
- **Action:** Test the new BSP→CRM integration in a sandbox first. Verify: contact creation, contact update, conversation log sync, custom-field mapping, opt-in event firing, and bidirectional sync if applicable. Only flip production once sandbox is clean. Keep the old BSP→CRM integration disabled but not deleted for 7 days as a fallback.

### 4.6 Train every agent on the new BSP inbox UI
- **Why it matters:** A 12-agent support team that does not know where the "transfer to human" button is on the new BSP will visibly degrade your CSAT for 2 weeks post-switch. Training is the cheapest insurance you will buy.
- **Owner:** Ops manager + Support team lead
- **Time:** 1 day (training) + 1 week (shadow period)
- **Tool:** New BSP agent training portal, your internal SOP document
- **Action:** Run a 2-hour live training session covering: inbox layout, canned responses, ticket assignment, template usage, escalation flow, and reporting. Record the session. Pair every agent with a buddy for the first 7 days. Track CSAT and average handle time daily — if either degrades by more than 15%, intervene with retraining.

### 4.7 Rebuild every automation flow on the new BSP
- **Why it matters:** Flows do not transfer between BSPs (the flow JSON format is proprietary to each platform). Rebuild is manual, and missed nodes cause customer-facing breakage — abandoned cart recoveries that never fire, OTP fallbacks that never trigger.
- **Owner:** Automation lead + Ops
- **Time:** 1 to 2 weeks (parallel-able with template re-approval)
- **Tool:** Flow inventory and screenshots from checkpoint 1.5, new BSP flow builder
- **Action:** Rebuild flows in priority order: transactional first (OTP, order confirmation, payment receipt), then service (support routing, FAQ), then marketing (abandoned cart, win-back, upsell). For each rebuilt flow, run a UAT script with at least 10 test contacts covering happy path + 3 edge cases. Document the test results.

### 4.8 Migrate or rebuild custom integrations
- **Why it matters:** That custom Lambda function piping leads from your landing page to the BSP, or the n8n workflow sending Stripe events as utility messages, are usually undocumented. They break silently on cut-over.
- **Owner:** Engineering lead
- **Time:** 1 to 4 days depending on integration count
- **Tool:** Integration inventory from checkpoint 1.6, your codebase, n8n/Make/Zapier accounts
- **Action:** For each custom integration: update the BSP endpoint URL and API key, update any phone-number-specific routing, retest the integration end-to-end with a real-data sample, and add monitoring/alerting (e.g. fire a Slack alert if the integration is silent for more than 1 hour during business hours).

### 4.9 Update IP allowlist on the new BSP
- **Why it matters:** Many enterprise BSPs allow you to restrict API access to specific IPs. If you skip this step and a key leaks, anyone on the internet can send WhatsApp messages from your number.
- **Owner:** CTO + Security
- **Time:** 30 min
- **Tool:** New BSP security settings, your cloud provider VPC IP ranges
- **Action:** List the egress IPs of every server, Lambda, or function that calls the BSP API. Add them to the BSP's IP allowlist. Add a "deny by default" rule. Test that a call from an IP outside the allowlist is rejected. Document the allowlist in your security runbook.

### 4.10 Validate DNS and any custom domain configuration
- **Why it matters:** If you use a custom domain for webhook receipt or BSP-hosted landing pages, DNS misconfiguration on cut-over day means dead links and lost messages.
- **Owner:** CTO + DevOps
- **Time:** 1 hour
- **Tool:** Your DNS provider (Route 53, Cloudflare, GoDaddy), your SSL certificate inventory
- **Action:** Verify every DNS record (A, CNAME, TXT) pointing at BSP-related infra. Update TTLs to 300 seconds 48 hours before cut-over so changes propagate fast. Confirm SSL certificates are valid and auto-renewing. Test with `dig` and `curl -v` from at least two geographic regions before cut-over.

---

## Section 5 · Compliance carry-over (6 points)

### 5.1 Migrate DPDP Section 6 consent records intact
- **Why it matters:** DPDP Act 2023 Section 6 requires that consent be free, specific, informed, unconditional, unambiguous, and capable of being withdrawn. The record of that consent must be portable to the new BSP without alteration — including the original timestamp and consent text.
- **Owner:** Legal + Ops + CTO
- **Time:** 2 days
- **Tool:** Consent export from checkpoint 2.2, new BSP consent ingestion API, DPDP gazette reference
- **Action:** Import consent records into the new BSP with original timestamps preserved (not "imported on" timestamps). Validate that the BSP stores the consent text verbatim and not a normalised version. For any contact whose consent record is incomplete or pre-DPDP-compliant, run a re-consent campaign or remove from messaging lists. Keep the master consent ledger in your CRM or a dedicated consent management platform, not in the BSP.

### 5.2 Carry over the opt-out and DND list
- **Why it matters:** Messaging a contact who has opted out is a DPDP violation, a TRAI DND violation, and a Meta policy violation — three regulators, one mistake. The opt-out list must transfer first and be honoured from message #1 on the new BSP.
- **Owner:** Ops + Legal
- **Time:** 4 hours
- **Tool:** Opt-out export from current BSP, TRAI DND scrub service, new BSP suppression list
- **Action:** Export every contact who has opted out, blocked your number, or filed a complaint. Import as a suppression list on the new BSP before any contacts are loaded. Cross-reference against TRAI DND registry. Set up an automated rule that any contact who replies "STOP" / "UNSUBSCRIBE" / "OPT OUT" is added to suppression immediately and an acknowledgement is sent within 24 hours.

### 5.3 Maintain DPDP audit-trail continuity
- **Why it matters:** Regulator audits ask for "show me the consent and all message activity for contact X from date Y to date Z". If your audit trail has a gap between old-BSP and new-BSP, that gap is evidence of non-compliance.
- **Owner:** Legal + CTO
- **Time:** 1 day
- **Tool:** Conversation export from checkpoint 2.4, new BSP audit log
- **Action:** Combine the old-BSP conversation log (last 90+ days exported) with the new-BSP log into a single canonical store (S3 + Glue catalog, or a log warehouse like Datadog). Index by phone number and timestamp. Ensure no gap between the last old-BSP message and the first new-BSP message. Document the merge methodology in your DPDP playbook.

### 5.4 Update IT Rules 2021 Grievance Officer contact details
- **Why it matters:** IT Rules 2021 require a Grievance Officer accessible via the messaging platform itself. If your old BSP hosted a grievance landing page or chatbot flow, the URL or flow ID changes on the new BSP and your published privacy notice goes stale.
- **Owner:** Legal + Compliance
- **Time:** 2 hours
- **Tool:** Your privacy notice, your IT Rules 2021 grievance page, your published Grievance Officer email
- **Action:** Update the privacy notice and grievance page with the new BSP-hosted flow URL or contact path. Confirm the Grievance Officer email is monitored and the SLA (15 days under IT Rules) is enforced. Re-test by filing a test grievance and tracking through to closure.

### 5.5 Update ASCI and sector-specific compliance flags
- **Why it matters:** Advertising Standards Council of India guidelines, plus sector regulators (IRDAI for insurance, RBI/NHA for fintech and health), require specific disclaimers on marketing messages. Your old BSP may have templated these into footers; your new BSP needs the same disclaimers added.
- **Owner:** Legal + Marketing
- **Time:** 1 day
- **Tool:** ASCI guidelines, your sector regulator handbook, new BSP template builder
- **Action:** For every marketing template, confirm the required disclaimer is in the footer (e.g. "Insurance is the subject matter of solicitation" for IRDAI, "Mutual fund investments are subject to market risks" for SEBI, "T&C apply" plus link for ASCI). Re-approve any template that was missing a disclaimer. Add a pre-flight check in your template-creation SOP.

### 5.6 Re-verify IRDAI / RBI / NHA approvals if applicable
- **Why it matters:** Regulated sectors often require sector-regulator approval of marketing channels and content. The approval may be tied to a specific BSP. Switching BSPs without re-notifying or re-approving can void the channel approval.
- **Owner:** Compliance / Legal
- **Time:** 1 to 3 weeks (regulator-dependent)
- **Tool:** Your sector regulator's communication-channel-approval process, your compliance archive
- **Action:** Notify your sector regulator of the BSP change in writing, attach the new BSP's compliance certifications (data localisation, ISO 27001, SOC 2), and request re-approval of the messaging channel. Do not begin marketing campaigns on the new BSP until written confirmation arrives. Service and transactional messages typically continue without re-approval, but verify this with your compliance team.

---

## Section 6 · Cut-over playbook (5 points)

### 6.1 Soft-launch with 1% of traffic
- **Why it matters:** Cut-over disasters compound in the first hour. A 1% canary lets you see delivery rate, Quality Score, and webhook integrity before risking the full volume.
- **Owner:** Ops manager + CTO
- **Time:** 1 day
- **Tool:** Your traffic-splitting logic (application-side flag or feature toggle service like LaunchDarkly)
- **Action:** Route 1% of outbound messages through the new BSP for 24 hours. Monitor: delivery rate, read rate, error codes, webhook receipt latency, and Meta Quality Score on the phone number. If any metric degrades by more than 10% versus the 90-day baseline from checkpoint 1.2, halt the rollout and investigate.

### 6.2 Validate delivery rates against baseline
- **Why it matters:** Delivery rate is the canary in the coal mine for everything that can go wrong — template formatting, opt-in mismatches, Quality Score drops, BSP routing errors. A 5% drop in delivery is a P1 incident.
- **Owner:** Ops manager
- **Time:** Continuous during cut-over week
- **Tool:** New BSP delivery dashboard, your application logs, baseline from checkpoint 1.2
- **Action:** Set up a real-time dashboard showing delivery rate per category (utility, marketing, auth) for the new BSP, with the 90-day baseline overlaid. Alert if delivery rate drops more than 3% for more than 30 minutes. During the first 7 days, review the dashboard hourly during business hours.

### 6.3 Validate webhook receipt integrity
- **Why it matters:** A webhook lost is a message status lost. If webhooks are missing, your application thinks messages failed when they delivered (or vice versa), corrupting analytics and billing reconciliation.
- **Owner:** CTO
- **Time:** Continuous during cut-over week
- **Tool:** Your webhook receipt log, new BSP's send log
- **Action:** Reconcile the new BSP's send log against your webhook receipt log daily for the first 7 days. Acceptable loss rate is 0% — anything above 0.1% is a configuration bug. Investigate every gap by message ID, fix the root cause, and document the fix.

### 6.4 Schedule the full cut-over window
- **Why it matters:** A scheduled cut-over with stakeholder sign-off and a war-room is calm. An unscheduled cut-over driven by old-BSP cancellation date is chaotic and expensive.
- **Owner:** Ops manager + CTO + Founder
- **Time:** 4 hours active cut-over + 24 hours hot-standby
- **Tool:** Your status page, your war-room channel (Slack/Discord), your communication-tree to customers if applicable
- **Action:** Pick a low-traffic window (avoid Mondays, avoid month-end, avoid Diwali/festival weekends). Pre-stage every change. Have the founder, CTO, ops lead, and BSP support contact in the war room. Execute in the documented sequence. Update a public status page. Communicate completion to internal stakeholders within 30 minutes of cut-over.

### 6.5 Run 7-day shadow-mode on the old BSP
- **Why it matters:** A 7-day shadow window where the old BSP is paid-for but unused (or used only for inbound) gives you a free safety net. If the new BSP has a hidden issue, you can fail back without contract chaos.
- **Owner:** Ops manager + Finance
- **Time:** 7 days of overlap billing
- **Tool:** Old BSP contract (note exact termination date), new BSP confirmation
- **Action:** Negotiate the old BSP termination to be 7 days after the cut-over date, not on cut-over day. Keep API access alive on the old BSP. If a P1 incident on the new BSP cannot be resolved within 2 hours, flip traffic back to the old BSP via the same feature flag from checkpoint 6.1. Document any failback and root-cause it before retrying.

---

## Section 7 · Post-switch optimization (4 points)

### 7.1 Rebuild Meta Quality Score deliberately
- **Why it matters:** Quality Score is per phone number and persists across BSPs, but cut-over disturbances (bad opt-in lists, rushed templates, agent confusion) can briefly degrade it. Active rebuilding gets you back to High within 14 days.
- **Owner:** Ops manager
- **Time:** 2 weeks
- **Tool:** Meta Business Manager → WhatsApp Manager → Quality Rating dashboard
- **Action:** For the first 14 days post-switch, ramp marketing volume slowly (start at 50% of pre-switch baseline, add 10% per day). Send high-engagement utility messages (OTPs, order updates) at normal volume. Monitor the Quality Rating dashboard daily. If rating drops to Medium, pause marketing for 48 hours and review the last 1000 messages for opt-out spikes.

### 7.2 Plan and execute messaging tier ramp-up
- **Why it matters:** Meta's messaging tier (1k → 10k → 100k → unlimited) is reset only if Quality Score drops to Low. Most teams forget to actively work the tier ramp and stay throttled below their actual capacity for months.
- **Owner:** Ops manager
- **Time:** 4 to 8 weeks (Meta-controlled)
- **Tool:** Meta Business Manager → WhatsApp Manager → Phone Numbers → Messaging Limits
- **Action:** Check the current messaging tier weekly. To progress to the next tier, Meta requires that you send to the maximum of your current tier consistently while maintaining High Quality. Plan campaigns to deliberately reach (but not exceed) the current tier maximum for 7 consecutive days. Track tier progression and forecast when you will reach unlimited.

### 7.3 Reconcile billing between old and new BSP
- **Why it matters:** Switch month invoices are messy: partial-month from old BSP, partial-month from new BSP, possible double-billing on overlapping days, GST input credit adjustments. Skip this and finance will be chasing reconciliations for 3 months.
- **Owner:** Finance + Ops
- **Time:** 1 day
- **Tool:** Old BSP final invoice, new BSP first invoice, your 90-day volume baseline
- **Action:** Reconcile the old BSP's final invoice against actual usage for the partial month. Verify any pro-rated refunds. Check the new BSP's first invoice for accuracy on Meta pass-through line items. Compare the all-in cost per message against the 90-day baseline — if the savings do not match the pre-switch projection, raise it with the new BSP within 30 days.

### 7.4 Schedule a 30-day founder check-in with the new BSP
- **Why it matters:** The honeymoon is over at day 30 and that is exactly when small issues compound. A scheduled founder check-in surfaces problems while goodwill is still high.
- **Owner:** Founder / CEO
- **Time:** 1 hour
- **Tool:** Calendar invite, a written agenda
- **Action:** Schedule a 60-minute call with the new BSP's founder or VP 30 days post-switch. Agenda: actual delivery rates vs SLA, support ticket count and resolution times, billing accuracy, integration stability, roadmap requests, and any escalations. Take notes. Schedule a 90-day follow-up. This relationship is what you are paying the premium for at the enterprise tier — use it.

---

## Common switch mistakes (5 horror stories anonymised)

**The 14-day Meta lock**: A Mumbai D2C beauty brand initiated a Friday-evening phone-number transfer to save costs. Meta's review queue stretched across a long weekend plus a Monday holiday. The transfer landed on day 14, during which the brand could not send a single marketing message. Diwali week revenue fell by an estimated ₹38 lakh. Lesson: never initiate transfers before festivals or long weekends, and confirm Meta business-verification status before scheduling.

**The undocumented Lambda**: A Bengaluru fintech finished a "clean" migration only to discover three days later that customer KYC OTPs were silently failing. A four-year-old AWS Lambda function was still pointing at the old BSP's API endpoint. Nobody on the current engineering team had built it; the original engineer had left in 2023. Lesson: do checkpoint 1.6 with paranoid thoroughness, and grep your entire codebase for the old BSP's API domain before cut-over.

**The consent gap**: A Delhi insurance aggregator switched BSPs and ran their first marketing campaign on day 7. They got two DPDP complaints in 48 hours. The cause: their old BSP had stored consent records with timestamps but no consent text verbatim, and the new BSP could not produce a regulator-acceptable audit trail. The campaign was paused, lawyers were called, and the company spent ₹14 lakh on a CMP (Consent Management Platform) implementation that should have been built in 2024. Lesson: checkpoint 2.2 and 5.1 are not optional.

**The Quality Score crash**: A Pune SaaS company rushed template re-approval to hit a quarterly campaign deadline, submitted 47 templates in one day, and pushed marketing volume to 100% of pre-switch baseline on day 1. Quality Score dropped from High to Low in 36 hours. The messaging tier dropped from 100k to 1k. Recovery took 5 weeks. Lesson: ramp deliberately. Checkpoint 7.1 exists for a reason.

**The auto-renewal trap**: A Chennai e-commerce brand thought they had cancelled their old BSP on day 60 of a 12-month contract. The cancellation email went to a generic support address; the contract required registered post or a notice via a specific portal. The contract auto-renewed for another 12 months. The brand paid out the second year while running on the new BSP. Lesson: checkpoint 1.8. Read the contract. Send notice in the exact format the contract requires. Get written acknowledgement of cancellation.

---

## Estimated total switch time

- **Light D2C (under 10,000 messages/month):** 2 weeks end-to-end. Phone-number transfer is the long pole. Template count is low (typically under 20) so re-approval is fast.
- **Mid D2C (10,000 to 50,000 messages/month):** 4 weeks end-to-end. Template count is 20 to 80, flow count is 5 to 15, and CRM/e-commerce integrations need genuine testing. Plan one full week for template re-approval and one for flow rebuild.
- **Enterprise (50,000+ messages/month):** 6 to 8 weeks end-to-end. Multi-stakeholder sign-off, regulator notifications (BFSI/insurance/health), 100+ templates, 20+ flows, multiple integrations, and a deliberate Quality Score ramp dominate the timeline. Budget for a dedicated migration owner at 50% time for the full window.

---

## Why RichAutomate

We built RichAutomate after running the migration above for ourselves and watching the same five mistakes repeat across our network. Our platform is Meta-pass-through-transparent (you see Meta's rate and our margin as separate line items on every invoice), India-hosted (AWS Mumbai primary, Hyderabad failover), DPDP-audit-trail-native (consent records with verbatim text and 7-year retention by default), and founder-accessible (the engineering and ops founders are reachable on WhatsApp for every paying account). We are also one of the few BSPs in India with a 30-day no-questions exit clause in our standard MSA — because we believe a customer who stays only because of a lock-in is not really a customer. If you have run through this checklist and the answer keeps pointing back to "we need a transparent, India-first, founder-led BSP", we would like the conversation.

---

## Free audit

- **24-hour founder-led BSP audit:** [richautomate.in/audit](https://richautomate.in/audit) — we read your current BSP invoice, your template library, and your DPDP setup, and tell you in writing whether switching is worth it. No sales call required.
- **Lifetime ₹0 platform fee (first 50 seats):** [richautomate.in/apply/first-50](https://richautomate.in/apply/first-50) — we are seating our first 50 enterprise accounts at zero platform fee for life, Meta pass-through at cost. Application-based, closing once filled.

---

*Document version: 1.0 · India 2026 · Last reviewed: 2026-05-23*
*This checklist is provided as practical guidance, not legal advice. Verify DPDP, IT Rules, IRDAI, RBI, and sector-specific obligations with qualified counsel before acting.*