Manassa:
What you need to do is possible but needs to be done very carefully. First of all, do not test on the production system, setup another box with a copy of the DNN directory from the production server and don't forget to also copy the production database. You want to have separate installations for this. Then, when you have the test box running properly with all the functionality available just like on the production site, make a full backup of the test DNN directory and the test database. This will be necessary in case you attempt an upgrade step that screw things up, you will use the test configuration backup to bring back to life the test environment again (and be prepared, you may need to do this a few times).
DO NOT PROCEED without completing the steps above. Also, when you setup the test environment, make sure, and check it twice, that the test DNN implementation is connecting to the test database. You don't want to make a copy of the DNN directory just to have it connect to the same database as the production version, that would be bad, really bad. One way to ensure that the test environment is not connecting to the production server is by physically isolating the test environment, in other words, disconnect it from the production network, literally, pull the network cable from the test box.
Now a question, when you say that "We do not have access to upgrade the software", are you talking about the DNN core software or some other module? If it is the DNN core software, you will eventually need full access to that server to perform the upgrade (that is, after you have done all the testing and have a documented process).
Another thing, are you using core modules only or do you have commercial/third party modules? Or even, in-house developed modules? Third party modules, including modules developed in-house, can always cause problems during major upgrades like what you need to do. This may be the hardest part of the process depending on how many of these modules you have. You may have to find updated versions of commercial or free third party modules or upgrade in-house developed modules. Some modules may not be available anymore and you would have to find a substitute for the functionality.
Regarding the actual upgrade process, I cannot provide the step-by-step process but I can tell you that the process has been documented in these forums, as well as other sites. There is a procedure that discusses doing a gradual upgrade like 2.1.2 to 3.x to early 4.x to the very last version. You would have to make sure each upgrade runs and works properly before attempting the next step. I would also do a backup of each successful middle step (including DNN directory and database of course). Document every step you take with version numbers, specific settings, etc. You will need these steps to upgrade the production site, if you want to repeat the process there, or, you could just perform the whole upgrade on the test environment and then copy it to the production server, not on top of the old production site, but side by side. With the latter idea, you will have two DNN directories, the original production dir in 2.1.2 and the new dir with the latest version. You would also have two databases. Then it would only take a change in the IIS definition of the site to point to the new, upgraded directory that itself uses the new upgraded database (don't forget to change the version of ASP.Net the site needs to use, from 1.1 to 2.0).
Again, the project you are embarking in is doable but needs to be done very carefully and will take some time. Preparation is the key. I hope you can explain this to your management and that they understand it.
May the force be with you...
Carlos