Our parent company has just completed an acquisition of a similarly sized firm, and we are now tasked with merging two separate Drata instances into one. Both companies have been using Drata independently for over a year, with fully configured frameworks, integrated systems, and established workflows.
From a technical standpoint, I foresee several key challenges:
* **Policy and Control Duplication:** Both instances have their own versions of SOC 2, ISO 27001, and other framework controls. Merging these without losing evidence or creating conflicts is a primary concern.
* **Evidence Collection & System Integrations:** Each instance is connected to a distinct set of data sources (GitHub, JIRA, AWS, etc.). We need to rationalize these integrations to avoid gaps or redundant data collection.
* **User Management & Access:** Consolidating user accounts and permissions from two different SSO configurations will be complex.
My initial thought is that a simple "export/import" will not suffice due to the relational nature of the data. I am considering two potential architectural approaches:
1. **Designate a Primary Instance:** Select one instance as the survivor, manually map and migrate the controls and evidence from the secondary instance, and then decommission the secondary.
2. **Fresh Start:** Create a completely new Drata instance and attempt to bulk-import curated control sets from both existing instances, effectively rebuilding from a merged list.
Has anyone executed a similar merger? I am particularly interested in:
* Practical steps taken and the order of operations.
* How you handled control ID collisions or naming conventions.
* Whether Drata Support provided any APIs or bulk operations tools to assist.
* The overall timeline and major pitfalls encountered.
I will be documenting our own process and will share throughput metrics (e.g., controls merged/week, evidence linkage success rate) and a high-level architecture diagram of the final merged state once we complete the project.