/Docs
IntroductionHow FeatureGate worksQuickstart
OrganisationsProjectsEnvironments
OverviewTypes and valuesConfigure across environmentsTargeting rulesPercentage rolloutsDesign evaluation contextLifecycle and intentTags and discovery
Choose an evaluation approachEvaluation credentialsNode.js SDKEvaluate over HTTPEvaluate in browsersSnapshots and configuration freshnessErrors and fallbacksTest flags locallyProduction integration checklist
Run a controlled rolloutKill switchesProject insightsActivity and audit historyReview and clean up flagsEnvironment readinessTroubleshooting and limits
Members, roles, and permissionsInvite and manage a teamOrganisation settings and operational defaultsProject lifecycle and transferPlans, billing, and team organisationsOrganisation closure and reactivationAccount settings and security
Management API overviewPreviewProvision flags through automationPreviewRotate runtime keys through automationPreviewAudit project changes through automationPreview
DocsAPI Reference

Administration/Project lifecycle and transfer

Get access
/Docs
Get access
  1. Docs
  2. Administration
  3. Project lifecycle and transfer

Project lifecycle and transfer

Rename, archive, restore, transfer, and permanently delete a project safely.

MarkdownFeedback
PreviousOrganisation settings and operational defaultsNextPlans, billing, and team organisations

On this page

Rename a projectArchive and restorePrepare a transferTransfer effectsVerify after transferPermanent deletionCommon problems

Project settings separate reversible identity and archive changes from owner-only transfer and permanent deletion.

Owners and admins can rename, archive, and restore. Transfer and permanent deletion require the organisation owner.

Rename a project

The display name and URL slug can change without changing internal project identity, flag keys, environment keys, or evaluation-key bindings.

The console URL changes when the slug changes. Update bookmarks, runbooks, and human-facing links. API automation should store durable IDs rather than parse console URLs.

Project slugs must use lowercase letters, numbers, and dashes. Reserved organisation navigation names are rejected.

Archive and restore

Archive removes a project from ordinary active views and blocks normal management work while preserving configuration and activity.

Use archive when work is paused, an application is retired, or deletion needs a reversible checkpoint. Archived-project discovery remains available from the organisation project list.

Restore before editing resources or resuming ordinary work. Review old credentials, defaults, and application ownership after a long archive period.

Archive does not clear values already held in a running SDK. It also does not remove guarded code from application repositories.

Prepare a transfer

The source actor must be owner and can transfer only to an organisation where they are owner or admin.

Before confirming:

  1. Review destination membership and roles.
  2. Review billing and plan boundaries.
  3. Compare operational defaults.
  4. Identify runtime, client, and management credentials.
  5. Notify automation owners.
  6. Record the ownership reason without sensitive data.

Do not use transfer to bypass role, plan, billing, or organisation lifecycle restrictions.

Transfer effects

If the destination uses the same slug, FeatureGate adds a numeric suffix. The internal project ID remains stable while the console URL changes.

Active runtime and client keys are rebound to the destination so evaluation can continue. Project-scoped management keys in the source are revoked because their authority cannot cross organisations.

Historical activity and API usage attribution remain with the source organisation. Source and destination both receive transfer events.

Runtime invalidation is published for active environments. Snapshot clients still need a successful refresh before they hold current state.

Verify after transfer

  • Open the project from the destination organisation.
  • Confirm the final slug and update saved links.
  • Verify production evaluation with a safe request.
  • Confirm snapshot refresh health.
  • Replace revoked source management automation.
  • Review destination roles and key rotation ownership.
  • Confirm source and destination activity events.

Permanent deletion

Only an owner can permanently delete a project, and the project must be archived first. Deletion is not the first step of application cleanup.

Before deletion:

  1. Remove guarded code and project integrations.
  2. Revoke or replace callers.
  3. Confirm acceptable defaults during shutdown.
  4. Archive and wait for operational verification.
  5. Retain records required by organisational policy.
  6. Confirm the exact archived project before deleting.

Running SDKs may retain their last snapshot until refresh, restart, or discard. Deletion cannot erase customer-process memory.

Common problems

  • Transfer is unavailable: confirm the actor is source owner and owner or admin at destination.
  • The slug changed: use the numeric-suffixed destination URL.
  • Automation returns 401: replace a revoked source management key.
  • An archived project cannot be edited: restore it first.
  • A deleted flag value remains locally: restart or refresh the customer process.

Related pages: Projects, Activity and audit history, and Evaluation credentials.