Checklist for BizTalk Application Upgrade

Checklist for BizTalk Application Upgrade


This article describes the steps which must be taken to perform an upgrade of a BizTalk application. Since each upgrade has its own specific matters, the attached document can be used as a template and can be modified for each specific upgrade.

A pretty boring but certainly important subject is writing checklists to make sure your BizTalk Application Upgrade goes smoothly. The last 5 years I have done numerous upgrades on a pretty large application, where BizTalk is only one part of the entire system. In most cases also the databases, web services, the client application and batch jobs had to be upgraded. Quite a task which had to be performed well, to be able to get the upgrade done succesfully. One of my responsibilities was creating such checklists.

For each new release of the (BizTalk) application I start with taking the checklist of the most recent upgrade and modify it, so it can be used for the upgrade of the new release. This modified checklist is used for the first time during the upgrade in the Test Environment. If we have multiple test runs, the document can be made more perfect during each run. This way we are pretty sure we have a fine checklist when we are going live with the new release.

Upgrade Parts

The upgrade of a BizTalk Application can be split into a number of parts:

  • Preparations before the upgrade
  • Day before the upgrade
  • Check and stop the BizTalk application
  • Upgrade the BizTalk application
  • Start the BizTalk application
  • After the installation

Every part will be described in a little bit more detail below.

Preparations before the upgrade

Before the upgrade it might be necessary to create scripts which will be executed during the upgrade. You can think of scripts like database upgrade etc. In this step these scripts have to be prepared.
Each script should contain the number of the step in the checklist when, during upgrade, the script must be executed, for instance by making that number part of the file name. All upgrade scripts should be placed on a central location.

The main goal you’ll achieve with this is that the scripts can be run and tested in your Test environment. In the ideal world the scripts won’t have to be changed before they are being run at the Live Environment. So all you have to do is move them from your Test Environment to your live Environment.

Day before the upgrade

The day before going live with a certain release, you can put installation files in place and you’ll want to make backups of binding files and all kind of configuration files. These backups will also be stored at a central location.

Check and stop the BizTalk application

The day of upgrade has arrived. When you are ready, you can start the upgrade by checking the environment. When everything is okay you proceed with stopping and undeploying the BizTalk application. The most important thing here is that you stop BizTalk in the correct order. First stop the Receive Locations so BizTalk will stop taking new work, then wait until BizTalk has processed the work at hand, stop the Send Ports and then stop the Host Instances.

Upgrade the BizTalk application

Next the new BizTalk application will be installed. Make sure it is installed (and GAC-ed) and deployed on one BizTalk server and installed (and GAC-ed) on the remaining BizTalk servers.

Start the BizTalk application

After the BizTalk application is installed correctly, you can start it.

After the installation

When the installation is succesfully completed and the BizTalk application is running smoothly, you should check if your monitoring software might need to be adapted, as the configuration of the BizTalk application might have been changed. And of course you want your monitoring software to reflect the current configuration of the BizTalk application.

Appendix of the document

The attached document can be used for both Test as Live environments. However, since the server landscape can be different between these environments and file locations for all kind of upgrade scripts etc. might not be the same, any environment specific matters should be mentioned in the appendix of this document.

The Appendix serves 2 goals: 

  • Store Environment specific settings
  • Store the state of your Host Instances

Store Environment specific settings

To make the document usable for both your Test and Live Environment you can maintain a table in which you can write down any differences between your Test Environment and your Live Environment. You can think of things like file locations for backups or configuration files, but also any different End Point addresses can be mentioned here.

Store the state of your Host Instances

Part of the upgrade is stopping and starting your Host Instances. To remember which Host Instance runs (and is started) on which Server, you can fill out the table which can be found in the Appendix of the document. The table looks like this:

 Host BTS01
BTS02  BTS03
 ReceiveHost  X X
 SendHost  X X

 ProcessingHost     X X
 TrackingHost  X X

Download the document

The document can be downloaded here

See Also

Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.

Read suggested related topics:
  • Understanding BizTalk Application Deployment and Management on MSDN
Leave a Comment
  • Please add 1 and 3 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
  • Lex Hegt edited Revision 30. Comment: Fixed layout

  • Lex Hegt edited Revision 29. Comment: Removed the MSDN section, moved the content to 'Read suggested related topics'

  • Lex Hegt edited Revision 27. Comment: Fixed layout

  • Lex Hegt edited Revision 26. Comment: Fixed a typo

  • Lex Hegt edited Revision 25. Comment: Edit regarding the other type of upgrades which had to be done

  • Steef-Jan Wiggers edited Revision 24. Comment: Minor edits

  • Lex Hegt edited Revision 23. Comment: Fixed layout

  • Lex Hegt edited Revision 22. Comment: Fixed layout

  • Lex Hegt edited Revision 21. Comment: Minor edits

  • Steef-Jan Wiggers edited Revision 15. Comment: Minor edits and fixed typo

Page 1 of 2 (17 items) 12
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
  • Lex Hegt edited Original. Comment: Corrected some typos

  • Tord G.Nordahl edited Revision 2. Comment: formatting, layout

  • L:ex,

    Good article. Keep them coming.

  • Nice on Lex, very good work!

  • Thanks guys! Don't worry: I'll certainly keep them coming!

  • Lex Hegt edited Revision 5. Comment: Added text about stopping BizTalk artifacts in the correct order.

  • Hi BT Tech'ians,

    I have got a new project, where I need to upgrade the BizTalk 2002 EE (product version 3.0) project to Biztalk 2010.

    can any one please provide me the links or suggestions on this.

    Right now we have BT 2002 EE, it has to upgrade to higher version 2010.

    first, should I upgrade to 2004 to 2006 to 2006 R2 and then to 2009 to 2010.

    Please let me know what are the steps to consider and precautions to do this.



  • Horizon_Net edited Revision 6. Comment: added language tags

  • Hi Israel,

    Have you got the solution of your question. If yes, can you please share the relevant documents with me!!

  • nice

  • Richard Mueller edited Revision 7. Comment: Removed (en-US) from title, added tags

  • Interesting article and useful for those that want to migrate their BizTalk applications!

  • Replaced 'migration' to 'upgrade' in the title and throughout the entire article, which better covers this process.

  • @Steef-Jan: thanks for the compliments!

  • Sandro Pereira edited Revision 10. Comment: Add see also

Page 1 of 2 (28 items) 12