ウェブサイトをリニューアルする際にはデータ移行が必要となります。
本記事では、サイトリニューアルに伴うデータ移行についてお伝えしますが、サイトリニューアルだけではなく、「データ移行」に焦点を当ててお伝えするので、サイトリニューアルをする際だけではなく「データ移行」が発生する機会についてお伝えしていければと思います。
データ移行は、比較的簡単に移行できる場合もあれば、難易度が高い移行の場合などがあります。
本記事ではそんなデータ移行について、お伝えしていきます。
データ移行を行う場合、移行対象となるデータと移行できない（しない）データがあります。
この項目では、データ移行の対象となるデータについてお伝えします。
データ移行の対象となるデータには以下のようなデータがあげられます。
・コラムやブログの記事
・新着情報（お知らせ）
・メールアドレスなどの個人情報
・お問い合わせ内容
コーポレートサイトの場合、サイト内で、コラムやブログを運営していることが多いかと思います。
コラムやブログ記事は、アクセスが見込めるコンテンツのため、移行対象となることが多いです。
コーポレートサイトの場合、比較的移行は簡単な移行になるかと思います。
・受注情報
・商品情報
・顧客情報（会員情報）
・コラムやブログの記事
・新着情報（お知らせ）
ECサイトでデータ移行でコーポレートと大きく違うポイントとしては、「受注情報、商品情報、 顧客情報」の3つがあることです。
ECサイトのリニューアル前とリニューアル後でシステムが違い、受注データの形式が異なり、データ移行作業に膨大な時間を要する場合、受注情報を移行しないケースもあります。
受注情報を移行しない場合、顧客の購入履歴の表示や購買データの分析などができなくなってしまいます。
しかし、移行しない場合でも、工夫次第で購入履歴を表示することはできます。
例えば、リニューアル前の購入履歴を表示するための専用データベースを作り、新しいECサイトではそのデータを参照することで、マイページなどで購入履歴を表示することができます。
費用対効果を考え、移行するかどうか、上記のような対応をとるかなど、データ移行を実施する業者と相談しましょう。
商品名／商品画像／商品タイトル・説明文／価格／スペック（色・サイズなど）／商品別送料区別／カテゴリ情報など
氏名／住所／メールアドレス／電話番号／性別／生年月日／会員ID／ポイント／会員ランク／お気に入りリストなど
データ移行を行う場合、移行できない（しない）データがあります。
この項目では、データ移行できない（しない）データについてお伝えします。
データ移行できない（しない）データには以下のようなデータがあげられます。
顧客のパスワードは暗号化されているため、移行で引き継ぐことはできません。
顧客のパスワードはデータベースに保存する時に暗号化するため、新しいシステムでは、その暗号化したデータを継続して利用することが出来ません。
従って、サイトリニューアルのタイミングで、再度パスワードを設定していただく事で対応したりします。
移行をする前にメールやサイト内での告知などで、パスワード再設定の必要があることをユーザーへ連絡するようにしましょう。
どうしても顧客のパスワードをリニューアル先でも継続したい場合、既存のECサイト構築システムで使用しているパスワード認証のロジックを、移行先のECシステムにもそのまま適用するといった方法がありますが、それには既存のECサイト構築システムのベンダーの協力も必要となり、ハードルが高く、実際には行わないことがほとんどです。
リニューアル前のECサイトで決済代行サービスを導入している場合、会員のクレジットカードの情報は決済代行会社が管理しています。
そのため、リニューアル後に決済代行会社も変わる場合には、原則として会員のクレジットカード情報を移行することはできません。
リニューアル後のECシステムで決済方法や配送料金、配送エリアの設定などを行う必要があります。
リニューアル前とリニューアル後で、配送料金に相違があるとトラブルに繋がってしまうケースや今まで使えた決済方法がつかなくなってしまうなどは、顧客満足度を低下させる原因となるため、特に注意するべき項目です。
上から順に難易度が簡単なものとなります。（あくまで目安です）
このデータ移行が一番簡単なパターンとなります。
例えば、Wordpressの同じバージョンから同じバージョンのままリニューアルしたり、EC-Cubeの同じバージョンのままサーバー移転などのがあります。
主にサイトのリニューアルかサーバー移転の場合が考えられます。
大体のシステムの場合、できるだけ新しいバージョンを使う事を推奨しているため、古いバージョンから新しいバージョンへのデータ移行ツールが提供されており、比較的簡単にデータ移行が可能です。
ただ、一つ注意点があるのは、同じシステムでも古すぎるバージョンから、最新バージョンに移行となった場合、途中でシステムの作りが大幅に変わったなどの理由から、ツールによるデータ移行ができない場合などがあります。
システムのバージョンアップは定期的に行う事が推奨されているのは、こういった理由などもあげられます。
EC-CUBE2からEC-CUBE4へのバージョンアップの際には、システムの作りが大幅に違うため、簡単に移行することができません。
こちらはサイトリニューアルする際によくあるパターンです。
例えば、EC-CUBEからShopifyへの移行などがあります。
全く違うシステムへの移行するため、データベースに保存されている情報や項目などが異なる可能性が高く、パターン2よりも難しくなる可能性が高いです。
移行元で使っているシステムがWordpressやEC-CUBEなど有名なものであれば、移行先のシステムで移行用ツールが提供されている場合もあります。
ですが、その場合も使っているバージョンが古すぎると、ツールが対応していない可能性があったりします。
独自システムは自社の要望どおりのシステムを作っているために、特別な仕様のものも多く、独自システムを構築した制作会社の協力が必要となることがほとんどです。
ウェブサイトのデータが保存されている場所は基本的にはデータベースに保存されています。
そのため、データ移行作業を行うということは、データベースに保存されているデータを、別のデータベースに移行させる作業をすることになります。
このデータベースに保存されているデータの形式は、基本的にはシステム毎で事なるため、移行が難しいパターンが出てくることとなります。
データ移行する際、さまざまなケースがあるため、全て同じ方法ではないので、今回はECサイトのリニューアルに伴い、ECシステムの移行すると仮定したデータ移行作業についてお伝えします。
事前に移行作業における予算やスケジュールを知っておくことも大切です。
どのくらいの予算がかけれるのか、どのくらいの期間を使うことができるのか把握しておきましょう。
予算やスケジュールの兼ね合いで移行するデータの対象範囲も変わってきます。
優先順位をつけ、移行を諦めるデータも出てくる可能性もあるかと思います。
また、移行するデータの対象範囲を決めるためには、全てのデータを把握する必要があります。
サイトにどんなデータがあるのか全体を把握していないと何を移行し何を移行しないのか決定することができません。
ウェブサーバデータやクローラーを使ってサイトの全ページのリストを作成することやサイト内（データベース）にどんなデータがあるのか把握し、全てのデータを把握します。
ECサイトのデータ移行をおこなう際は、移行元のデータをCSVファイルなどでエクスポートし、移行先にインポートするのが一般的ですが、必ずしも移行元のデータを抽出できるとは限りません。
ECシステムの管理画面にエクスポート機能が備わっていれば、データを取り出すのは簡単ですが、エクスポート機能が実装されていない場合は、システムベンダーにデータのエクスポートを依頼する必要があります。
また、移行元のECシステムのデータ形式と、移行先のECシステムのデータ形式が異なる場合、データの修正作業が発生します。
エクスポートしたデータの一部が文字化けするなど、技術的に修正の不可能なデータが出てくることもあるため、すべてのデータを移行できるとは限りません。
データをエクスポートする方法や、エクスポートにかかる時間と費用は、ECシステムの仕様やデータ量によって異なるため、移行したいデータを移行元のECシステムから取り出せるのか、そして、どのようなデータ形式で出力されるのか、データの修正作業が必要なのか必ず確認しておきましょう。
移行するデータ量と移行方法、データの修正が必要な場合は修正作業量によって、データ移行の工数や費用が大きく変わってきます。
移行作業にかかる費用とメリット、スケジュールを考慮しながら移行するデータの優先順位を整理し、最終的にどこまでデータを移行するのかクライアントと相談しながら決めていきます。
一例ですが、移行元のECシステムからエクスポートした会員データの修正が必要な場合、会員数が少なければ、すべての会員データを移行先のECシステムに移行しても、それほど工数はかかりませんが、修正するデータの量が多い場合は、膨大な工数が発生します。
その場合、過去○年以内に注文があった顧客のデータだけに絞って移行するなど、データ移行の対象範囲を絞ることもあります。
●CSVで手動でエクスポートしてアップロードする方法
移行するデータを既存のECシステムからエクスポートできるのか、またエクスポートしたデータを移行先のシステムにそのままインポートできるのか確認しましょう。
●データベースからデータを手動でエクスポートし、インポートする方法
移行元のデータベースからPhpmyadominでデータをエクスポートして、移行先にインポートする。
●アプリを使う方法
Shopifyの場合、Matrixify（https://www.shopify.com/jp/blog/excelify-app）というアプリなどがあります。
大量のデータを簡単に他のECプラットフォームからインポートし、Shopifyにエクスポートすることができます。
移行計画を作成し、関係者と共有しましょう。
●移行するデータの対象範囲
サイトの目的やKGI・KPI達成に向けて、必要なデータの優先順位をつけ、費用・スケジュール・重要性などを考慮し、クライアントと合意を得ながら対照範囲を決めていきましょう。
●誰が何を担当するか／スコープ（作業範囲）
エクスポートしたデータの修正作業やファイル名の変更などの作業を、誰が担当するか決める（ベンダーに委託する場合は見積を取る）
エクスポートしたデータの修正作業やファイル名の変更などのマッピング作業の工数の見積もりと誰が担当するかと決める（ベンダーに委託する場合は見積を取る）
●全体のスケジュール
どこまでに移行を完了させるのか
●移行方法と手順
どのような方法で移行するかと手順について
●金額
データ移行に伴う費用について
移行する商品情報としては、下記のような情報が考えられます。
商品名／商品画像／キャッチコピー／商品説明文／価格／スペック（色・サイズなど）／商品別送料区別／カテゴリ情報など。
これらの商品情報を移行元のECシステムからCSVファイルでエクスポートし、エクスポートしたデータを移行先のECシステムにインポートします。
●移行元と移行先でデータ項目が異なる場合
移行元のECサイトに登録されている商品データの項目と、移行先のECサイトで登録する予定の商品データの項目の構成がそろっていれば、商品情報の移行はそれほど難しい作業ではありませんが、データの修正が必要な場合は、マッピングを行う必要があります。
マッピングとは、移行元と移行先の異なるデータ項目を同一項目として関連付ける作業のことです。
具体的な作業としては、データ項目の紐付けを行います。
移行元の「データ項目A」を、移行先の「データ項目C」に対応させるなどのデータの修正です。
例えば、ある商品の説明欄には商品の「原産地」が記載されていて、別の商品の説明欄には「賞味期限」が掲載されているなど、商品ごとにデータの内容がばらばらの形式ではデータを機械的に移行することが難しくなります。
こういった場合、まずは移行できるデータだけを移行元から取り出して移行先に流し込み、イレギュラーな商品データは個別に手作業での修正するといった流れとなります。
●移行元と移行先の画像の縦横比に注意する
移行元のECサイトの商品画像は正方形で、移行先のECサイトの商品画像は長方形であれば、商品画像をそのまま使うことはできません。
画像の縦横比がわずかに変わるだけであれば、すべての商品画像を同じ条件でトリミングするなど、一律で処理できる場合もありますが、一律で処理が難しい場合には、商品画像を手作業で修正するか、新しい画像を用意することが必要となり、膨大な時間がかかります。
サイトのワイヤーフレームやプロトタイプの段階で、移行元の画像の縦横比を考慮して設計しておくことも考えておく必要があります。
●画像データを一括ダウンロードできるか確認する
ECシステムの仕様によっては、ECサイトに使用している商品画像のデータを管理画面から一括でダウンロードできない場合もあります。
そういった場合、移行元のECシステムを提供しているベンダーに画像のダウンロードを依頼する必要が出てきます。
もしベンダーで対応できなければ、画像を1点ずつ抜き出す必要があるかもしれません。
●画像のファイル名を変更する
画像のファイル名を移行先のECシステムの命名規則に従って変更する必要があります。
画像のファイル名を一括修正をサポートしてくれるか移行先のベンダーに確認しましょう。
移行する顧客情報としては、下記のような情報が考えられます。
氏名／住所／メールアドレス／電話番号／性別／生年月日／会員ID／会員ランク／ポイント／お気に入りリストなど
●入力情報のフォーマットや表記規則を確認する
移行元のECシステムで使用している会員情報のフォーマットが、移行先のシステムに合致するか確認しましょう。
文字数／移行元のECシステムで使用している住所などの文字数が移行先のECシステムの文字数上限を超えていないか。
文字化け／移行元のECシステムで使用している文字コードと移行先のECシステムの文字コードは同じか。
半角・全角／ローマ字や数字の「半角・全角」の表記ルールは一致しているか。
会員ID／ログインなどに使用する会員IDは、メールアドレスか一意の文字列か。
●退会済みや冬眠顧客を移行するか
移行元のECシステムからエクスポートしたデータの修正が必要な場合、会員数が多いほど、修正する顧客データは多くなります。
そのような場合、例えば過去2年以内に注文があった顧客のデータだけを移行するなど、データ移行の対象範囲を絞ることも検討しましょう。
ECサイト構築システムによって受注データの形式が移行元と移行先で異なり、データを移行するのに膨大な修正作業が発生する場合、データ移行を諦めるケースもあります。
受注情報を移行することは技術的には可能ですが、費用対効果を踏まえ、データの移行が必要かどうかを判断します。
●受注情報を移行しなくても顧客の購入履歴の表示や購買データの分析は可能です
移行元の受注情報を移行先にデータ移行しない場合も、工夫次第で購入履歴を表示することはできます。
例えば、移行元の顧客の購入履歴を表示するための専用データベースを作り、移行先ではそのデータを参照することで、マイページなどで購入履歴を表示することができます。
移行した記事のURLは極力変更しないでおきましょう。
URLを変更するとサイト内リンクや外部サイトからのリンクが切れるため、SEOの効果が落ちたり、ユーザビリティが悪くなる恐れがあります。
301リダイレクト処理をすれば解消されますが、抜け漏れがあったり、開発が必要だったり、SEO効果が引き継がれなかったりと、運用に支障をきたすことがあります。
またURLをそのままにしておくことで、CMSへのコンテンツ移行後に、リダイレクト設定ミスでリンク切れが発生したり、SEOの評価が落ちたりした場合、原因追及のためのチェックが行いやすくなります。
また、既存の顧客がECサイトをブックマークしている可能性があるため、URLリダイレクトを行う必要があります。
この対応をしないと、ブックマークが正常に移行後のページに繋がらないため、アクセスを失う可能性があります。
Google アナリティクスでアクセス状況を収集している場合、同じアカウントで移行前と移行後のデータを継続的に分析することができます。
たとえば、注文完了ページなどコンバージョンとして設定しているページのURLに変更がある場合は設定の変更が必要なものの、Google アナリティクス上で移行前後の受注件数は合算して表示されます。
ビジネスインテリジェンス（BI）ツールなども同様です。
受注データを使う目的に合わせて、最適な解決策を講じることで、データ移行の費用を抑えながら必要な機能を実現していくという発想を持つことが重要です。
また、サイト移行後の内部・外部リンクの確認やSNSでのURLが問題なく作動しているかサイト全体の確認をしましょう。
本記事ではサイトリニューアルに伴う、データ移行作業についてお伝えしましたが、いかがでしたでしょうか？
データ移行は、簡単に移行ができる場合や移行に時間がかなりの時間がかかるものまで、様々です。
簡単に行える場合は、そんなに難しいことはありませんが、データ移行に修正が必要な場合やデータ全てを移行するのが難しい場合などは、データ移行する木ていやサイトを運営している目的、サイトのKGIやKPIが明確になっていることで、どこまでデータ移行をするかなどの対照範囲も決めやすくなるかと思います。
そのためには、サイトを運営する方が目的を持って運営していくことが必要不可欠になるかと思います。
では、今回はこの辺で。
記事がありません
この記事を見ているあなたに
オススメの記事
前の記事へ