倉庫管理システム（WMS）の移行は、企画・現状分析から本番稼働まで5つの工程を順に踏みます。各工程は、出荷業務と並走させながら進めます。
移行を判断する目安からデータ移行、並行稼働まで、発注側が押さえる点を取り上げます。全体像は倉庫管理システム移行の完全ガイドもご覧ください。
▼全体ガイドの記事
・倉庫管理システム移行の完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
倉庫管理システム移行の全体像と判断のタイミング
移行に入る前に、なぜ移行するのか、どの手法を候補にするのかを固めておきます。目的が曖昧なままだと、ベンダーを選ぶ段階で方針がぶれてしまいます。
移行を決断すべき具体的なサイン
判断の材料は、現行システムの保守状況と、業務量や運用の変化です。次の兆候に当てはまるかを見極めます。
- サポート終了：EOSLや、OS・ミドルウェアが保守対象外になっている
- 業務量の増加：EC化で1日の出荷件数が数倍になり、現場で対応しきれない
- 運用の限界：Excelでの補完や手作業が常態化し、特定の人に業務が偏っている
セキュリティパッチを適用できない状態は、事業継続上のリスクです。さらに、オムニチャネル対応で在庫引当が複雑になり、そのしわ寄せが現場に来ている場合も、限界の兆候といえます。
長年の追加カスタマイズで仕様がブラックボックス化し、改修できる人が一人だけになっている場合、そのシステムは属人化が進んでいます。
移行手法の種類と選び方
移行手法は3つに分かれ、初期費用、例外業務への適合、カスタマイズ費用の違いで選び分けます。それぞれの特徴は、下の箇条書きで確認できます。
- クラウド型（SaaS）：初期費用を抑えやすく、数ヶ月で稼働できる
- パッケージ型：業種特化型なら、一定の適合性が得られる
- フルスクラッチ：自社の業務に合わせて構築できる
SaaS型は、自社特有の例外業務に合わせにくいという制約があります。一方、パッケージ型には、アパレルの色・サイズや食品の賞味期限・温度帯を管理する製品があります。ただし、カスタマイズが膨らむほど費用も上がります。
従来は工期とコストが課題だったスクラッチ開発にも、近年はAI駆動開発という選択肢が加わりました。AIを活用した開発手法では工期・コストを30〜70%圧縮できるようになり、パッケージ並みの予算で自社に100%フィットする構築も現実的になっています。
手法は「SaaSかパッケージか」だけで決めず、業務特性と5年スパンのコストで比べます。
倉庫管理システム移行の進め方（全体ステップ）
工程は、企画・現状分析に始まり、要件定義と設計・開発を経て、移行・テストから本番稼働へ進みます。工程の区切りごとに判断ゲートを設け、次の工程へ進んでよいかを確かめます。ゲートがあると、要件が固まらないまま設計に入るような後戻りを防げます。
期間の目安は、SaaS型なら数ヶ月、パッケージ型やスクラッチ型なら半年から1年以上です。全体の日程は、この期間を前提に組みます。
企画・現状分析（As-Is／To-Be）とKPI設定
最初に、現状の業務（As-Is）を一覧にして、非効率な箇所や属人化している作業を洗い出します。業務フロー図には、次の工程を書き入れます。
- 入荷・検品：荷受けから検品まで
- 棚入れ・保管：商品の格納から保管まで
- ピッキング・梱包・出荷：注文品の出庫から発送まで
システムに記録されない現場の例外処理も、漏れなく拾っておきます。ここが抜けると、後工程で在庫差異が生じます。
あるべき姿（To-Be）を描いたら、移行の成功を測るKPIを数値で決めます。たとえば、在庫精度99.5%以上、誤出荷率0.1%以下、ピッキング生産性20%向上などが目標の例です。
具体的な目標値があれば、経営層への投資判断や稼働後の効果検証に使えます。特に、数千万円をかける理由をROIで説明できるかが、予算化の分かれ目になります。
要件定義とRFP作成・ベンダー選定
To-Beの要件は、提案依頼書（RFP）にまとめてベンダーに提示します。選定では、提案書の見栄えよりも中身に目を向けることが大切です。
- 要件の区分：必須（Must）と希望（Want）を分けて書く
- 業務・連携要件：例外業務やERP・OMS連携を文書に明記する
- 実績と開発力：物流への理解、WCS／WES・自動倉庫との連携、移行支援
- 撤退時の対応：データを引き上げられるかどうか
要件を具体的に書いておけば、契約後の認識違いを防げます。
発注先や外注先の選び方は、関連記事もあわせてご覧ください。
設計・開発・テストフェーズ
カスタマイズ範囲とテスト対象は、競争力に関わる業務と現場の例外を軸に見極めます。
- カスタマイズ：競争力に直結する業務だけに限る
- Fit to Standard：それ以外は標準機能に業務を合わせる
- 受け入れテスト（UAT）：自社主導で、例外のシナリオまで検証する
要望をすべて取り込むと、費用と納期が膨らむうえ、将来のバージョンアップも難しくなります。カスタマイズ範囲は、長期的な運用費も左右します。
検証の対象には、返品処理、在庫差異の調整、障害時の手作業への切り替えも含めます。
UATをベンダー任せにすると、現場特有の例外が抜け落ち、本番で初めて不具合が表面化するおそれがあります。
データ移行を成功させる実務（失敗の7割はデータ）
倉庫管理システムの移行で起きるトラブルは、機能よりもデータに起因するものが多くあります。「移行失敗の7割はデータが原因」と言われるほどで、マスターデータの整備と在庫データの移行は、プロジェクトの要です。ここを手抜きすると、稼働直後に欠品クレームや在庫差異につながります。
マスタクレンジングの基準（12ヶ月ルール・名寄せ）
旧システムには、運用の中で溜まった不要なマスターデータが残っています。移行前に、次のようなデータを見直しておきます。
- 未取扱商品：すでに取り扱いのない商品マスタ
- 休止ロケーション：使われていない保管場所
- 重複取引先：表記ゆれで重複登録されたデータ
不要なデータを残したままだと、検索しにくくなり、運用の効率も損なわれます。そのため、明確な基準を立てて機械的にクレンジングします。
たとえば、過去12ヶ月間に入出荷実績のない商品マスタや休止ロケーションは移行しない、というルールを設けます。こうしたルールがあれば、担当者ごとの判断のばらつきを避けられます。
半角と全角、株式会社の前株と後株、スペースの有無といった違いも、名寄せの対象にします。名寄せすると、同じ取引先がひとつに定まり、マスタの重複がなくなります。
在庫の時点整合性（差分移行 vs 業務停止一括）
在庫を移行するときは、データを抜き出してから投入するまでの時点を揃えておく必要があります。その間も倉庫では、入荷や出荷で在庫が動き続けています。
この時間差を放置すると、新システムの在庫数が実在庫とずれたまま稼働することになります。対処法は次の2つです。
- 差分移行：抽出後の在庫変動を差分として反映する
- 業務停止一括切替：週末などに業務を一時停止して在庫を固定し、一括で移行する
差分移行は業務を止めずに済みますが、移行プログラムが複雑になります。一括切替はシンプルな一方で、出荷停止中のバックオーダーを消化する計画が必要です。
出荷量と止められる時間をもとに、現実的な方法を早い段階で決めます。
並行稼働（パラレルラン）の進め方と終わらせ方
並行稼働（パラレルラン）は、新旧システムを一定期間動かして、移行のリスクを抑える方法です。
進め方を誤ると、かえって現場が回らなくなります。事故の多くは、進め方よりも終わらせ方を決めていないことに原因があります。
指示系統の一本化ルール
並行稼働で特に危ないのは、新旧両方から現場へ指示を出してしまう二重化です。同じ作業の指示が二重に届くと、誤出荷につながります。
- 出荷指示書：新旧双方から出すと作業が重複する
- ピッキングリスト：同じ商品を二重にピッキングする恐れがある
- 送り状：誤った送り状を貼る原因になる
作業者に渡す紙やハンディ端末の指示は、新システムからだけ出します。旧システムは、裏でデータ照合や検証のために動かすにとどめ、現場への指示は一本に保ちます。
Exit Criteria（終了条件）の決め方
並行稼働を終える時期は、落ち着いたという感覚ではなく、終了条件（Exit Criteria）を数値で決めて判断します。条件を満たしてから、旧システムを止めます。
- 出荷エラー率：0.5%未満を2週間継続
- ERP連携：API連携が4週間安定稼働
- 棚卸差異率：あらかじめ定めた基準内に収まる
並行稼働中は二重入力のため、現場の工数が1.5〜2倍に膨らみます。終了条件が曖昧だと、この負荷が続いて疲弊やミスを招きます。
条件を達成したら、速やかに旧システムを切り離します。明確なゴールがあることは、現場を守ることにもつながります。
閑散期での切替
並行稼働と本番切替は、物流の閑散期を選んで行います。繁忙期に切り替えると、二重入力の負荷と障害が重なり、現場が混乱します。避けたい繁忙期の例として、次の時期が挙げられます。
- アパレル：セール期
- 食品：歳暮・お中元シーズン
- EC：大型セール期
自社の出荷カレンダーから閑散期を割り出し、そこから逆算して要件定義や開発の日程を組みます。稼働希望日を起点に全体を計画すると、現場の負荷を抑えられます。
本番稼働とリスク管理
本番稼働（カットオーバー）の前に、障害時の対応を決めておきます。
出荷が止まると事業に直結するため、撤退の基準と決定できる人を明確にしておきます。
ロールバック判断基準と権限
ロールバック（切り戻し）は、障害時に旧システムへ戻す判断です。その場の雰囲気で決めないよう、戻す基準の数値と決定権限を事前に決めておきます。
- 出荷エラー率：何%を超えたら戻すか
- 棚卸差異率：どの水準に達したら戻すか
判断の基準や権限があいまいだと、現場が混乱するなかで決定が先送りになり、被害が広がります。
プロジェクト責任者と現場責任者の間で、撤退ラインと、判断を上へ仰ぐ経路（エスカレーション経路）を文書にまとめておきます。そうすれば、緊急時の初動を速められます。
旧システム・旧端末の保持期間
切り戻しに備えて、新しい環境の稼働後も最低3ヶ月は旧ライセンスと端末を保持します。
- 旧端末：先に廃棄すると切り戻せず、業務が止まるおそれがある
- 旧ベンダーとの契約：解約後に旧データベースへのアクセス権を失うと、不整合を調査できない
- 旧環境：データ引き上げと新システムの安定稼働を確認するまで残す
旧環境を残す期間と契約解除の時期は、あらかじめ移行計画に組み込んでおきます。
よくある失敗と回避策
移行では、典型的な失敗が繰り返し起こります。在庫差異につながる例外処理の反映漏れと、ベンダー任せや現場教育の不足が代表例です。事前に知っておくだけで避けられるトラブルも少なくありません。
例外処理の反映漏れによる在庫差異
WMSを入れれば在庫が合う、というのは思い込みにすぎません。現場が良かれと思って行う例外処理が、システムに反映されないと差異が生じます。
- 返品単位の違い：2個1セットの商品が1個だけ返品される
- 破損品の隔離：論理ステータスを変えずゴースト在庫になる
- 無記録の持ち出し：サンプル品などを記録せず持ち出す
ゴースト在庫は、出荷できない商品を引当可能として扱うため、欠品クレームの原因になります。そのため、要件定義の段階で現場の例外処理を詳しく聞き、業務フローに反映させることが欠かせません。
ベンダー丸投げと現場教育不足
典型的な失敗の一つが、ベンダーへの丸投げです。自社の業務を最もよく理解しているのは現場です。
ベンダーはシステムの専門家ですが、自社特有の例外業務までは把握していません。
- 要件定義・テスト：現場も判断と検証に加わる
- 操作研修：並行稼働中に前倒しで行う
- マニュアル整備：本番前に進め、現場の習熟を支える
操作に不慣れな作業者が本番を迎えると、入力ミスや遅延が増えます。だからこそ、習熟してから切り替えることが定着につながります。
まとめ
移行は、企画・現状分析から本番稼働まで、データ移行と並行稼働を挟みながら進みます。止められない出荷業務との両立が求められます。
成功させるには、在庫の時点整合、指示系統の一本化、Exit Criteria、ロールバック基準を詰めておくことが欠かせません。機能だけでなく、実務の段取りも大切です。
現場の例外処理を要件に反映させ、閑散期に切り替え、旧システムと端末は最低3ヶ月保持します。これらが、現場の混乱を防ぐ要点です。
ここで挙げた工程と注意点を、移行のチェックリストとして役立ててください。
費用相場や開発会社の選び方、発注の方法は、完全ガイドと関連記事でご覧ください。
▼全体ガイドの記事
・倉庫管理システム移行の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。