新規作成の部分は、難なくこなせるのですが、改造の案件が来た時に苦戦してしまいます。
苦戦する理由はいろいろあり得るので、あなたの場合どういう理由で苦戦しているのかを分析して、それへの対応策を考えて実施するのが良いと思います。一般論は無いです。
何でもそうですが、「うまくいかない原因」がわからないと、改善できません。
また改造に着手するとき、何から着手すればよいでしょうか?
これも、どんなシステムであるのかによって、いろいろな考え方があるかと思います。
以下は、一例ですが、あなたの場合に適用できるのかどうかは不明です。
そのシステムをゼロから作るときと同じく、どういう業務をどのようにシステムで支援するのかということを理解するのが最初でしょう。そのシステムの目的ですね。これはまあ聞けばわかるでしょう。
ゼロから作るのでなくて改造で対応するので、そのシステムの目的のために、前任者はどのようなアプローチで、どのように設計したのかを調べるのが次。これは良いドキュメントが残ってない場合が多い気がします。リバースエンジニアリングツールがうまく使えればいいのですが。
で、コードを読んで理解する。
もちろん、微細な修正であれば、前段を飛ばして、該当のプログラムを読むだけでできると思います。
変更要件と状況によっては全面再構築も検討した方がいいかもしれない。
他に考えるべきこととしては、
・「ここだけ修正すればいいと思って修正・テストしてリリースしたけど、実際に障害が発生して、あそこも修正が必要だったことが分かった」みたいなことをどう防ぐか。
・テストをどの範囲行うか。修正規模によっては、システム新規作成時と同じ規模のテストが必要かもしれません。
・なじみのないシステムだと、プログラムが正しくても、本番システム修正手順を間違えてしまって障害発生とかも。自動化されていれば細かい間違いはないのでしょうが。
など。