Unmanaged packages versus change sets for metadata migration
Key Takeaway
Use a change set, not an unmanaged package, to move customizations from a sandbox to production.
Change sets and unmanaged packages both move customizations from one Salesforce org to another, but they are built for different jobs. A change set moves tested customizations between related orgs, such as from a sandbox to production. An unmanaged package is a one-time handoff of an app or open-source project that the receiving org is expected to customize.
What each one is built for
If you are moving customizations from a sandbox to production...
You should use a change set, because change sets are built for that path. You should not use an unmanaged package.
If you are distributing an open-source project to developers...
You should use an unmanaged package, because unmanaged packages are meant for wider distribution.
If you are making a one-time handoff of an app that needs customization after installation...
You should use an unmanaged package.
For example, imagine you create and test a new object in a sandbox. You can then send the object to your production org in a change set.