Maybe. Depends on how big the app is and how fast you can fix it if POE doesn't turn out like you want it.

In my opinion, POE looks cool, but it doesn't always make things simpler. Posting events and writing in an explicit event-driven style can be very counter-intuitive when compared with other styles of programming (i.e. functional, imperative, OO, and a mixture of those). It complicates debugging.

I will say, though, that POE is taking quite a following and has some very good Component modules that may make going to this format worthwhile. For me, though, I'd rather write my own event loops and callbacks...just to keep the code simple and more debuggable. This is not for all folks, that's just the way I like it.

Sometimes a good reason to use POE is because the POE modules are better than the non-POE alternatives. i.e. POE::Component::IRC is probably the best IRC module out there. But, even then, it might make since to use POE only so far as to enable use of the module.

The scary thing about POE, at least to me, is that it is rather embryonic, and is apt to change quickly....building your app on a POE dependancy (POE will tend to change the architecture of your whole app) may be a problem if you download a later version of POE and things are different. Or if you want to start programming in a non-POE style.

I'd vote for doing things the same old way (methods and loops), but use a few modules to control your processes and their inputs and outputs. There are other modules out there for starting and checking on processes, etc. If you do adopt the POE approach, I'd at least encapsulate the engine somewhat so you can swap it out later without too much pain.