Transition plan for PHP5 abomination to Drupal Background

A year from now my clients are going to port a relatively complex intranet portal service (scheduling, actual tracking and reporting, and more) to Drupal because the head office says so. Very little effort has been made to determine if this is the right technical choice and it is beyond the control of my client's or even their bosses.

The current portal is an abomination that is in the process of being re-factored and I believe the most cost effective plan will be to bring in a domain model layer via Doctrine 2 and put 99.9% of all business &amp; input validation logic into the models, gutting out the abomination until it is a skeletal view &amp; authentication logic layer.

Question

For any Drupal specialist out there, does this seem like a viable approach? Could Doctrine2 play nice with Drupal or does Drupal higher level logic need a much tighter integration to the data?
We have done a few sites where we have connected outside systems to Drupal where the data had to be kept in the outside system.  This is what I spend most of my time working with.

When we do this, we typically create a content type to "stub out" the content in the other system.  The content type only contains the node title and a CCK field for the unique identifier in the other system.  Along with this are a lot of hook_nodeapi functions.  For example, the load hook will call out to the remote system and add the data to the node.  You also need to devise a method for getting the outside data into search results.  There are a few methods for this, but those are too lengthy to get into here.

While there are some downsides, we find this works well and allows normal Drupal stuff like comments, tags, etc.