Section 09

Changing your organization

"Move the app to our new company account" sounds like an afternoon. On the leas side it is — the fleet moves in minutes. On Apple's and Google's side it is a formal transfer with real preconditions. Read this before you promise anyone a date.

Moving to a different Apple Developer team

Everything Apple-related is scoped to a team ID, so effectively nothing survives the move: certificates, provisioning profiles, the API key, and the registered bundle identifier are all team property.

Two genuinely different situations, and people conflate them constantly:

SituationWhat you actually do
Same team, new owner — the company is unchanged, the person holding the account is leaving. Transfer the Account Holder role in the developer account. The team ID and every app stay put. Nothing in leas changes. This is by far the easier path — prefer it whenever it is honestly available.
New team — a different legal entity now owns the app. Use App Transfer in App Store Connect. The app, its reviews, ratings, and TestFlight history move to the receiving team. Then rebuild all credentials from scratch under the new team.

The App Transfer checklist

Apple imposes real preconditions and adjusts them over time, so confirm the current list in App Store Connect before committing. Perennially true:

  • The receiving team must have accepted all current agreements and have its banking and tax details complete. A transfer will sit blocked on this indefinitely.
  • The app must be in a transferable state — generally already released, with nothing pending review.
  • Certain capabilities and entitlements block transfer outright. App Store Connect names the specific blocker, so start the transfer early enough to discover yours.
  • The bundle identifier moves with the app. You do not — and cannot — re-register it.

What to do in leas afterwards

  1. In the new team: create a distribution certificate (setup step 3) and a provisioning profile for the transferred bundle ID (step 4).
  2. In the new team's App Store Connect: create a new API key (step 5). Keys never transfer.
  3. Update ascApiKeyId, ascApiIssuerId, and ascAppId in leas.json — the issuer ID is different for every team, and the app ID changes too.
  4. Replace the three iOS secrets, then run a cloud build to confirm.
  5. Revoke the old team's credentials once a build has shipped from the new one.
Team ID is invisible in your config, but it is everywhere

leas reads the team ID out of the provisioning profile at build time rather than storing it, so there is no stale value to hunt down. Swap the profile and the new team ID follows automatically.

Moving to a different Google Play developer account

Structurally the same story with different paperwork. Play supports transferring an app between developer accounts, initiated from the source account and requiring identifying details from both sides.

  1. Start the transfer from the source account's Play Console and complete Google's verification.
  2. Once it lands, create a service account for the new organization and invite it in the new Play Console (setup step 7). Service accounts never transfer.
  3. Update serviceAccountKeyPath and, if the identifier changed, packageName in leas.json.
  4. Replace LEAS_PLAY_SERVICE_ACCOUNT_BASE64.
The one thing that must not change

The package name is permanent for the life of a listing. If a transfer forces a new package name, that is not a transfer — it is a new app, with no reviews, no ratings, no install base, and no update path for existing users. Establish this early; it changes the whole plan.

Moving the build fleet to a different GitHub organization

The easy one. The fleet holds no state beyond secrets.

gh repo create NEW_ORG/your-app --private --source=. --push

# re-upload every secret against the new repo
base64 -i credentials/ios/dist.p12 | gh secret set LEAS_IOS_DIST_CERT_BASE64 --repo NEW_ORG/your-app
# ...repeat for the rest

Workflows travel with the repository. Nothing in leas.json refers to the organization, so there is nothing else to change.

Running several apps? Set the secrets at organization level instead of per-repository and every app inherits them — one rotation, not eight.