保守作業にもテストは必要

もちろん、設定を変えると動かなくなってしまうような項目は外出ししても意味がない。

とはいっても、諸々の経緯から、そのような項目は残るわけで、実際に動かなくなることもあります。で、それを防ぐには、やっぱりテストを書くしかないです。例えばコードテーブルの場合でも、ちゃんと動く組み合わせとなっているかどうか、テストを書いておこう。で、徐々にリファクタリングし、不必要な項目はなくしていく。
また、開発が終了し保守モードに入った後も、様々な作業が発生します。例えば、開発機から本番機への移行。既存DBのデータ移行。すでに稼動しているDBへのデータパッチなどなど。
このような作業でミスを防ぐには、ダブルチェックや手順書のレビューを行うだけでなく、作業自体をいかに自動化し、テストを書くかに尽きます。
システム（＆SIer）に対する満足度は、出来上がったプログラムの品質（バグの少なさ）だけでは決まりません。稼動後の保守作業の質も問われます。そして質を上げるには、心構えだけでなく、テストが必要です。
アドホックな作業毎にテストを書くのは面倒かもしれませんが、例えば移行前のテーブルの値と、移行後に期待する値の比較テストは事前に書いておくべきです。テストは繰り返せますし、後から振り返ったときに、どのような作業を行ったかの記録にもなります。