Hey folks,
I’m working on a disaster recovery setup for our Genesys Cloud org. We want to keep a copy of our entire configuration in Terraform state, just in case we need to rebuild everything quickly. It’s a standard WFM use case for us, but the scale is tricky.
I’ve been using the genesyscloud provider to import resources. I wrote a simple script to dump the current state to a file:
terraform import genesyscloud_user.user_001 12345678-1234-1234-1234-123456789abc
This works fine for single resources. But we have thousands of users, skills, and wrap-up codes. Doing this one by one is impossible. I tried using the genesyscloud-terraform CLI tool to export everything at once:
genesyscloud-terraform export --output ./dr-config
The export finishes, but when I try to terraform plan on that config, it shows massive drift. It wants to delete and recreate almost everything. The state file is huge, and the plan output is unreadable.
I suspect the issue is with how references are handled. For example, a user’s division is referenced by ID, but the division resource might be named differently in the exported config. Or maybe it’s the way skills are mapped. I don’t know how to fix the references automatically.
Has anyone successfully exported a full org for DR? Is there a way to clean up the exported config before planning? I’m stuck on this step. The current approach just gives me a mountain of changes that I can’t verify. It feels like the tool isn’t designed for this scale, but I’m sure I’m missing something. Any help would be appreciated.
State drift in large Genesys Cloud orgs is usually a symptom of importing resources without understanding the dependency graph. If you just dump the state, you’ll run into race conditions when Terraform tries to update parent and child resources simultaneously. The genesyscloud provider handles some of this, but manual imports often miss implicit dependencies.
Here is a safer pattern for exporting state while preserving structure. Instead of a raw dump, use the provider’s genesyscloud_tfc resource or the CLI export tool which respects parent-child relationships.
# Example: Using the import command with explicit dependencies
# First, import the parent (e.g., a routing queue)
terraform import genesyscloud_routing_queue.main_queue <queue_id>
# Then, import child resources explicitly linked to it
terraform import genesyscloud_routing_queue_member.main_member <member_id>
If you are dealing with a massive org, consider using the genesyscloud_tfexport command-line tool provided by Genesys. It generates the Terraform code and state file in a structured way, handling the nested resources like routing skills, users, and wrap-up codes correctly.
genesyscloud tfexport export \
--client-id=${GENESYS_CLOUD_CLIENT_ID} \
--client-secret=${GENESYS_CLOUD_CLIENT_SECRET} \
--output-dir=./terraform-output \
--resources=queue,user,routing_skill
This approach minimizes drift because the generated code matches the actual API structure. You still need to review the output for any custom configurations that might not export cleanly, but it’s far more reliable than a manual import script. Monitor the state file size too, as it can grow quickly with large orgs. Splitting the state into multiple backend files by resource type can help manage performance.