コンテンツ展開ウィザードの危険性は、実際には機能しない可能性があることではなく、特定の機能を備えた共有ポイント ソリューションとしてリリースされたほうがよいオブジェクトを移行しようとする可能性があることです。
具体的には、機能で定義されたリスト テンプレートとして新しいリストをリリースする必要があります。新しいカスタム フィールドは、ソリューションと共にリリースする必要があります。
目安として、コンテンツ (ページやドキュメントのテキスト) は移行できます。構造 (新しいリスト タイプ、フィールド) を解決策としてリリースする必要があります。
変更された新しいページは、サイト上で手動で作成し、準備ができたら公開できます。どうしても一括でリリースする必要がある場合は、ウィザードが役に立ちます。
必要なソリューション パッケージを作成するために、codeplex の STSDev も使用しました。これらのツールは「公式のマイクロソフト製品」ではありませんが、Microsoft の専門家自身によって頻繁に使用されており、「公式」のリリース基準がそれほど長いプロセスでなければ、公式のツールであることに注意してください。
ツールの作成者を確認してください。ほとんどの作成者はブログを持っており、作成者の経験と Microsoft との関係についてよく理解できます。
SPDeploymentWizard は使用していませんが、codeplex サイトから
コンテンツは、コンテンツ移行 API (PRIME) を使用して、他のサーバーにコピーしてインポートできる .cmp ファイル (コンテンツ移行パッケージ) としてエクスポートされます。すぐに使用できるツールとは異なり、ウィザードではツリービューを介してコンテンツを細かく選択できます。
つまり、このツールは「公式 Microsoft プロセス」の GUI ラッパーであり、移行パッケージに配置するコンテンツを簡単に選択できます。
あなたの質問の主題は、実際には簡単な作業ではなく、これを行うためのツールと手法は改善および変更されているため、ブログとコードプレックスを監視してアドバイスを求めてください.
アップデート
移行ツールは、各リリースに必要なドキュメントとページのみに適しているはずです。
リストについては、すべてのアイテムを含む一時的なテンプレートを作成しましたが、これはまだほとんど手動のリリース プロセスです。サイトに構造的な変更を加えていないため、コンテンツ移行ツールで試してみてください。正しく機能しない場合は、リストを削除することができます。
本当の問題は、コンテンツ タイプ ID とコンテンツ フィールド ID の GUID がサーバー間で同じであることを確認することですが、ソリューション/機能パッケージによるカスタマイズ リリースでは違いはありません。
更新 2
個々のページについて、URL、ファイルのリスト、およびアクションを指定して、ページをサーバーからローカル ドライブにダウンロードするか、アップロードする PowerShell スクリプトを作成しました。オブジェクト モデルを使用してページを作成するのは非常に簡単です。カスタム属性は少し複雑ですが、ページのチェックインと公開はそれほど重要ではありませんでした。