My team already had a Microsoft-based solution (CRM/e-business tools), but it was the result of incrementalism, and not all the parts were interconnected, and there was no way it could scale out much more without serious changes.

We eventually dove in head first with Apache2/mod_perl/Linux and never looked back. Sure, we hit a couple bumps along the way, but with CPAN, PerlMonks and sheer PerlHackerism we're now almost ready to launch.

We had to make use of what was available to us - and that meant Apache::ASP, Class::DBI, Apache::Session, XML::*, DBD::*, etc, etc, etc, - you get the drift. 90% of every Perl application is written already.

Sure, 15 months ago when we started, the new MVC frameworks (a la Rails) were a novelty so we rolled our own, but it was pretty easy to do since everything else was already handled by other existing modules. I think we would have written our own MVC framework anyway because we needed it to do exactly what we wanted, and nothing else.

Some things that we really would like to have include

• distributed transactions (i.e. J2EE's JTA)
• built-in WSDL-generation (Pod::WSDL is close! (but brand-new))
• a more robust (and distributed) Publish/Subscribe model (Class::Publisher is close, but not distributed out-of-the-box)
• a clearer path to system-wide event-handling (maybe with Event::Lib - seems good, needs more examples)
• A Perl IDE with a built-in FileBrowser and simple check-in/out instead of a hackneyed "Project Manager" (cough-Komodo-cough-EPIC-cough)
• Commit/Rollback event notifications (a la J2EE's JTA)
• Robust and well-documented system messaging framework (a la J2EE's JMS)

Fortunately these nice-to-haves would simply take time and humans thrown at them long enough to make them happen. They could even be fun projects to work on and release into CPAN.

In the end, our project has succeeded and we're very happy with the way things have turned out. I look forward to maintaining and supporting our new platform because it Just Works.