Answer the question: “What is the difference between an upgrade and an migration?”
For the purpose of this discussion I am going to talk about the two main parts of Sterling Integrator (called Gentran Integration Suite in earlier versions and IBM B2B Integrator in 5.2.4) -- the software and the database.
The software is the part that does all the work. The software runs in a Java Virtual Machine (JVM). There are actually a few JVMs, many if the system is setup for high availability using clustering. The JVM is what runs the workflow engine, translates documents, provides the web user interface, and a lot of other things.
The database is the part that stores the configuration and document data. It is typically an enterprise database that resides on a separate server. The database holds configuration data such as certificates, envelopes, maps, workflow definitions, service definitions, partner setup, etc. It also holds transactional data such as documents, workflow history, mailbox messages, metadata about the data being processed, dataflow history, etc.
Both the software and the database are required for Sterling Integrator to run. And both the software and the database are affected by an upgrade or a migration.
When you migrate to a new version of Sterling Integrator you install new software against a new database schema. When you do this you leave the old instance of Sterling Integrator running. Then you export the important bits from the old instance. Export maps, envelopes, workflow definitions, service definitions, certificates, trading partner information, etc. from the old system and import them into the new system. Once you have everything running and tested in the new system, you cut over, redirect incoming data to the new system for processing and stop using the old one. This can be done all at once, or in stages. A typical staging approach is by protocol where you would move ftp connections, then AS2 connections, and then WS/SOAP traffic.
This approach can minimize downtime. You can get the new system up and running and switch over in a matter of minutes. You also have an easy way to back out. If something doesn’t run as expected on the new system you still have the old one running to process data.
There are some drawbacks. Your transactional history will be split between the new and old systems. If you need to get to information about data that was processed before the migration, you need to go into the old system. Information about data processed after the migration is on the new system. If you are using Sterling Integrator to do duplicate checking, the new system can’t see the duplicate data on the old system. You also need to keep the hardware running for both systems during the migration.
A large challenge is business data that is “in flight”. An example of this is a mailbox store and forward solution, such as Sterling File Gateway. If there is business data setting in a mailbox that has not been delivered or picked up by the Consumer, there are no tools out of the box to move this data to the new system. You must make sure all business data is processed and that there is no “in flight” data setting in the old system when you make the migration.
The high-level steps for a migration to Sterling B2B Integrator 5.2.4 look like this:
1: Install a new instance of Sterling B2B Integrator 5.2.4.
2: Export all of the resources you need from the old instance of Sterling Integrator.
3: Import the resources into the 5.2.4 instance using the “no backup” and “import all” options for best performance.
4: Test the new 5.2.4 instance.
+ Quiesce the old system (or individual trading partners) and transfer the latest envelope control numbers from the old system to the new system.
5: Redirect traffic to the new 5.2.4 instance.
6: Turn off the old instance.
(see the install guide for detailed steps)
Upgrade (also called in-place upgrade)
An upgrade is similar to a regular install. But rather than installing into a new, empty database schema, you point the install at a database from an earlier version (usually a copy to be safe) and install against that. It will lay down new software, but rather than initializing the database with default data, it will keep the old configurations, maps, certificates, etc and it will keep all of the transactional history as well. During the upgrade process the database schema as well as data is upgraded to match what is needed by the new system.
The advantage to this is you don’t have to move over all of the configuration or deal with “in flight” business data. It will be there on the new upgraded system.
You also get all of the transactional data, all of the mailbox messages, runs of business processes, dataflow information, etc. This is either an advantage or disadvantage depending on whether you actually want all of this.
This tends to be a longer process. You have the additional step of copying a larger database. The upgrade itself may need to do transformations on the data in the database so takes longer than just laying down a new database with no transactional data. You may also run into issues with data not quite being in the format that the upgrade expects, which can lead to delays.
If you are going to do an in-place upgrade, I strongly suggest doing a test run. Make a copy of database you plan to upgrade and run an upgrade against that one. This will allow you to iron out any sticking points you may run into and will also give you an idea of how long it’s going to take.
The high-level steps for an upgrade to Sterling B2B Integrator 5.2.4 look like this:
1: Shut down the old instance of Sterling Integrator.
2: Make a copy of the database.
3: Install Sterling B2B Integrator 5.2.4 against the copy of the database and choose upgrade.
4: Redirect any incoming traffic to the new system.
5: Start the new 5.2.4 instance.
(see the install doc for detailed steps)
Some considerations for all upgrades and migrations.
Before you move to a new version of Sterling B2B Integrator, you do need to plan how data is going to get to the new system.
There are two basic ways that data gets into Sterling Integrator.
1) Data is pushed to a listener in Sterling Integrator.
a. Some examples are data coming in through an ftp server adapter or http server adapter.
b. You need to plan how the data is going to be redirected. Some ways to do this are:
i. Give your trading partner the new connection information.
ii. Set the new instance to listen on the same host and port as the old one was. This is less work for your trading partner, but will require some planning on your part.
iii. If the data is already coming through a load-balancer or firewall that can redirect, you can switch the data at that level. It’s a bit more work, but it gives you the most flexibility.
2) Sterling Integrator goes out and pulls the data.
a. Some examples are picking up files using a file system adapter, picking messages up off of a MQ queue, or making an ftp connection to a trading partner to get files.
b. These are much easier to set up. You just need to set the new instance of Sterling Integrator to pull the data from the same place.
c. You do need to be careful to not start pulling data before you are in production though. If you do, you might pull production data into the new system and never process it the production system.
3) “In flight” business data during a migration.
a. Ensure that all “in flight” business data has been processed or drained by the old system before migrating to the new.
b. If all use cases push data to the system, itshould self drain in a short period of time.
c. A major concern is data setting in mailboxes.
d. A secondary concern are scheduled activities that might batch thing up and deliver packages at specific times. Do not forget and leave one of these scenarios in the old system.
e. You may have to design a specific process to move “in flight” data if there is not enough time for the system to drain it on its own.
Be aware of system requirement changes, database version changes and OS/JDK version changes required to run 5.2.4.