There is no reasonable scenario in which a QA department could be expected to verify those and no way that Operations/Support could be expected to put thousands into production at the same time.
Thus a planned rollout involving small sets is required. And small sets can be upgraded manually.
Even if everything went smoothly with say the first 100 one would still want to have a grace period between production and the next batch to insure that some serious problem didn't develop. Attempting to rollback tens versus thousands of apps is obviously very different.
It might be part of a bigger process to upgrade their code-base to a newer compiler/system; maybe a year long process (not uncommon for large systems).
Maybe they have a unit test system in place to validate all their code and system tests to validate the outputs.
I think thinking about a way to automatize converting their project files is good thinking; I would not want to have to double click on 1000s of dsw/dsp in VS2010 and manually upgrade the project files.
Restating what I already said...the mas rollout cannot be done all at once.
Maybe they have a unit test system in place to validate all their code and
system tests to validate the outputs.
Anyone that relies on that as their sole production test deserves the problems that can occur.
I would not want to have to double click on 1000s of dsw/dsp in VS2010 and
manually upgrade the project files.
A phased rollout means that you must support the current production set, not what might be in a year from now. And using a branch (with the older versions) to support most of production for a year just so you don't have to click a few buttons once a week doesn't seem cost effective to me.
Unit testing is only one of many validation tools when updating code to newer compilers.
Maybe they have tons of small and simple libraries (.lib) projects that need to be upgraded and when all tests are passed and validated they will be released. (AFAIK) The library are not compatible between VC6 and VS2010; so they might have to do it "all at once" (an exe build with VC cannot use a VS2010 library and vice-versa).
In the OP's particular case, coming from VC6, it might be the least of their problems if they have been doing C++ and MFC; just fixing all of the compilation errors and warning will probably take forever.
Just updating the project files will be at best hard, even if they can automatize them.
After developing in C#, PHP and several other programming/scripting language I thought I'd give C a try last week. After a week of coding I'm beginning to get the hang of it. I wrote a simple, incomplete HTTP client in C. Since I never coded in C before last weeek I don't know what I'm doing wrong, do I use stuff that is considered bad practice? My code compiles fine and it works fine, I'm just wondering if somebody can take a look and tell me what I could improve. Don't be nice, just tell me what is wrong and what sucks.
Before you get flamed, I thought I'd point out that the Lounge is not the place to post programming questions. If I were you, I would possibly look to split out parts of your application into bite sized chunks and post questions in the Q and A forum asking whether the code follows good practices. I certainly wouldn't link to it in the lounge.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington