From Developer to Enterprise will be fine, just be sure that if you are using processor licensing you have licenses on the target server to cover all of the CPUs. And it's not enough to just hide them from SQL, if they're physically connected to the machine, you're responsible for them.
Also when you go from a lower build to a higher build your database version will increase. There are a few scenarios where this can be problematic - e.g. if you are using 15,000 partition support on a specific build of 2008 it will not work when you upgrade to a specific build of 2008 R2. You may also be relying on optimizations (and have workarounds in place) that are actually bugs in an older build but are fixed in the new build, and this may lead to worse performance. It is also vital to review any trace flags in use at the source and determine if they should also be enabled at the destination. Never mind jobs, logins, etc.
Of course you cannot go backwards. I've never tried a minor downgrade like 10.0.5512 -> 10.0.5500 but it is definitely not possible to go down in service pack or version. So if you have a 2012 database on your Developer Edition instance and you want to put it on your 2008 instance in production, you'll have your work cut out for you (see here and here) - especially if you've used 2012 features.
But to cover other cases that might land people at this question (e.g. someone wants to go from Developer -> Standard or Enterprise -> Express or what have you)...
There are other edition -> edition upgrades that won't go so well, e.g. from Developer -> Express if you've used any features that aren't supported in Express (and same goes for any edition other than Enterprise really). Some examples of features you won't be able to use on down-level editions (in which case the restore will die at the point it tries to bring the database online):
- Partitioning
- Change Data Capture
- Data Compression
- Transparent Data Encryption
I don't know if there's a way to tell this directly from the .BAK file (I'm sure there's some magic that can be extracted from page headers somewhere, or if you've got a weekend to burn with a hex editor), but while the database is still intact on the source instance, you can always do the following to see if you're using any features that are available because of the SKU you're in:
SELECT feature_name FROM sys.dm_db_persisted_sku_features;
I'm not sure if SQL Server Audit should be on that list - the edition exclusivity of that feature has changed, so it probably depends on what you're doing with it. There are other things that you might be using but won't show up in the DMV (some because they are in your code, which the DMV doesn't parse, and some because your database is relying on external things such as SQL Server Agent, Service Broker, etc.):
- mirroring
- certain forms of replication
- log shipping
- database snapshots
- online indexing
- updateable distributed partitioned views
- backup compression
- policy-based management
- plan guides
- database mail
- maintenance plans
- full-text search
There are also cases where you won't be able to go from Developer to Express because of file size limitations (Express databases are limited to 10GB in total data file size).
Of course there may be other gotchas that you won't be warned about - they won't prevent the migration, but they might lead to very different performance on the target. Examples:
- Different memory / CPU limitations on the target edition (or even the underlying operating system on the target). This bit a lot of people who went from 2008 R2 Enterprise to 2012 Enterprise (CAL), where the service is artificially limited to the first 20 cores). This can lead to straightforward performance differences (not enough memory to satisfy a query, for example, or much slower parallel query performance); more subtle ones include plan choices that are made because of the different underlying hardware.
- Reliance on features such as indexed view matching on the source will not be automatically respected on the target without changing source code to use
NOEXPAND. And you may not even be aware that this capability is why your queries suddenly slow down.
- Same goes for parallel index operations and probably a slew of other optimizations that aren't coming to mind this moment (thankfully I work almost exclusively in the Enterprise space, so I don't have to worry about the limitations of lower editions in most cases).
