Plan a connectivity migration from Gigs
Plan a migration around the customer’s working service. Preserve the information needed to understand existing commitments and establish what can move before asking a subscriber to change anything.
Prerequisites
Prepare authorized access to your Gigs project, a Bird workspace, the relevant commercial and support contacts, and a small evaluation cohort. Inventory active services and payment obligations. Confirm that the intended Bird offers meet each customer’s requirements.
1. Inventory the existing relationship
Map your customer identifier to the provider’s user, subscription, plan, SIM and porting records. Record the service’s current state and next renewal or expiry. Keep current payment arrangements and support history accessible to the teams that need them.
Treat an installation credential as a secret. It does not belong in an exported comparison spreadsheet or an agent prompt. Use references and authorized access for operational work.
2. Define the receiving service
Select the destination market, included services, allowance and commercial terms. Confirm device compatibility and whether a new profile installation is required. If a customer is keeping a mobile number, confirm the supported porting process and the information required from the donor service.
A similarly named plan is not an identical contract. Review coverage, speed policies, validity, renewal, cancellation and any remaining customer obligations before selecting the replacement.
3. Map behavior, not API names
Map plan discovery, purchase, fulfillment, installation, usage, top-ups and service changes to the documented Bird integration. Preserve the distinction between a customer request, its financial result and the resulting network service.
Use the Bird integration guide to map supported operations. Record unsupported requirements explicitly: the eSIM API does not transfer numbers or switch an active recurring subscription to another plan. Resolve those requirements before committing to a migration date.
4. Rehearse a controlled transition
Use an approved test customer and compatible device. Follow the receiving purchase, private installation and any required port. Verify the included data, incoming and outgoing calls, and messages separately.
Exercise interrupted installation, delayed observations and a recoverable request refusal. Verify what the subscriber sees and what the support team can do. Keep an existing order under investigation when its outcome is uncertain rather than creating another purchase.
5. Roll out with an exit plan
Invite a bounded cohort only after the migration path and customer instructions are verified. Monitor completion, support needs and the active financial relationships. Close the previous service according to its terms and only when the agreed transition permits it.
Record who can pause the rollout and how remaining customers keep service. A rollback may require a new service operation; changing an application setting cannot restore every profile or number transfer.
Troubleshooting
If a profile cannot move, use the agreed new-installation path. If a port is declined, follow the reported requirements and donor records. If usage is missing, inspect observation freshness separately from purchase and service state.
Provider references
Use the Gigs subscription guide, SIM guide and porting process to understand the source service.
Record the migration decision
Record the source-to-destination resource map, supported operations, unresolved requirements, and the customer group eligible for migration. Include the first-purchase, installation, cancellation, and failure-recovery checks from the rehearsal.
Confirm who approves live purchases, service cancellation, and customer communications before starting the transition. Keep the existing service available until the agreed continuity checks pass.
Next steps
Related resources
Continue with the documentation, guides and examples for this topic.