# 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

Use the [Gigs subscription guide](https://developers.gigs.com/docs/create-a-subscription), [SIM guide](https://developers.gigs.com/docs/core/sims) and [porting process](https://developers.gigs.com/docs/porting/how-porting-in-works) to understand the source service.

## 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.

```text
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](/products/esim/compare/bird-vs-gigs).
- [Prepare a Bird eSIM integration](/docs/guides/esim/api).
- [Guide device installation](/docs/guides/esim/installation).
- [Plan mobile number porting](/docs/guides/esim/number-porting).

## Related resources

- [What is an eSIM?](/explained/esim/what-is-an-esim) (answer)
- [eSIM](/products/esim) (product)
- [eSIM connectivity guide](/docs/guides/esim/overview) (docs)

[Get an implementation brief](/learn/workspace?topic=esim)