If your excel and flat files are needed to refresh you QVW, it's better to move them also.
Because, even if you use UNC paths to load them instead of relative ones, it means that if you change a file in DEV, it will have an impact in QA and PROD.
The better solution is to have the same folder structure, it will simplify your script and you will increase the reliability of your system (else a test is not a test).
Of course, if for example, you have only flat files in DEV but you have a real database in QA or PROD.
You can for example, create a QVS file in which you set a variable for your environment (LET ENV=QA; ).
Then using INCLUDE, you include (of course ) this script in your code.
And, in the file you can test this value and following the value, you will perform the CONNECT or not. And you will change your LOAD for a FROM file.qvd (qvd); by a SELECT * FROM table.
So, you are always deploying the same QVW and it's only the information in the QVS which will identify the environment.
"...to repeat the same setup as we have in Dev Environment..correct?"
Not necessarily. What you do in Development may never end up on any of the other platforms. This is your Development environment, meaning that you will experiment, develop, test, try&fail and restart various solutions. Once you start tinkering with or improving your Deployment Framework, you will end up with a development platform that will probably be different from everything else. And that's not bad.
Look at it from the other side. QA shouldn't be a copy of Development. On the contrary, it must be - as much as possible - a copy of your Production environment, so that you can test your new (versions of existing) documentson QA as if you were using them in Production. Only after these tests complete succesfully, you can be 99% sure that pushing these documents to Production won't get you or your end-users in trouble.