This may not be the appropriate site for this question -- the coding path you've been going down thus far calls into question whether advice or documentation would change your practice.

I will tackle just the restricted item of "code not working as intended". Your software vendor imposes a pretty amazing 16-bit restrictionrestriction on your 64-bit machine. Here is one way to work around that restriction, if we assume that parameterization or "learning about loops" are off the table.

define subprocedures

A common theme in software engineering is that, when Author feels the need to write comments in the middle of a procedure, likely that procedure is Too Long. Typically we hit the limits of human cognition before we hit machine limits, but I guess many things are possible.

    'This Copies the Data (Line 1)

This source line suggests defining a new subprocedure:

Sub copy_data_line_1()
    ...
End Sub

Invoke with Call copy_data_line_1().

Similarly the code following this

    'This Copies the Remove Data (Line 1)

might be banished beneath

Sub copy_the_remove_data_line_1()
    ...
End Sub

There are additional sections which might come in for similar treatment.

Has all this improved the quality or maintainability of your code? No. It's also not improving the ability of your project to attract and retain technically skilled colaborators.

It does give you a larger number of 64-KiB buckets in which you can store copy-n-pasted chunks of code. So, not a "solution", more of a work around. I'm trying to meet you where you are.

I encourage you to scour the web and your local bookstore for VBA programming resources which would help you to cobble together a real solution to the business need. Perhaps the present codebase is an asset, but it's a fragile one.