カウンタートップ用ソフトウェアを乗り換える上で最も難しいのは、既存システムに蓄積された「履歴」である
長年積み重ねられた図面。承認済みの見積書。顧客データ。施工スケジュール。スラブ（石材）の割り当て。前金（デポジット）。当初の見積もりと実際の作業内容が大きく異なる理由を説明する添付ファイル。
インターフェースが洗練されていることは魅力的だ。しかし、それらの履歴を実用的な形で維持できるかどうかが、乗り換えを現実的なものにする鍵となる。
SlabOS は現在、この主張を支える十分な移行実績を備えている。
2026 年 9 月 15 日に実施された権限付きの読み取り専用データベースチェックでは、以下の点が確認された：
- 移行識別子を持つ見積書 155,274 件
- 移行識別子を持つジョブ（案件）111,073 件
- 移行識別子を持つジョブアクティビティ（業務記録）1,178,680 件
これらの数値には、特定されたデモアカウントおよび削除されたアクティビティは含まれていない。アーカイブコピーを除き、既存の宛先レコードのみを集計している。
また、これらのレコードは、Moraware/CounterGo、StoneApp、EasedEdge など複数のレガシーシステムからのインポート事実も裏付けている。
確立されたビジネスを SlabOS に移行する経験があるかどうか疑問を抱いている加工工場にとって、これは意味のある証拠である。
これらの数字が示すもの
移行のボリュームが重要なのは、加工工場が単なる顧客リスト以上のものを抱えているからだ。
見積書は顧客に紐づく。ジョブは住所に紐づく。アクティビティはスケジュールに紐づく。材料はすでに確保されているかもしれない。図面は、元の価格が承認された後に修正されている可能性がある。
これらの関係性を保持することが、運用上の課題となる。
SlabOS の検証済み実装では、顧客および請負業者アカウント、連絡先、アカウントおよび現場住所、ジョブアクティビティ、営業担当者および作業班のマッピング、材料カタログ、価格ルール、図面、見積もり価格、対応する支払い記録、添付ファイル、スラブ在庫、材料割り当てをカバーしている。
本番環境でのカウント数は、SlabOS 内に大量のインポート済みレコードが存在することを裏付けている。実装レビューにより、その背後にある移行作業の広範な範囲が確立されている。
どちらか一方だけでは、すべてのフィールドの正確性を測定することはできない。両方を組み合わせることで、販売ページの機能一覧よりもはるかに強力な結論を支持する。
SlabOS は、Moraware からの切り替えガイドで移行サービスについて説明している。
図面の移行こそが有用性の核心である
古い見積書の PDF を保存していても、その見積書を使って効率的に作業を行う能力を失う可能性がある。
見積作成者は、図面を開き、寸法を確認し、顧客がアイランドカウンターを変更した場合にジョブを修正する必要がある。元の図面の画像は、別の目的を果たすに過ぎない。
CounterGo は公式ドキュメントで見積書や注文の CSV エクスポート、印刷可能な見積書 PDF を記載している。これらは有用な記録だが、代替アプリケーション内で編集可能なジオメトリ（形状情報）を提供するものではない。CounterGo のエクスポート機能、見積書の印刷。
SlabOS の検証済み移行はさらに一歩進んでおり、ソースの図面情報を保持し、カウンタートップ用の図面对象に変換する。
4 つの合成変換ケースでは、矩形とアイランド、継ぎ目のある L 字型図面、価格情報のみ、材料欠損時の処理を検証した。コンバーターは、これらのテストで実行された寸法、相対位置、フットプリント（輪郭）、継ぎ目を保持し、基本的な項目、備考、材料情報も同様に維持した。
これらは限定的な変換テストであった。分離されたコンバーターの出力からは、項目オプションラベルと改訂メモが欠落していたが、ソース情報は他の場所でも保持されているため、完全な移行において情報が失われたことを証明するものではない。
実用的な受け入れテストは依然としてシンプルである。完成したアプリケーションで代表的な移行後図面を開き、確認し、工場が業務を継続できることを検証することだ。
承認済み価格にも同じ注意が必要である
移行後の見積書は一見正しく見えるが、その商業的意味合いが変わってしまう可能性がある。
古い価格表は現在のものと異なるかもしれない。割引が交渉されていたかもしれない。材料レートが上書きされていたかもしれない。現在のルールですべてを再計算すると、承認済みの価格が変更される恐れがある。
SlabOS の検証済み実装では、取得済みの見積もりサマリーを保持し、自動的な再価格付けに対する保護機能を備えている。
これは、未完了のコミットメントを抱える工場にとって重要な機能である。ビジネスが新システムへ移行する際、承認済み見積書が元の価格を維持するための手段を提供する。
既存の合計金額の保持と、将来の計算の再現性は別々のチェック項目である。オーナーによるレビュー時には、承認済み合計額を比較し、その後、制御された図面または材料の変更を行い、税金、割引、端数処理を確認すること。
支払いと在庫も引き継がれる
移行には、日付、金額、方法、参照番号を含む対応する注文支払エントリが含まれる。SlabOS には、これらのインポートされたエントリを表示するパスもある。
これは、「支払済み」または「未払い」というステータスのみを引き継ぐよりも有用である。ただし、特に返金、請求書の配賦、期首残高については、工場の会計記録との照合が必要である。
ここでもソースが重要になる。Systemize では前金の回収を完了したアクティビティとして記録できるが、CounterGo の注文には支払い機能がある。完了したアクティビティと実際の支払取引は、それぞれ異なる意味を保持すべきである。Systemize の前金追跡、CounterGo の注文。
材料側では、検証済み SlabOS 移行は個別識別子、寸法、コスト、保管場所、仕上げ、バンドル、受領日、端材分類を処理する。また、必要材料（Wanted Material）と実際に割り当てられた在庫（Allocated Stock）を区別する。
ヤード（倉庫）および購買チームにとって、この区別は即座に重要である。発注が必要な材料が、すでにジョブに割り当てられている物理的なスラブと混同されてはならない。
オーナーによるウォークスルーはプロセスの一部である
SlabOS は、結果を確認し不一致に対処するために、完了した移行をショップオーナーと一緒にレビューすると述べている。
このプロセスは評価段階に含まれるべきである。成功した移行は、何が到着し、何がチェックされ、何か対処が必要かをビジネス側が理解した状態で終わるべきだ。
SlabOS はほぼゼロの移行エラーを報告している。今回のレビューでは宛先レコードのカウント数を独立して確認したが、元システムとの全フィールドの照合によるエラー率の測定は行っていない。したがって、「ほぼエラーなし」という記述は SlabOS 側の主張として留保される。
公開されている移行認可文書には、検証パスと最終レポートが含まれている。これにより、オーナーはインポートされた作業とともに確認できる具体的なドキュメントを得られる。移行検証プロセス。
最も有用なウォークスルーは、馴染みのあるジョブに沿って行うことだ。承認済みのキッチン、修正されたアイランド、前金、予約済みスラブ、今後の設置予定など。オーナーは顧客、図面、商業条件、生産コミットメントを認識できるはずである。
更新と履歴ファイルには合意されたスコープが必要である
移行は、工場が旧システムで稼働を続けている間に発生する可能性がある。
SlabOS には進捗トラッキング、繰り返し可能なインポート、ターゲットを絞った修復操作が含まれている。検証済み改訂処理では、宛先見積書が既に編集されている場合でも、受信したソース改訂を別途保持できる。在庫処理には、ローカルで編集された材料レコードに対する保護機能も含まれている。
これらのコントロールは、実務的な移行の問題に対処している。インポートが進行中だからといって、新しい仕事が止まるわけではない。
チームは、遅延変更をどこで行い、最終的な更新をどのようにレビューするかについて合意する必要がある。
ファイルのスコープについても明示的な注意が必要である。標準的な添付ファイル設定では、最新の 500 ジョブと最新の 500 見積書がカバーされるが、完全な履歴は別の選択項目となる。数年分の写真、承認、補助書類を期待する工場は、その要件を移行スコープに含めるべきである。
開始時点のシステムによって移行パスが異なる
証拠は複数のレガシーインポートパスをサポートしているが、すべてのプラットフォームに対して同一のカバレッジを保証するものではない。
Moraware の製品も区別する必要がある。Systemize は運用記録をカバーする API を文書化しているが、Moraware の開発者ドキュメントでは CounterGo に API がないことが明記されている。現在の Moraware Inventory およびレガシー Systemize Inventory Edition も同様に、個別のスコープチェックが必要である。Systemize API、Moraware 開発者ドキュメント。
Stonify は顧客、カタログ情報、在庫、価格グループのエクスポートを文書化している。図面設定のエクスポートを、すべての編集可能な顧客図面のエクスポートと混同してはならない。Stonify 在庫エクスポート、図面設定。
ActionFlow は API アクセスとダウンロード可能なデータを宣伝している。SPS は Excel エクスポートと SPS へのインポート用移行テンプレートを文書化している。これらは可搬性（ポータビリティ）を評価するための有用な出発点であるが、SlabOS 内での完了した宛先ワークフローを保証するものではない。ActionFlow FAQ、ActionFlow パッケージスコープ、SPS エクスポート。
データの移動と店舗のセットアップは別の仕事である
提供された SlabOS 管理者向けガイダンスは、移行後も残る作業を特定している。店舗所在地、作業班の割り当て、ロール、招待状、フォームテンプレート、価格ルールの見直しなどだ。
見積作成者は見積書を修正する必要がある。スケジューラーは予約を移動する必要がある。ヤードチームはコミット済み材料を見つける必要がある。作業班は正しい指示を受ける必要がある。
これらが、インポートされたデータベースを実際に稼働中の工場にとって有用なものにする活動である。
SlabOS は、移行込み、ユーザー数無制限、セットアップおよびトレーニング支援を謳っている。購入者は、適用されるサブスクリプション期間、移行スコープ、セットアップ費用の有無を書面でのオファーで確認すべきである。SlabOS 料金プラン。
合意されたチェックが完了するまで、旧記録へのアクセスを維持すること。キャンセル前にソースベンダーのアーカイブ取り決めを確認し、SlabOS が将来的に利用可能なエクスポートをどのように提供するかを確立しておくこと。Moraware アーカイブガイダンス。
結論
SlabOS は大規模な確立された移行実績を持っている。
検証済みのインポートボリューム、複数のレガシーソース、検証済み実装の広範なカバレッジは、長年の蓄積仕事を保持することに懸念を持つ工場にとって強力な根拠となる。
特に Moraware/CounterGo ユーザーにとって、移行能力は購買決定において真剣に考慮されるべき重みを持つ。編集可能な図面変換、保持された見積もり価格、運用記録、サポートされた支払い履歴は、工場が業務を継続するために必要な情報をカバーしている。
オーナーによるウォークスルーは、その能力が自社の記録に対して確認されるべきポイントを提供する。
ビジネス側は、ソース固有のカバレッジに合意し、代表的な作業をレビューし、例外事項を照合すべきである。これらのチェックは、すでに示されている移行履歴の上に構築されるものだ。
変更を検討している確立された加工業者にとって、その履歴は SlabOS を候補リストに入れるための意味のある理由となる。
