I don't think I've ever seen that one before. First things first. Count the number of lines of code in the module. Now use the Help menu to look up either Limits or Specifications. (Which one you need depends on which version of Access you are using. One of them will be right.)
Find the limits/specifications for modules. That will tell you the size of the biggest allowed module. Then you can decide if the module you've got is too big, and by how much.
BTW, if in doubt, you can export your module, then read it back into Word and have Word do line/word counts for you.
Now, now to split a module? Egad, you've asked a devilishly hard question, my friend. There are guidelines to be followed, to be sure, but it is hard to say what you need to do for your specific situation. I can only answer in generalities here.
1. If you see the same sort of thing happening over and over again in various parts of the same module only with different variable names, you might have just found a candidate for conversion to a function or procedure - and your different variable names become formal parameters for the function calls you need. Replace the "same thing happening over and over" with a single-line function/subroutine call.
2. If you are following one theme of action in your module and you leave that theme behind for another in the same module, you have found a split point. Make BOTH PARTS into subroutines that will then be called from a higher level master procedure. I.e. processing file A with one set of input rules, then processing file B with a different set of input rules. Merits having two input routines.
3. Where you see repetition in loops, even when the loops are themselves not similar enough to be covered under my item 1, it is SOMETIMES a good idea to make a subroutine out of a loop that has a relatively tight locus of code around it. For instance, if you have a loop that scans a recordset for something, maybe you can make the scanner into a subroutine even if you only use it in one place - because the scanner will probably have very different error requirements from the code around it. And there is another key to routine splitting...
4. When your error requirements change, you might find that the boundary is a good place to break a routine apart. I.e. up to point A in the code, you only trap one class of errors. But after point A until point B, you have to trap two classes of errors. Isolating the code makes the trap routines easier to write because they don't have to be so very generalized.
5. The rule of thumb USED TO BE that if you had more than about two pages of printed code, it was time to break it up into parts. These days, that might be a little small - but it is not FAR from right.
6. Try to read your code in a straight sitting. When you find yourself starting to nod off, you've passed a split point.