There are certain myths that float around the IT industry that defy rational thought. I was recently exposed to one of these myths in a conversation and so I thought I would blog about it in the hopes that I could dispell it somewhat.

Risk adverse organisations will often say that they want the latest version minus one (n-1). The idea is that by going with the latest they are somehow exposing themselves to some sort of increased risk of newly introduced bugs. The implied assumption is that older versions are more "stable" and therefore less risky.

This is completely wrong. The code base of BizTalk 2006 is built directly on top of the BizTalk 2004 code base. So BizTalk 2006 = BizTalk 2004 + All BizTalk 2004 Hotfixes + 2 years worth of design improvements.

So by going with BizTalk 2004, you are depriving yourself of both the design enhancements of the newer version but you are also getting a inferior code base. Now someone somewhere will take that last sentence to mean "BizTalk 2004 is a inferior product". Thats not what I said. I said, BTS2004 is an inferior CODE BASE in COMPARISON to BTS2006.

I've also encountered customers who apply the same thinking to Service Packs. They don't want to apply the latest for some perceived added risk. My response to this is that you are far more likely to hit bugs in the down level version than you are to hit a problem CAUSED by the application of a service pack. Maybe this perception comes from the bad old days when the engineering that went into service packs was less robust. I don't know. But what i do know is that, service packs should be applied asap to lessen the risk of hitting bugs. To put that in other words, Service packs lessen risk.

While we're on that topic...BTS2004 SP2 is highly recommended but be aware that the install modifies the database schema for the message box and tracking databases. If you have large amounts of data in the tracking database, the application of the service pack could take a looong time. One of my customers reported 12+ hours. So this is something you will want to test before trying to apply during a weekend maintenance window. And when you do test this, make sure the test system you are using actually will reflect what you have in production. That is, if you production tracking database is 5 GB, then your test system should have 5 GB in the tracking database also. Or alternatively, archive tracking first before the upgrade and not have the problem.

I'm a big fan of having an identical UAT environment which you can install independantly for production and then do a promote / demote switcheroo and thereby cut over to the new version with the flick of a switch. No risk of borking production during a maintenance window if the UAT (the new production) was prepared and tested earlier.  I'll try to make a comprehensive post on this at a later date.