In the initial release, I had 2 solutions: one is timer job and the other is event receivers/lists. In hindsight, the event receivers/lists should've been separated as well.
In the newest iteration, I've attempted to split the two. Taking the Event Receivers and putting them into a separate solution. Thus far, it works. For the most part.
However, there is the issue of the fact that the list definitions are deployed to the production site and have data in them. If I deploy as-is, it'll wipe the data clean. There is the ListInstance object that I can change the Deployment Conflict Resolution to None, which I did and attempted to deploy. In doing so, it fails at activation because it says a list (or one of the other categories of SharePoint objects, but it is list in this case) already exists with that name. As such, it won't allow it to activate.
The only thing I changed with the feature for what is now the Lists solution was the removal of the event receivers (migrated that code to a separate solution). Anything related to the lists (columns, views, etc.) remained the same. So in reality it should be the same but isn't treated that way (from what I read, if they're the same, it is no harm, no foul. If not, the system won't like it).
In the development environment, I've been able to make it work but the solutions were handled as such:
Timer job - deployed and activated Event receivers - deployed and activated Lists - deployed
At this stage, everything was handling fine. If I don't have the list definitions deployed, the links to the lists result in the page giving an ASP.NET error (understandable), but for some reason the solution just being deployed makes it functional again. Not optimal, but there's that.
What would be a method of making it where all three solutions can be deployed and activated without losing the data within the lists in question? Event Receiver