Contracts are written before anyone has really looked at the environment.

Contracts are written before anyone has really looked at the environment. That is not a criticism. It is just how the sequence works. You scope based on what the customer knows, what they can share in a pre-sales conversation, and what discovery has surfaced so far. Then you get into the actual forest, the actual tenant, the actual data, and things look different. I have been on migrations where the contract said one domain and the environment had three. Where mailbox counts were accurate but shared mailboxes and resource accounts were not in scope anywhere on paper. Where the timeline assumed a clean hybrid configuration that turned out to be anything but. The contract does not manage those moments. The PM does. What I have found is that the earlier you name the gap, the better. Not to trigger a change order fight, but because the customer's team is usually not surprised. They knew about the third domain. They were not sure it mattered. Getting it on the table early means you are solving it together instead of explaining it at go-live. The document you signed describes the project you planned. The runbook you build describes the project you actually have. The PM's job is to close that distance without losing the customer's trust in the process. That means being willing to reset expectations before they calcify, revisiting timeline and scope assumptions out loud, and making sure the customer understands what the project actually looks like now, not what it looked like when the contract was signed. Managed well, that conversation builds more confidence than it costs. Most of the time, it starts with one honest conversation before it becomes a problem.