Are you the maintainer or administrator of this system? Did you make *any* changes to the software?

If not the latter and not the former, ask your system admins if they did anything on the file system or services configuration that could impede things from working.

If the latter and not the former, find out if the admins did any work, and review *everything* you did code-wise. If the admins were making changes while you were working on code (on a production system I'm assuming), you need to seriously review your maintenance scheduling procedures.

If you're the only one who maintains this system, then as cold as this seems, you need to learn better system maintenance, programming and implementation policies.

• Implement a Version Control System. Any will do, but 'git' has been, and remains (I'd say) the de-facto standard today. To back that up, Github is a free VCS repository hosting site that allows you to store your code remotely. Honestly, the basics of Git can be learned in a day. For a single-developer situation, it's worth a day to pick things up on. The more advanced topics and situations can be learned as-you-go by Internet searches
• Document your code. This is a very easy thing to do. Most don't do it because they say it wastes time. Well-written documentation can be the light in a train tunnel. At minimum, especially if writing the docs after the code is long in use, it provides you the time to go back through that code, and re-understand what it's supposed to do. Thereafter, a quick look at your docs should point you to where you want to go
• Write a test suite. I can not emphasize this enough. Whether it's 15 year old code, or code you've just inherited, you can take a few minutes every day to write tests that can become something that will reliably test against regressions and other issues that devolve into situations like the one you're facing right now. Writing tests against code you haven't really worked with in a while (or just cobbled together over time without any thought) allows you to re-familiarize yourself with it. If, during review, you feel "holy crap, this is shitty!", you can begin to 'refactor' the code, but because you now have tests, you can mostly move forward with confidence
• Implement at least one infrastructure that mirrors your production system (replace system with environment at will) as closely as possible. You should, at minimum have at least one development system, and your production system. Better yet, have a dev, stage and prod. Whether you use VMs, or some form of containerization system, you should *always* be developing and testing in your dev/stage systems, and *only* go to prod when all of the above points have been done, and you are certain that moving to prod will not break things. Test your integrations several ways. Test as many edge cases as possible to avoid catastrophe
• Last but not least, always document yourself a backout strategy. I don't care if this is a test change of a single line of code, or a change of Operating System, software versions or hardware platforms. If you know you're making some changes, document them down, then document down how you'll roll those exact changes out in the event of an emergency

Please do not be disillusioned; these are the most basic of things that should be undertaken for any programming language, and for any type of system/environment change control. Nothing I've stated here is strictly Perl-related and shouldn't be construed as such.