Use change sets to send customizations from one Salesforce org to another. For example, you can create and test a new object in a sandbox org, then send it to your production org using a change set. Change sets can only contain modifications you can make through the Setup menu. For example, you can’t use a change set to upload a list of contact records. Change sets contain information about the org. They don’t contain data, such as records.
Sending a change set between two orgs requires a deployment connection. Change sets can only be sent between orgs that are affiliated with a production org. For example, a production org and a sandbox, or two sandboxes created from the same org can send or receive
Because your two Org's are unrelated you cannot establish a connection between them. So you can now eliminate options A,B and C.
Unmanaged packages are typically used to distribute open-source projects or application templates to provide developers with the basic building blocks for an application. Once the components are installed from an unmanaged package, the components can be edited in the organization they are installed in. The developer who created and uploaded the unmanaged package has no control over the installed components, and can't change or upgrade them. Unmanaged packages should not be used to migrate components from a sandbox to production organization.
More about packages here
Option E: After you have created application components and tested them in your own development org, you usually want to migrate them to a different org. The second org is used for testing, staging, publication, or production use by end users.
Although each metadata component lives and runs in a particular org, the metadata files you work with in the Force.com IDE are portable from one org to another. Deploying is the process of pushing your local project files into a different Salesforce org than your project’s home org. The Force.com IDE provides the Deploy to Server wizard to guide you through the deployment process.