それにしても、これ程の不具合がなぜ運用前のチェックで発見できなかったのか？
今回のような大規模な不具合を運用前のテストで完全に見つけ出せなかったのは、「テスト環境」と「実際の運行現場（本番環境）」との間に、予測できない大きなギャップがあったためだという。
今回のANAのシステム移行は、10年以上使った国内線システム（able-D）を、海外製の国際線標準システム（アルテア）へ丸ごと統合する、歴史的にも極めて難易度が高いプロジェクトだった。事前のテストでも発見できなかった主な理由は‥‥
１．「データの同期ズレ」は本番でしか起きにくいため
テストの段階では、用意されたきれいなデータを使って検証する。しかし本番では、何百万人という利用者が、スマホアプリ、ウェブサイト、旅行会社のシステム、空港の自動チェックイン機などから同時に、ものすごいスピードでアクセスする。
新旧のシステムやアプリが複雑に連携する中で、この大量のアクセスによって「データの時間差（同期ズレ）」が発生し、「予約したはずの座席が消える」「別の人と二重になる（ダブルブッキング）」といった現場のエラーに繋がってしまった。
２．国内線特有の「細かなルール」が多すぎたため
今回導入された「アルテア」は、海外の会社（アマデウス社）が作った世界標準のシステムパッケージだ。
しかし日本の国内線には、「頻繁に発生する予約変更」「直前の振替手続き」「JALや他社（エア・ドゥやソラシドエアなど）とのコードシェア（共同運航）の複雑な組み合わせ」といった、日本独自の非常に細かい運用ルールが大量にありました。これらを海外製の基本システムに無理やり当てはめようとした結果、テストケースから漏れてしまう「想定外のバグ」が潜む原因となりました。
３．「新しい運賃制度」とのダブル変更だったため
システムを新しくするのと同時に、最安運賃「シンプル」などの「新しい運賃ルール」への刷新も同時に行った。「システムが変わったことによる使いにくさ」と「新しい運賃プランの制限（24時間前まで座席指定ができない等）」の2つが同時に現場に押し寄せたため、不具合と利用者の混乱が掛け算で膨れ上がってしまった。
４．1年間の「並行稼働」でも防げないデータの罠
ANAは1年前から新旧システムを同時に動かすなど、かなり慎重な計画を立てていた。しかし、過去に予約された航空券のデータ（クレジットカードの変更に伴うお客様番号の紐付けや、過去の特殊な旅程のデータなど）を新システムへ変換・移行する際、移行の最終段階になって初めてエラーを起こすような、「隠れたイレギュラーデータ」を事前にすべて洗い出すことは不可能だった。
システム開発において「本番環境と全く同じ条件」をテストで作ることは、航空会社のような超巨大システムになればなるほど不可能に近くなる。そのため、「不具合は起きるもの」として現場やコールセンターのサポート体制を事前にどこまで強化できていたか、という「受け入れ態勢（リスク管理）」の甘さも、今回の混乱を大きくした一因として専門家から指摘されている。