Customer-facing guide for importing a Permit-delivered migration data
package into an on-prem deployment: package request/verification, DB
backup, write-freeze, ordered table import (with the same-session
FK-disable form for api_key/pdp_config), post-import cleanup and
superuser grant, org-filtered verification against the manifest,
Keycloak email-linking for member access, and troubleshooting.

Import side only — the export is performed by Permit and delivered as a
secure download link; no internal tooling is referenced.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Critical: the SDK cutover snippet omitted the api_url override, so a
migrated app's management calls would silently keep writing to the old
Permit Cloud workspace; it also pointed pdp= at the platform domain
instead of an on-prem PDP deployment. Now shows both endpoints with a
do-not-skip caution and links PDP Deployment.

Over-disclosure removed:
- 41-table schema list replaced with a manifest-driven loop
  (manifest.import.tables_in_order / fk_disabled_tables — contract added
  to the export in the backend PR), so public docs carry no schema dump
  and can't drift per installer version
- avp_policy_store_id cleanup SQL (cloud-provider internals) moved to
  the package README; docs keep only the customer-relevant review bullets
- unilateral commitments softened: audit retention period, download-link
  expiry, "without code changes"/"automatically regain access" guarantees

Friendliness: "At a glance" orientation (phases, downtime window, done
criteria, Permit assistance), pg_restore rollback snippet, jq/tar/sha256
prerequisites, replica-count note before scale-down, FK-bypass scoping
caution, platform-wide superuser caution, dependency-order gloss, and
the standard Support footer.

Build: 0 bad links, 0 bad anchors.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

FK-graph verification against the schema found the documented ordered
import cannot work for all customers: v2_project <-> v2_policy_repo
reference each other (a genuine FK cycle, hit by any GitOps org), plus
two more order violations masked in the original validation by empty
tables. The import now runs as one FK-deferred transaction
(--single-transaction + ON_ERROR_STOP): all-or-nothing, safe because the
package is a single consistent snapshot, and simpler for customers -
any failure rolls back cleanly and the step is just rerun.

Troubleshooting updated accordingly (partial-import scenario no longer
exists; added a guard entry for packages predating manifest.import).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- Replace --single-transaction with explicit BEGIN/COMMIT: on psql <= 14 a
  client-side \COPY failure under --single-transaction COMMITs the
  already-loaded tables (rollback-on-client-error landed in psql 15),
  breaking the all-or-nothing promise; explicit BEGIN/COMMIT is atomic on
  every version (verified empirically on psql 14 and 16).
- Admonition: "turned off" not "deferred" (no DEFERRABLE semantics), and
  forward-reference the step-6 member cleanup as the one known exception
  to snapshot consistency.
- Step 8: log out/in only works after the step-9 restart.
- Step 9: per-deployment scale commands (one --replicas flag can't express
  three different counts).
- Troubleshooting: "prints no COPY lines" (psql still prints SET/BEGIN).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- api_url must not carry an /api suffix: on-prem routes only /v2/ through
  the frontend nginx to the backend (verified against the platform chart
  ingress and permit-backend APP_PREFIX); with /api every SDK management
  call lands on the SPA fallback and returns HTML (Zeev's finding)
- scale-down command uses the explicit deployment/<name> resource form
  with flags first (portable across kubectl versions; Copilot's finding)
- management.mdx backend health check: /api/v2/health -> /v2/healthy
  (the actual backend route; same /api routing hole as above)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Reframes the migrate-from-cloud guide so customers run the whole migration
themselves. Adds "Step 0: Export Your Data from Permit Cloud":

- generate an Organization API key (management access) in Settings -> API Keys
- call GET /v2/data-export with the Bearer token to download the package
- freeze-writes, version-alignment, and audit-log notes; 413 -> ask Permit to
  run the offline export for very large orgs

Reconciles the rest of the page with the self-service package (data/ +
manifest.json only): package-contents tree, policy-repo guidance (ask Permit
for the default repo clone), self-contained cloud-config cleanup (no package
README), prerequisites and filenames, and the "no COPY lines" troubleshooting.
The import steps (single-transaction FK-deferred) are unchanged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…guide

The customer migration page no longer mentions audit-log history export
(dropped the "not included / request from your account team" notes in Step 0
and in "What is not migrated"). The page is dedicated to the RDS data
migration: self-serve export via the API, then import into the customer's own
on-prem deployment.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Step 0 now documents the export as start -> poll -> download: POST
/v2/data-export to start, poll GET /v2/data-export/{task_id}, then download
from the short-lived presigned URL in result.download_url. Notes the link is
short-lived + secret, and the too-large case surfaces as a poll failure.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>