- Customer: Large US Bank
- Industry: Financial Services
- Challenge: Move IBM BAW database platform from DB2 z/OS to MS SQL Server and migrate existing workload
- Solution: BAW Instance Migration
- Outcome: 35,000 process instances migrated to new infrastructure enabling mainframe cost savings
A large bank wanted to move their IBM BAW database from DB2 z/OS to MS SQL Server and contacted IBM for support. Since there are no database level tools available to support this, IBM reached out to Apex to support the client with this migration project.
Leveraging experience from previous migration projects, Apex proposed an "Instance Migration" approach. This uses a tool that reads process instance data from a legacy environment and re-creates the legacy process instance in a new target environment without the need for any direct database migration. We ran a short POC with the client’s data to prove that the tool could be effective for their scenario. As part of the POC, we successfully migrated 20 process instances and the resulting process instance data was tested and verified by the client in the target environment.
After the initial POC, Apex led a discovery phase to identify any development patterns in the client processes that could require custom updates to the instance migration tool. We identified a few patterns that required specific handling, so additional development of the Instance Migration Tool to support those patterns was completed. This was followed by another round of instance migration testing and validation by the client.
Since the Instance Migration Tool utilizes published API’s to update process, task and business data, the resulting process instances in the target environment are exact copies of the legacy process instances. After each process instance is migrated to the target environment, the legacy process instance is suspended so that the “master” for each process instance is only accessible in one environment, but the legacy process instance is still available for reference if there are any questions or an issue arises. Reporting is provided for each “run” of the Instance Migration Tool and it maps the legacy process instance details to the new process instance and also identifies any issues encountered during the migration.
When testing a larger run (500) of non-production process instances, the migration report identified another issue that was occurring consistently with one specific process. The issue was traced to a rather unique modeling style that had been used for one particular part of the process. Although it was unusual, it was valid logic, so Apex made another adjustment to the Instance Migration Tool to support it correctly. At this time, everything was retested and validated by the client.
A plan for a phased migration was set up based on groups of users and the processes that they consumed. Once approved by all the stakeholders, the production migration was started. During the production migration, the client team executed the migration based on the phased approach they had planned. The Apex team had daily review meetings with the client and supported them through their successful migration of approximately 35K process instances.
Once again, the Instance Migration Tool had proven to be an effective strategy for a specific BAW migration scenario. You might want to consider process instance migration if you are facing any of the following:
- Migration between significantly older and newer versions (where no DB upgrade script is available)
- Migration to a new underlying database vendor
- Migration from on-premises to SaaS
To learn more about BAW Instance Migration, contact us.
