My first suggestion is not to do this. If you have a working module and it is already heavily used, just write a new module for the OO stuff and have it use the old module under the covers.

I second that suggestion :-)

My process for this sort of thing is as follows:

1. Create your new OO module that calls the original module where it needs functionality. Do not touch the implementation of the original module. If you do have to touch the implementation, skip immediately step 3. (You will, of course, be creating a nice comprehensive test suite while you implement the new module ;-)
2. Stop - unless the new module is inelegant, or you want to retire the original module.
3. If it doesn't have one already, write a comprehensive test suite for the original module - so you can be sure that you don't break anything during the move.
4. Do not skip the last step. I really mean it!
5. Repeat the following until the original module is implemented in terms of the OO module:
   1. Move a chunk of the implementation from the original module to the OO module.
   2. Re-implement the functionality you've just moved in the original module in terms of the OO module.
   3. Run the test suites for both modules. Fix bugs. Repeat until no bugs.
6. Add some "deprecated" warnings (see perllexwarn) to the original module.
7. Remove original module if you have to (after an appropriate time of mourning).

Basically, do it gradually and incrementally. Don't try and have a single module be OO and non-OO at the same time. It's complicated and will cause you more hassle than it will save.

(and I really mean it about those tests :-)

This nodes spelling mistakes were...

s/morning/mourning/ - thanks Arien

s/depreciated/deprecated/ - thanks to sauoq