A pretty boring but certainly important subject is writing checklists to make sure your BizTalk Application Migration goes smoothly. The last 5 years I have done numerous migrations on a pretty large application, where BizTalk is only one part of the entire system. 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 migration and modify it, so it can be used for the migration of the new release. This modified checklist is used for the first time during the migration 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.

Migration Parts

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

• Preparations before the migration
• Day before the migration
• Check and stop the BizTalk application
• Migrate 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 migration

Before the migration it might be necessary to create scripts which will be executed during the migration. You can think of scripts like database migrations etc. In this step these scripts have to be prepared.
Each script should contain the number of the step in the checklist when, during migration, the script must be executed, for instance by making that number part of the file name. All migration 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 migration

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 migration has arrived. When you are ready, you can start the migration by checking the environment. When everything is okay you proceed with stopping and undeploying the BizTalk application.

Migrate 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 completed and the BizTalk application is running smoothly, you might need to update your monitoring software.

Appendix

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 migration 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 migration is stopping and starting your Host Instances. To remember which Host Instance runs on which Server, you can fill out the table below.

Download the document

The document can be downloaded here.