DeveloperからEnterpriseまでは問題ありませんが、プロセッサライセンスを使用している場合は、ターゲットサーバーにすべてのCPUをカバーするライセンスがあることを確認してください。そして、それらをSQLから単に隠すだけでは十分ではありません。それらがマシンに物理的に接続されている場合は、あなたが責任を負います。
また、下位のビルドから上位のビルドに移行すると、データベースのバージョンが増加します。これが問題になる可能性のあるシナリオがいくつかあります。たとえば、2008の特定のビルドで15,000のパーティションサポートを使用している場合、2008 R2の特定のビルドにアップグレードすると機能しません。また、実際には古いビルドのバグであるが、新しいビルドでは修正されている最適化に依存している（そして回避策が講じられている）場合もあり、これによりパフォーマンスが低下する可能性があります。また、ソースで使用中のトレースフラグを確認し、宛先でも有効にする必要があるかどうかを判断することも重要です。ジョブ、ログインなどを気にしないでください
もちろん後戻りはできません。10.0.5512-> 10.0.5500のようなマイナーダウングレードを試したことはありませんが、サービスパックまたはバージョンでダウンすることは絶対に不可能です。したがって、Developer Editionインスタンスに2012データベースがあり、本番環境の2008インスタンスに配置したい場合、特に2012の機能を使用している場合は、作業が省略されます（こことここを参照）。 。
しかし、この質問に人々を導くかもしれない他のケースをカバーするために（例えば誰かが開発者->標準またはエンタープライズ->エクスプレスまたはあなたが持っているものから行きたいと思っています）...
他のエディション->エディションのアップグレードがうまくいかない場合があります。たとえば、Expressでサポートされていない機能を使用している場合は、Developer-> Expressからアップグレードします（Enterprise以外のエディションでも同じです）。下位レベルのエディションでは使用できない機能の例（この場合、データベースをオンラインにしようとした時点で復元は停止します）：
- パーティショニング
- 変更データキャプチャ
- データ圧縮
- 透過的なデータ暗号化
これを.BAKファイルから直接伝える方法があるかどうかはわかりません（ページヘッダーからどこかに抽出できる魔法があるか、または16進エディターで書き込む週末があるかどうかはわかりません） 、ただし、データベースはまだソースインスタンスに影響を与えていませんが、SKUが原因で使用可能な機能を使用しているかどうかを確認するには、いつでも次の操作を実行できます。
SELECT feature_name FROM sys.dm_db_persisted_sku_features;
SQL Server Auditがそのリストに含まれるべきかどうかはわかりません。その機能のエディションの独占性が変更されたため、おそらくそれをどのように使用しているかによって異なります。他にも使用している可能性があるがDMVに表示されないものがあります（一部はコード内にあり、DMVは解析しません。一部はデータベースがSQL Serverエージェントなどの外部のものに依存しているためです） 、Service Brokerなど）：
- ミラーリング
- 特定の形態の複製
- ログシッピング
- データベースのスナップショット
- オンラインインデックス
- 更新可能な分散パーティションビュー
- バックアップ圧縮
- ポリシーベースの管理
- 計画ガイド
- データベースメール
- メンテナンス計画
- 全文検索
また、ファイルサイズの制限により、DeveloperからExpressに移行できない場合もあります（Expressデータベースは、データファイルの合計サイズが10GBに制限されています）。
もちろん、警告されない他の落とし穴があるかもしれません-それらは移行を妨げませんが、それらはターゲット上で非常に異なるパフォーマンスをもたらすかもしれません。例：
- ターゲットエディション（またはターゲットの基盤となるオペレーティングシステム）に対するメモリ/ CPUの制限が異なる。これは、2008 R2 Enterpriseから2012 Enterprise（CAL）に移行した多くの人たちです（サービスは最初の20コアに人工的に制限されています）。これにより、直接的なパフォーマンスの違いが生じる可能性があります（たとえば、クエリを満たすのに十分なメモリがないか、並列クエリのパフォーマンスがはるかに遅くなります）。より微妙なものには、基盤となるハードウェアが異なるために行われる計画の選択が含まれます。
- ソースでのインデックス付きビューマッチングなどの機能への依存は、使用するソースコードを変更しない限り、ターゲットで自動的に尊重されません
NOEXPAND。そして、あなたはこの機能がクエリが突然遅くなる理由であることさえ知らないかもしれません。
- 同じことが、並列インデックス操作とおそらくこの瞬間に頭に浮かばない他の多くの最適化にも当てはまります（ありがたいことに、私はエンタープライズスペースでほぼ独占的に作業しているため、ほとんどの場合、下位エディションの制限について心配する必要はありません）。
この重複に基づく更新：
データベースを特定のエディションから古いエディション（同じバージョンであっても）に復元しようとすると、役に立たないエラーが発生する場合があります。
サーバー 'server \ instance'のRESTOREが失敗しました。
RESTOREはデータベース 'databasename'を開始できませんでした。
これはあまり直感的ではありません。ただし、SQL Serverのイベントログをさらに詳しく調べると、より有用なエラーが表示されます（1つの例にすぎません）。
SQL Serverの現在のエディションでは一部のデータベース機能を使用できないため、データベース 'databasename'を開始できません。
データベース 'databasename'には、パーティション関数 '_dta_pf__9987'が含まれているため、このエディションのSQL Serverでは起動できません。SQL ServerのEnterpriseエディションのみがパーティション関数をサポートしています。
さて、それは真実ではありません-評価版または開発者版に復元することもできますが、それは要点の外です。このデータベースを復元するには、基本的に2つのオプションがあります。
- SQL Serverの適切なエディションに復元します。これは、新しいインスタンスを検索またはインストールすることを意味します。
- 別の名前の新しいデータベースとしてソースサーバーにバックアップを復元し、すべてのエンタープライズ機能を削除してから、データベースを再度バックアップし、それを下位エディションに復元します。（この特定のケースでは、パーティション関数の名前をエラーメッセージに残しました。これはとにかく破棄可能なもののようです-データベースエンジンチューニングアドバイザによって作成されたため、あまり詳しくない人が作成した可能性があります。彼らが何をしていたかを知っています。これは常にそうだとは限りません。）
（2）のバリエーションは、ソースデータベースのパーティション分割とその他の機能を削除し、別のバックアップを取ることです。しかし、それが壊れていなければ...