It is not clear what does it mean, "move this to a Serer 2003". What "this"? What is "move"? Move development, or deploy application, or what?
So, let me ask just the first question. Here is the thing: it's a pure madness to do the development without some
Revision Control system. Without it, your software does not belong you, it does not belong to your company, it belongs to every minute disaster or mistake. If does not have to me proprietary, moreover, I would say, open-source would by much better, just because your valuable code asserts are too important to hand it to something without full source code. So, it can be free of charge, very light-weight and very reliable, it can work on a server only or be distributed. You really need to stop doing what you are doing, and settle yourself with a revision control system. Please see my past answers:
Make an unclickable form[
^],
Needs some words of wisedom to set up and/or use a server[
^];
and the answers to this question:
Revision control systems, which to choose from?[
^].
[EDIT — in reply to OP's comments]
I understand you; I faced with this, too, and, at couple of the companies I worked in, there was unacceptably bad system (one example is Microsoft VSS: beware! a big no-no!) Such barriers are not easy to overcome, but overcoming them is very important. A company also need to have unattended automated batch build, system of versioning, and other must-have items. See also the "The Joel Test":
http://www.joelonsoftware.com/articles/fog0000000043.html[
^].
As I understand, your problem with "Server 2003" is deployment. It wasn't clear to me in first place. This is is another item. I believe the formal, comprehensive one-step batch unattended deployment procedure should be developed. I could be as simple as copying ("xcopy"-type) the content from an output directory of the development system through FTP (most typical access method for deployment in the Web world). Nothing too complex, anyway. In revision control systems, each deployment should be a single commitment step, typically creation of a "tag" or "branch" using "weak copy", which is frozen forever (thus avoiding the merging issues which stem from branching).
Also, I want to warn you against mixing up 3 procedures: built, revision control update/commit and deployment. Some teams make a mistake by defining the the procedures of updating code from revision control and build. They, for example, add revision control procedures as a build step in a MSBuild project. It really works. But the idea is really bad. Developers need to make a lot of full rebuilds by many reasons: trying out some way of variant of implementation or a fix, do some special testing, and a lot more. In most of these steps, revision control should not be involved.
Imagine you have some batch files for each operation (this is what I do). They can be: 1) full project build in all configurations; 2) MSI release build (for some types of the products); 3) deployment (for other types of projects, such as sites), 4) some kind of clean-up, optional, 5) update of the version information of the product, optional. You can have different configurations and thus different batches. For example, you can have build with and without th re-build of auto-generated documentation. Each step should be one click. But all the revision control operations should be separate and performed by a person, based on a human decision. Some of those operations also can be batches (it depends on the product you use), but… Listen to a good advice: don't mix those revision control operations with other steps mentioned above.
—SA
Submit an article or tip