Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Aside from the technical specifics, what should be on your checklist for when you go live with a program? Are there last minute things you can do to make a piece of software go into production smoothly? (assuming you used sound principles in development and tested the average amount) More testing? Discussion with the client? Last minute optimizations?

share|improve this question
It depends on the software, and what "go into production" means. However, NEVER, repeat NEVER do last-minute optimizations just before putting something into production. There should have been a freeze for some time for the purpose of fixing bugs ONLY. – David Thornley Mar 30 '11 at 15:10
up vote 5 down vote accepted

Make sure today isn't Friday.

Never push code into production on a Friday. :)

share|improve this answer
Actually, I don't know about that. In many industries, its common to push code on Friday evenings or Saturday mornings as transaction volumes are lower, and you have more time to rollback if things don't go as planned. – quanticle Mar 30 '11 at 18:35

There's no going live day. There is a going live process. Depending on the kind of software, you could deploy to selected beta testers first (Google-style), and expand the user base.

The same applies if the software is replacing manual processes.

If the software is replacing another system, it is harder, and you should should plan for simultaneous operation of both systems, until there is enough confidence in that the old system can be turned off.

At any rate, you should expect problems, so it is best to have a thorough risk assessment with ready-to-go mitigation and contingency strategies. The risk of an all-or-nothing launch plan is too high.

share|improve this answer
For some things, it's a going-live day (or maybe weekend). In many cases, it isn't feasible to have parallel production systems. – David Thornley Mar 30 '11 at 15:59
@David Thornley: "In many cases, it isn't feasible to have parallel production systems". I don't know what the risk mitigation strategy is, then. However, we do several "cut-overs" from old production to new test. At some point, the users would rather use new test because it works better. We do one more "cut-over" and decommission the old production. Often by and domain name change only. – S.Lott Mar 30 '11 at 20:20
@S.Lott: The risk mitigation strategy is to try really hard to make it go smoothly, and fall back entirely on the old system if necessary. I don't see how to do it differently in, say, a transaction-based system with considerably different data formats. – David Thornley Mar 30 '11 at 20:24
@David Thornley: The run-both-in-parallel is one of those things that's been used for decades. Even with considerably different data formats. However, the "multiple cut-over" works pretty well, even if the data formats are different. It's one direction only, so it's easy to get right. – S.Lott Mar 30 '11 at 20:35
@S.Lott: Running in parallel, or multiple cut-over, means that input from both the old and new versions has to go into both the old and new data stores, since for the applications I'm thinking about it's mandatory that the information be kept complete and consistent. That's more code that has to be written and tested and which can cause problems during the cutover. It can't be one direction only without a simultaneous rollout everywhere. – David Thornley Mar 30 '11 at 21:03

I think that's a fairly generic question, so of course I'm going to have to reply with a generic answer. My opinion is that it's safe to assume that there will most definitely be problems with your software, so what you should plan for on "Going Live Day" aside from making it available for download is this.

Be ready to correct critical errors within the first couple weeks of going live with someone dedicated to the task. When the critical errors are fixed, you can begin to handle the major errors. :)

share|improve this answer

As other answerers have noted, it's so high-level a question it's hard to answer very specifically. I will just say this: it's long-standing web developer's superstition that a web site launched on a Friday will never get an audience or produce any ROI. A friday afternoon launch is especially the kiss of death.

At this point, I'm happy to say 100% of my clients have bought into this superstition.

share|improve this answer

Are there last minute things you can do to make a piece of software go into production smoothly?


There are no last-minute things. There can't be.

First you get it to work, securely, quickly, and reliably.

Once it's working, you introduce it to users. Perhaps as a pilot or alpha-test.

Then, after you make needed enhancements, you introduce more users. Perhaps as a beta-test.

Then, after you make needed enhancements, you introduce more users.

There's no moment at which you "go live".

You progressively introduce more users.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.