Deployment dependency and migration order
Key Takeaway
Include every interdependent component that doesn't already exist in the target org, and deploy in the recommended order, with objects first and sharing rules last.
A deployment moves metadata, and sometimes configuration data, from a development environment such as a sandbox into another org such as production. Components depend on each other, so a deployment fails or behaves unexpectedly when something a component needs is missing from both the deployment and the target org. You prevent those failures by planning which dependencies to include and the order to deploy them in.
Dependencies and what a change set must contain
A component depends on another component when it refers to it.
For example, imagine an Apex trigger that references a custom field. The trigger depends on that field. If you deploy the trigger and the field is missing from both the target org and the change set, the deployment fails.
So each outbound change set must contain every interdependent component that doesn't already exist in the target org. You can leave a dependent component out only when it already exists in every org where the change set will be deployed.