That sounds like a classic example of what modules can be used for. However, there are two ways to approach factoring your code into modules. The first way is to put all of the usage-specific stuff into a module, and then decide at compiletime (inside a BEGIN{...} block) which module to load, possibly based on command line parameters. The second way is to put all of the common code (the 99% that never changes) into a module, and the usage-specific stuff into the main script. You could have a dozen different main scripts, each of them very short, each which invoke the same module of common tools.

I happen to like the latter method. But don't stop there; there's one more solution: Use object oriented modules. Put all the common code into a base class, and then create a dozen classes that inherit from (or just use) that base class each to perform their own usage-specific task. Again, at compiletime, based on a command-line arg, you can decide which subclass to load in a BEGIN{...} block. That subclass already will know how to load the base class from which it inherits (or uses). And the actual package main code will simply be a minimal framework to initialize your subclass's object and set things in motion.

Then you'll have a tool (or suite of them) that is easy to maintain and update. If something changes on a particular XML feed, all you have to do is change the subclass that deals with that particular XML feed. The base class stays the same, and package main stays the same. New subclasses can be developed without breaking the base class or package main.