Migrate Your Agency and Sub-Accounts to Sparkforge Phone

By Sparkforge Support Team ·Last reviewed May 3, 2026

Switching to Sparkforge Phone removes the Twilio middle-layer for SMS and calls. Validate agency access, convert the agency, then migrate sub-accounts — bulk for US/Canada, one at a time for other countries with a Regulatory Bundle.

Sparkforge Phone is the native telephony layer. Migrating from Twilio (or another provider) to Sparkforge Phone removes the third-party integration so SMS and calls work directly inside the CRM.

Why Switch

With Sparkforge Phone, you skip the Twilio (or Plivo, etc.) account, the separate billing portal, and the integration glue. SMS and calls are native to the platform.

Migration Path

  1. Validate Sparkforge Phone access at the agency level.
  2. Convert the agency to Sparkforge Phone.
  3. Migrate sub-accounts — bulk for US/Canada, individually for international.

Step 1: Validate Sparkforge Phone Access

Go to Agency Settings → Phone System → Twilio. The Use Sparkforge Phone System modal should be available. Your card and bank may require 3D Secure verification on a small test charge before the system enables.

Step 2: Convert the Agency

  1. Click Switch to Sparkforge Phone System.
  2. Read the prompt and check I accept.
  3. Click Confirm.

Once confirmed, the agency runs on Sparkforge Phone. A2P registration does not migrate from Twilio — you will re-register and pay the $4.95 A2P fee even if A2P was already active in your old Twilio account.

From this point forward, every new sub-account is created on Sparkforge Phone automatically. Existing sub-accounts still need to be migrated manually.

Step 3: Migrate Sub-Accounts

A. Bulk Migrate US/Canada Sub-Accounts

  1. Click Switch all sub-accounts to Sparkforge Phone.
  2. Read the prompt and check I accept.
  3. Click Confirm.

All eligible sub-accounts move to processing. The old sub-account keeps working during the transition; Sparkforge auto-detects when each number lands and switches over. Allow 2-3 business days for completion. Bulk migrate can only be run once per agency.

B. Single US/Canada Sub-Account

Use the per-sub-account Switch to Sparkforge Phone button. Same flow, same 2-3 business day window.

C. Non-US/Canada Sub-Accounts

International sub-accounts require a Regulatory Bundle and Address SID in the destination before migration. Configure those first, then click Switch to Sparkforge Phone on the sub-account and confirm.

What to Verify After Migration

  • Re-register A2P brand and campaign on the new sub-account.
  • Confirm number forwarding, recordings, and whispers carried over.
  • Test inbound and outbound SMS and calls end-to-end.
  • Check workflows that reference phone numbers — some may need updating.
  • Reconcile billing — Twilio charges stop once numbers move; Sparkforge Phone charges start.

If Migration Stalls

If a sub-account is in processing for more than 2-3 business days, open a Sparkforge support ticket. Bulk and individual migrations both go through the same automated detection layer — most delays resolve themselves but the support team can force-progress stuck moves.

Frequently Asked Questions

Does A2P registration migrate from Twilio?
No. A2P does not transfer. You will re-register the brand and campaign and pay the $4.95 A2P fee in the new Sparkforge Phone setup.
How long does sub-account migration take?
2 to 3 business days for US and Canada sub-accounts. International sub-accounts depend on Regulatory Bundle approval times.
Can I run bulk migration more than once?
No. Bulk migrate-all-sub-accounts can be run only once per agency. Sub-accounts not migrated in the bulk run must be moved individually afterward.
What happens to my old Twilio sub-accounts during the move?
They continue to function normally until each number is detected as moved. The cutover is automatic and per-number, so there is no downtime in the transition window.
Do I need anything special for international sub-accounts?
Yes. Non-US/Canada sub-accounts require an approved Regulatory Bundle and Address SID configured in the destination before the migration will proceed.

Was this article helpful?