> For the complete documentation index, see [llms.txt](https://docs.trustlogix.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trustlogix.io/trust-access/data-access-governance/access-policy-migration-status-flow.md).
# Access Policy Migration Status Flow
### **Platform Support & Prerequisites**
* Supported Data Platforms: Policy migration is seamlessly supported for Snowflake and Databricks.
* Account Consistency: Source and target accounts must match in platform type (e.g., Snowflake-to-Snowflake).
* Environment & Tenant Flexibility: The source and target can reside within the same overarching account or span across different accounts (such as isolated Dev and Prod accounts). We also fully support cross-tenant policy migration.
* Database Mapping: The database name can be the same or different between the source and the target data source accounts.
* Policy State: Only deployed access policies are eligible for migration.
### Downloading the CI/CD Migration Script
To execute the policy migration, you will need the appropriate CI/CD utility script. Follow these steps to download it:
1. Login to the TrustLogix console.
2. Navigate to Configuration from the left-hand menu.
3. Click on the Utility Script card.
4. Download the Migrate Access Policy script.
### Migration Workflow: Lower to Higher Environment
To ensure a secure and consistent promotion of access controls, policies follow a strict path from lower to higher environments.
* Development & Testing: Access policies are designed, deployed, and validated within the Development (Dev) environment.
* Migration Trigger: The policy is promoted to the higher environment (Prod/UAT), preserving the exact conditions and constraints established in Dev.
* Immutability Guarantee: During migration, no changes are made to the original policy in the Dev environment.
### Flow Diagram
The following diagram illustrates the automated step-by-step logic applied during a policy migration.
### Status Flow (Migration Engine Process)
### Detailed Migration Execution Phases
| Status Phase | Platform Action | Customer View / Details
|
| --------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Verification | Policy Discovery | The migration platform scans the target environment to determine if a version of the migrating policy already exists. |
| 2. Resolution | Create or Update | If missing, a new policy is created. If present, the existing policy is updated with the new conditions and object selections from Dev. |
| 3. Validation | Condition Validation | The platform internally validates the updated policy conditions against the target account structure. The policy state transitions to Published. |
| 4. Execution | Automated Deployment | Our automated deployment engine (Trustlet) picks up the Published policy and natively executes the required statements in Snowflake or Databricks. |
| 5. Completion | Finalize Status | Upon successful execution, the policy's final status in the target environment is updated to Deployed, completing the migration. |
### Troubleshooting & Failure Handling
Handling Migration Failures: In the event of a deployment failure (e.g., due to missing permissions in the target environment), first apply the required permissions. Once resolved, downgrade the target policy version in the JSON configuration file and rerun the migration script.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.trustlogix.io/trust-access/data-access-governance/access-policy-migration-status-flow.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.