# Existing apps: keep the link, update the control flow

App11 creates an app directly and returns an app management key. New work
starts there. Your existing App10 or entity-owned app still works with its
current routes, credentials, resource versions, data, and link.

## Check support

```sh
curl -fsS https://jmpkit.com/api/versions
```

Read `current`, `currentGuide`, and `legacy`. `legacy.status: supported`
and `sunsetAt: null` mean **no retirement date is announced**. Legacy app
responses link to this guide and the version endpoint. Do not infer a
deadline from a kit filename or a newer version number.

A future breaking retirement requires a published replacement, migration
instructions, and at least three calendar months' notice. Follow the live
version response and app service notices. Do not delete a working app today.

## Add App11 control to an existing app

With the **current legacy owner's bearer**, use the existing app URL:

```sh
curl --fail-with-body -X POST "${APP_URL}api/app11/migrate" \
  -H "Authorization: Bearer $LEGACY_OWNER_BEARER" \
  -H 'Content-Type: application/json' \
  -d '{"confirmAppId":"your-existing-app-id"}'
```

Save the returned `managementKey` privately before changing clients.
The app ID, URL, aliases, domains, and resource mappings stay the same.
Omitted expiration means **no scheduled expiration**; existing apps do not
unexpectedly acquire a 30-day deadline. You may explicitly supply `expiresIn`
or `expiresAt` when wanted.

Verify inspection, a non-destructive resource read, and an update using the
new key. Use the returned app-local control URL. Resource route versions
(`q10`, `p10`, `machine10`, etc.) do not change with App11 control.

Original entity-owner access remains valid. Rotating App11 keys revokes
App11 keys, **not the legacy owner's bearer**. This enrollment does not
detach the old owner or grant exclusive app-key authority. If legacy
ownership transfers later, the previous owner's App11 keys stop working.
The new owner may migrate again; capacity and publication history remain,
not a second starter grant. Transfer does not clear an existing expiration
or retirement. Remigration without a lifetime override preserves the chosen
deadline; an expired app still needs explicit renewal. Retirement stays final.

## Cleanup is a separate decision

- Keep old credentials until remaining apps, billing, grants, and resources
  have been reviewed. Other things may still depend on that entity.
- Do not delete an entity simply because one app gained a key. Migration
  does not implement entity deletion or legacy-owner detachment.
- Export needed data before explicitly retiring an unwanted app. Retirement
  stops service; it does not claim to erase stored data.
- Expiration can be renewed; retirement cannot. Do not substitute one for
  the other without the user's intent.

Historical immutable starter ZIPs and HTTP trees remain for their matching
contracts. Use the [catalog](/docs/kits/catalog.json) for current selection;
do not reinterpret old artifacts.

[Current app control](/docs/app11.md) · [Lifecycle](/docs/app-lifecycle.md)