When migrating to a new environment using Terraform, you're right that the policy schema (resources, roles, actions) will be created, but the runtime data (users, role assignments, resource instances) won't be included since Terraform manages the schema, not the data (1) . For handling the directory data (users, role assignments, resource ownerships) , you have a few options: 1. ​*Use Permit's SDK to sync the data*​ - The Mesa Verde example shows how to programmatically sync users and role assignments (2) :

// Add User to Tenant  
await permit.api.syncUser({  
 key: email,  
 email,  
}) ;

For role assignments at the tenant level :

await permit.api.assignRole({  
 role: "AccountOwner",  
 tenant: cleanedEmail,  
 user: email,  
}) ;

For resource-specific role assignments :

await permit.api.roleAssignments.assign({  
 role: "Sender",  
 tenant,  
 resource_instance: `Transaction:${transaction.id}`,  
 user,  
}) ;

2. ​*Export and import data via API*​ - You could write a script to export all current users, tenants, and role assignments from your production environment using Permit's API, then re-import them into the new environment. 3. ​*Blue-green deployment approach*​ - As suggested in the thread, you could gradually set up the new environment, test it with a PDP connected to it, then switch your production PDP to the new environment via DNS or load-balancer configuration once verified. The Terraform provider focuses on managing the authorization schema (resources, roles, permissions) as infrastructure code (1) , while the runtime data should be managed through your application's normal data flow using the SDKs (2) .

The

env copy

feature allows you to copy or merge environments, which is useful for managing policy changes in a controlled manner (1) . You can copy environments into new environments or existing environments . How it works When copying environments, only ​*Policy*​ objects are copied (Resources, Roles, Condition Sets) . ​*Directory*​ objects like Users, Tenants, and Resource Instances are NOT copied . API Usage You can copy an environment using the API :

curl --location '<https://api.permit.io/v2/projects/{project_id}/envs/{env_id}/copy>' \  
 -H 'authorization: Bearer API_SECRET_KEY' \  
 --data '{  
 "target_env": {  
 "new": {  
 "key": "prod",  
 "name": "production"  
 }  
 }'

CLI Usage The CLI provides the

permit env copy

command (2) :

$ permit env copy --api-key permit_key --from staging --to production --conflict-strategy overwrite

Conflict Strategy When merging into an existing environment, you can handle conflicts with (1) : • ​*fail*​ (default) : Rollback the entire merge operation • ​*overwrite*​: Overwrite the existing object in the target environment Scope Control You can include/exclude specific objects when copying :

curl --location '<https://api.permit.io/v2/projects/{project_id}/envs/{env_id}/copy>' \  
 -H 'authorization: Bearer API_SECRET_KEY'\  
 --data '{  
 "target_env": {  
 "new": {  
 "key": "prod",  
 "name": "production"  
 }  
 },  
 "scope": {  
 "roles": {  
 "exclude": ["*"]  
 },  
 "resources": {  
 "include": ["folder", "file"]  
 },  
 "resource_sets": {  
 "exclude": ["test*"]  
 },  
 "user_sets": {  
 "exclude": ["canada_users"]  
 },  
 "custom_policies": {  
 "include": ["*.rego"]  
 }  
 }  
}'

Background API for Large Environments For large environments, you can use the async endpoint :

curl --location '<https://api.permit.io/v2/projects/default/envs/staging/copy/async>' \  
 -H 'authorization: Bearer API_SECRET_KEY' \  
 --data '{  
 "target_env": {  
 "new": {  
 "key": "prod",  
 "name": "production"  
 }  
 }'

This is particularly useful for your migration scenario - you can copy your production policy schema to a new environment, then handle the directory data separately as discussed earlier.

To learn more, see the sources I considered: [[1] Create a new Environment](https://docs.permit.io/manage-your-account/creating-environments) [[2] Environments management using the Permit CLI](https://docs.permit.io/how-to/permit-cli/permit-cli-envs)