ビジネス推進要因
コンテンツ移行を検討する理由 コンテンツ移行は、以下のようなさまざまな問題を解決できます。
複数のCMSシステムを少数のシステムに統合することで、より一元的な管理、コンテンツのガバナンス、そしてより優れた知識管理 と共有が可能になります。 合併や買収に伴うコンテンツの再編成を行い、ソースシステムからできるだけ多くのコンテンツを統合して、統一された外観と操作感 を実現する。 CMSまたはフラットHTMLで自然に生成されたコンテンツを変換し、フォーマットを標準化することで、コンテンツの統一されたブランディングのための標準規格を適用できるようにする。 サポート対象外バージョンからの複雑なアップグレード手順は、コンテンツをプラットフォームの新しいバージョンに移行することで簡素化できます。 コンプライアンス要件によっては、基盤となるストアにさらなる機能が必要になる場合があります。例えば、コンテンツへのアクセスを監査したり、セキュリティや記録管理を 改善したりする必要が生じる可能性があります。
コンテンツ移行に反対する論拠 コンテンツ移行にはリスクが伴います。コストなど、明白な理由もありますが、移行作業を避けるべきあまり知られていない理由もいくつかあります。これには、転送中の破損やコンテキストの喪失、特に非構造化コンテンツ（通常はビジネスにおける大規模な成果物の一つ）における問題が含まれます。また、外部参照が考慮されない（コンテンツへのリンク切れ）リスクもあります。移行対象データの規模が大きいため、移行作業は非常に多くのリソース（ソース、宛先、一時ストレージ、ネットワーク帯域幅など）を消費します。そのため、移行プロセスの監査も複雑になり、一貫性とトレーサビリティが求められる可能性があります。
コンテンツ移行におけるもう 1 つの一般的な問題は、検索エンジンでの SEO とページランクの喪失です。別の場所に移行して新しいソフトウェアを採用すると、すべての Web サイトURL も 変更されるため、検索エンジンはプロセスについて通知されていても、何らかの調整を行う必要があります。Oracleは ホワイト ペーパーで、いわゆる人的観点に関連するいくつかの問題についても概説しました。コンテンツ移行に関わる人々が、ソース データと新しいシステムの履歴、構造、意味を十分に理解していない可能性があり、それが情報の喪失だけでなく、追加のリソースの発生にもつながる可能性があると指摘しました。[ 1 ]
リスクに対処する方法の1つはメタデータ の使用です。メタデータは、記録を記述、アクセス、管理するために使用され、記録の完全性、信頼性、真正性を証明する究極の手段となります。[ 2 ] [ 3 ]
アプローチ CMSに保存されているコンテンツにアクセスする方法は数多くあります。CMSベンダーによって、 アプリケーションプログラミングインターフェース （API）、Webサービス、 SQL クエリの記述によるレコードの再構築、 XML エクスポート、またはWebインターフェースなど、様々な方法が提供されています。
API [ 4 ] ほとんどのCMSはデータベースを使用してコンテンツを保存および関連付けるため、APIが存在しない場合は、プログラマーはテーブル構造をリバースエンジニアリングする必要があります。構造がリバースエンジニアリングされると、複数のテーブルからすべてのコンテンツを中間テーブル、または何らかのカンマ区切り値 （CSV）ファイルやXMLファイルに抽出するための非常に複雑なSQLクエリが作成されます。開発者はファイルまたはデータベースを入手したら、ターゲットCMSのAPIを読み解いて理解し、コンテンツを新しいシステムにプッシュするためのコードを開発する必要があります。Webサービスについても同様のことが言えます。 XMLエクスポートは、CMSに保存されているコンテンツのXMLファイルを作成しますが、エクスポートされたファイルは、ターゲットとなるCMSシステムの新しい形式に合わせて変更する必要があります。これは通常、開発者が変換を行うコードを記述することで行われます。 HTML ファイル、JSP、ASP、PHP、またはその他のアプリケーション サーバー ファイル形式は最も扱いが難しいです。フラット HTML ファイルの構造は、フォルダ構造、HTML ファイル構造、および画像の場所の集積に基づいています。コンテンツ移行の初期には、開発者はプログラミング 言語を使用して HTML ファイルを解析し、構造化データベース、XML、または CSV として保存する必要がありました。通常、正規表現の 処理機能があるため、PERL、JAVA、C++、または C# が使用されていました。JSP、ASP、PHP、ColdFusion、およびその他のアプリケーション サーバー テクノロジーは通常、サーバー サイド インクルードに依存しており、開発を簡素化するのに役立ちますが、コンテンツはユーザーが Web ブラウザーで表示するまで組み立てられないため、コンテンツの移行が非常に困難になります。そのため、ファイルを調べてファイル構造からコンテンツを抽出することが非常に困難になります。 Webスクレイピングを 使用すると、Webユーザーインターフェースからほとんどのコンテンツに直接アクセスできます。Webインターフェースは視覚的なものであるため（これがCMSの目的です）、一部のWebスクレイパーはUIを利用してコンテンツを抽出し、データベース、XML、またはCSV形式などの構造に格納します。すべてのCMS、DAM、およびDMSはWebインターフェースを使用するため、1つまたは複数のソースサイトからコンテンツを抽出するプロセスは基本的に同じです。場合によっては、Webインターフェースを使用して新しいCMSにコンテンツをプッシュできますが、一部のCMSはJavaアプレットまたはActive Xコントロールを使用しており、これらはほとんどのWebスクレイパーでサポートされていません。その場合、開発者は対象のCMS APIを読み込んで理解し、新しいシステムにコンテンツをプッシュするためのコードを開発する必要があります。Webサービスについても同様のことが言えます。
基本的なコンテンツ移行フロー コンテンツの目録を作成する。 画像、PDF、CSSファイル、Office文書、Flash、その他あらゆるバイナリオブジェクトなどのバイナリコンテンツのインベントリを取得します。 コンテンツまたはコンテンツリソース内のリンク切れをすべて見つけてください。 コンテンツのメニュー構造を決定する。 コンテンツを移動する際に、他のコンテンツやリソースへのリンクが壊れないように、親コンテンツ／兄弟コンテンツとの関連性を見つけてください。 ページからリソースを抽出し、データベースまたはファイル構造に保存します。参照をデータベースまたはファイルに保存します。 サイトからHTMLコンテンツを抽出し、ローカルに保存します。 APIまたはWebインターフェースを使用してリソースを新しいCMSにアップロードし、新しい場所をデータベースまたはXMLに保存します。 新しいCMSの標準規格に準拠するようにHTMLを変換し、すべてのリソースを再接続します。 変換後のコンテンツを新しいシステムにアップロードしてください。 古いものから新しいものへ
新しいサイトのコンテンツ戦略は、 ブランド目標の変化や、新しい環境におけるコンテンツのパフォーマンスを理解するにつれて進化していく可能性があることを覚えておいてください。当初移行されなかった古いコンテンツを復活させる必要が生じる場合もあります。そのため、最初に移行されなかったコンテンツはすべてアーカイブしておくようにしましょう。
参考文献 ↑ Oracle (2011 年 10 月)。「データ移行の成功」( PDF) 。Oracle。2018年 9 月 4 日 に取得 。 ↑ TAHO（2015年9月）。 「情報管理アドバイス60パート5 システム移行中の情報リスクを適切に管理する」 （PDF） 。 タスマニア州政府。 2018年 9月4日 取得 。 ↑ サンチェス＝アロンソ、サルバドール；アタナシアディス、イオアニス（2010）。 メタ データと意味論的研究 。ベルリン：シュプリンガー。p. 28。ISBN 9783642165511 。↑ コンテンツ移行APIではないもの
外部リンク 容易ではない作業：コンテンツを新しいCMSに移行する 