DBアクセスに独自の仕組みではなくSQL文スクラッチのような形でも特に問題にならないのは、CodeIgniterへの移植のしやすさとして大きい部分だと感じます。共通処理的なコードは適宜、メソッドでまとめるなり、(CodeIgniterでいう)ライブラリを追加するなりしました。今回はTwigを使用しました。Twig」が利用できます。http://blog.a-way-out.net/blog/2015/05/25/codeigniter-twig/元々の実装に有ったHTMLヘルパー的クラスは用意せず、シンプルにTwigを使ったテンプレートを作成していきました。利用するようにしました。そのため各UI部品、Webアプリ全体のデザインについてはあまり時間をかけずに現代的な物になりました。元々のWebアプリではフレームでメニューを表示していましたが、ヘッダーにメニューバー(navbar)を設ける形に作り替えました。URL互換性レイヤーなんてたいそうな名前を付けていますが、元のWebアプリとのURL互換性を取るためのレイヤーをCodeIgniterのコントローラとして作成します。例としてURLが/?function=機能A&page=detail&code=xxxのようなものが来たら、GETとPOSTの値で判断し、/機能A/detail/xxxのURLにリダイレクトさせます。}}この互換性コントローラの呼び出しはapplication/config/routes.phpのルーティング設定に定義します。'compatiblelayer/functionB';のように振り分けます。基本的には新しいURLを使ってほしいですが、既存の資料なりブックマークなりで古いURLを持っていたしても、これを用意しておく事でURL互換性が保たれます。5.6で動かした場合にバグとなる部分を修正する作業が一番重いです。それを乗り越えると既存のフルスクラッチコードは簡単にCodeIgniterのコントローラ、モデル、ビューに分割していく事が可能でした。DBアクセス部分に関しても、旧来のSQL組み立てロジック、PHPが標準で備える関数での実行、結果を連想配列として扱う処理がそのままに近い形で移行できます。どちらもCodeIgniterが独自の作法を極力持たない、フルスクラッチに近い感覚で書けるという良さが移植においても現れた物かと思います。