Each entity chooses its own Entity ID. When you are setting up a SP, you choose your Entity ID and the IdP(s) MUST be able to adapt to your choice. Similarily, an IdP decides its own Entity ID and all SPs MUST be able to adapt to it.
Entity IDs MUST be unique within a Circle of Trust (CoT). Given that CoT relationships may change from time to time, its best to choose Entity ID so that it is globally unique. If Entity ID contains a domain name as a component, then the globally unique property tends to be enforced by the domain name allocation system.
Entity ID SHOULD be the Well Known Location (WKL), i.e. the URL from which the metadata can be fetched.
Providing metadata by URL, ideally by the Entity ID, SHOULD always be enabled. This greatly facilitates configuration.
After you get an installation to work, be sure to review whether the default configuration is appropriate for production use
Decide whether you want to run open federation and disable it if needed.
Prune your Circle of Trust. List who you trust and delete the misfits.
Check validity time tolerances you accept. The defaults may be rather generous for production use.
Review that you did not turn off any signature validation just to get it to work. All signature validations are there for reason and you should not go to production if any of them fail.
Check permissions on private keys and think whether your private keys, including web server SSL one, are protected. Could they have been compromised during trial period?
Check that your public image is conveyed right in your metadata. Orgqanization name, contact URLs, logotype, etc. However, be forewarned that changing these on last minute changes your metadata and you may need to engage in an additional round of metadata exchanges when you go to production.
Make sure you have a solution in place to keep your audit trail in case you ever have to go to court. See zxid-log.pd for details. You may also want to think about encrypting or deleting some items after a while to reduce your liability for breaches.