The question is are you able to do it and prove it to your boss that there is low risk? Do you have good automated tests? At least enough do demonstrate that 'it mostly likely will work, until users do something screwy'?

My argument would be that as you expand the code you are going to want to use some new feature or bug fix and then that is going to cascade into dependency hell trying to get it supported.

200 CPAN modules shouldn't be an issue unless you don't archive them and have a list of supported versions. I had an app that by the end of 3 days required me finding and installing 125 modules. That led me to come up with an XML file that would describe what modules I wanted, what the dependencies where and other things I needed to consider. I then took a few days to create a script that would read it, build, test, and install modules. Only took about 2 weeks of active use to work out all the bugs in it, but I use it all the time now with no issues (unless a module has a screwy install).

I believe it would be better in Ubuntu to setup a new Perl instead of one of 200 CPAN modules borking up the system. While the CPAN shell is nice about resolving dependencies, you don't really realize how big some of those trees are (XML::Compare needs at least 18 modules). Alternative is to make a new location for CPAN modules in your app and make sure your privileges are read only on your system perl.