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.
For an agent-assisted integration, provide the approved source contracts and a redacted field map. Ask the coding agent to identify unsupported operations and ambiguous outcomes before implementing adapters. Do not let it infer a one-to-one mapping from resource names alone.
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
Start an agent-assisted assessment
Give your coding agent this prompt with the approved contracts and a redacted inventory. Keep credentials in the authorized tools, outside the prompt.
Code example
Assess a migration from Gigs to Bird eSIM for this application.
1. Discover the repository instructions and authorized read-only tools.
Read https://bird.com/docs/guides/esim/migrate/gigs.md and
https://bird.com/docs/guides/esim/api.md. Inspect the current Gigs
integration and the Bird contracts supplied for this evaluation.
2. Inventory customers, subscriptions, plans, SIM references, billing,
installation and porting behavior. Use redacted references. Do not
retrieve or print installation credentials, payment data or tokens.
3. Map each operation to a documented destination. Separate supported
operations from requirements that still need Bird confirmation.
Do not invent an API from a similarly named resource.
4. Propose the customer journey, compatibility checks, idempotent
purchase handling, delayed observations and recovery paths. Identify
service continuity and financial obligations for a bounded cohort.
5. Produce a reviewable integration plan, test cases and unresolved
questions. Stop for explicit approval before changing live accounts,
buying or activating service, moving numbers, cancelling subscriptions,
changing billing, or sending customer invitations.Next steps
- Review Bird vs Gigs.
- Prepare a Bird eSIM integration.
- Guide device installation.
- Plan mobile number porting.
Related resources
Continue with the documentation, guides and examples for this topic. Resources are in English.
Understand the conceptWhat is an eSIM?Explore the capabilityeSIMImplementation guideeSIM connectivity guide
Get an implementation brief