BizTalk Application Upgrade: Checklist

Article
1/17/2024

Introduction

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	BTS04
ReceiveHost	X	X
SendHost	X	X
ProcessingHost			X	X
TrackingHost	X	X	X	X
etc.

Download the document

The document can be downloaded here

Share via