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.
Last Visit: 31-Dec-99 18:00 Last Update: 7-Mar-14 17:19