ZF2 がまったく別の動物であることは間違いありません。実際、非常に異なっているため、万能の移行計画/戦略はありません。
ただし、最近、同様の移行を行いました。これはかなり複雑な基幹業務アプリケーションであり、当初は約 18 か月にわたって作成され、さまざまな機能が多数含まれていました。決定の主な要因は、モジュールとイベント システムの改善でした。
私たちの場合、それは製品の主要なポイント リリースになり、最終的にはすべての配管に加えて多数の UI の変更が含まれました。
ZF1 が気に入ったと仮定すると、ZF2 は (フレームワークとして) はるかに優れたフレームワークであるという良いニュースがあります。ModuleManager、EventManager、Di、および ServiceManager コンポーネント (および一般的な MVC 関連のもの) は、理解すれば非常に優れています。悪いニュースは、それらが ZF1 から完全に離れていることです。したがって、少なくともディスパッチとルーティングを完全にオーバーホールするためにサインアップすることになり、Zend_Registry に別れを告げることになります (ServiceManager/ServiceLocator は大幅な改善です)。
もう 1 つの良いニュースは、古い ZF1 タイプのコンポーネントをすべて、必要な限り維持できることです。したがって、Zend_Cache、Zend_Log、Zend_Mail などに依存している場合は、オートローダーの設定を少しいじるだけでそれが可能になります。
私が提案しているのは、思い切って ZF2-as-a-framework に移行することを最初に検討し、後で ZF2-as-a-component-library について心配することです。
fat-model/skinny-controller パラダイムに固執している場合は、Controllers、Front-Controller、Zend_Application などをかなり単純な方法で置き換えるだけでおそらく実現可能です。それを本番環境に導入したら、時間が許す限り、ZF1 コンポーネントへの依存関係を削除する作業を行うことができます。私の場合、物事はかなりうまく分解され、ラップされていたため、それほど多くはありませんでした (たとえば、Zend_Cache から Zend\Cache への移動は簡単でした)。
最後に、View-layer のもの (主にヘルパー関連のもの) も異なることを事前に知っておく必要があります。複雑なビュー関連のもの (パーシャル、カスタム ビュー ヘルパーなど) があちこちにある場合は、それらを書き直すか、ZF2 で古い Zend_View のものを使用して移行できるようにする方法を見つける必要があります。少しずつ。私たちのインターフェイスはかなりシンプルで、UI をオーバーホールする機会と捉えたので、私は実際にはこれに対処しませんでした。
0.02 ドルですが、お役に立てば幸いです。