I apologize for not having more information than that, but you are correct. I'm looking for a very high level idea of what it would take to migrate an environment from one child domain to another in the same forest. Below is my initial idea which may or may not be totally off base
1. Establish the new domain
2. Establish two way trust
3. Move SQL to the new domain and ensure that ePO1 is still communicating with it.
4. Install ePO2 on new domain (new server)
5. Point ePO2 at the same database and configure ePO1 and ePO2 to run in tandem (shared database, 2way server trust)
6. As endpoints change domains, assign ePO2 as primary server until all endpoints are converted.
This is completely hypothetical but I'm curious if its even possible. I guess my concern lies in where any/all domain information is stored and if ePO will willingly let this information be changed or if this would require a completely new install with a complete client transfer.
ePO on its own is domain agnostic. It's not tied to the underlying domain that manage the OS that the application is installed on. I know customers that deploy ePO in a workgroup and I know customers that maintain a separate domain for all security infrastructure.
As far as domain information is concerned, each domain is configured as a Registered Server at the application level. As long as the ePO server itself is able to communicate to the domain controllers in each domain, you should be okay. Your endpoints can be in different domains / workgroups, and ePO won't care. The only exception is Drive Encryption which does require that connectivity to the domain of the system be available so that user assignments can occur.
You can't share a database between two epo servers. You can share a sql server. Best is to build the second servers with a second database and use the built in functionality in ePO to transfer system/policies/ task in between servers. We have 4 domains connected