Managed File Transfer

 View Only

The 7 essential components of a migration strategy to migrate IBM Sterling Managed File Transfer solution from legacy to Red Hat OpenShift

By KALYAN PAVAN KISHORE CHAKRAVARTHULA posted Wed June 22, 2022 11:05 PM

  

Introduction

The migration of a managed file transfer solution from a legacy platform to a modernized Red Hat OpenShift Platform-as-a-Service (OCP PaaS) is daunting if the migration strategy is not correctly laid out. Understanding the most prominent side-by-side migration option for migrating IBM Sterling Managed File Transfer solution (MFT) and related migration strategy components is critical for the success of the migration. In the side-by-side migration option, the MFT solution runs on legacy and OpenShift parallelly until all the partners are migrated to the new platform.

 

In this article, I have endeavored to define the components and recommendations using a side-by-side migration option as there is no reference material on the migration strategy components. This article identifies seven key migration strategy components for migrating the managed file transfer solution from legacy to OCP (self-managed or cloud-managed OCP). These migration components will act as a foundation for defining the migration process. In addition, it helps the customers speed up the OCP migration journey efficiently and effectively. The same principles apply to migrating from the legacy to Kubernetes (self-managed or cloud-managed Kubernetes).

Migration Strategy Components

The following seven components comprise a basic framework for building a robust migration strategy. A migration strategy starts with a migration assessment and ends with defining the migration pattern.

 

Migration Assessment

The migration assessment helps identify the known unknowns. The known unknowns are the typical risks that may derail the migration because of the product upgrade and/or platform migration from legacy to OCP. This exercise is critical to determining the mitigation plan, migration timelines, and rearchitecting decisions.

 

Partner grouping

All the related producer and consumer partners must be grouped logically in a single group. The general rule of thumb to determine the groups is to understand one-one, one-many, many-one, and spiderweb relations between the producer and consumer partners. A data visualization can help to study the relationship quickly. I recommend starting small with the pilot partner group to identify the teething problems with the new platform. This allows a quick fall-back to happen if there are unforeseen issues. After completing the pilot group migration, customers can add the rest of the groups incrementally to the new OCP platform.

It is recommended to identify the inactive partners who have not sent or received files via the MFT and decommission the partners following the partner offboarding guidelines. The migration of dormant partners may cause additional work and delays.

 

Partner Configurations

All active partner configurations must be exported from the legacy MFT and imported into the new instance on OCP using the out-of-box export/import functionality. Customers can perform this activity before the migration commences. Customers must ensure any subsequent configuration changes made to the old MFT environment are reflected on the MFT instance deployed in OCP. Some of the partner configurations that need to be transferred are:

  • MFT Partners
  • SSH Profiles
  • SSH Keys
  • PGP Keys
  • SSL Certificates, etc.

 

After importing the configurations into the target environment, the configurations must be made compliant with the target environment as per the recommendations in the migration assessment.

 

Partner File Metadata

In MFT, the file metadata includes file activity, business process instances, and communication sessions. The file metadata is used to troubleshoot file failures and analyze the root cause.

 

The file metadata can not be exported from the legacy system and imported into the new system as the product does not provide any tools. So, it is recommended to use the legacy system to perform root cause analysis on the files processed before the migration.


Partner Files

MFT hosts the files to let initiating consumers download the files (aka messages) from their dedicated mailboxes. The customers need to determine the requirements of the unextracted files, whether to make them available on the new platform or request the initiating consumers download the files before the cutover. Requesting the initiating consumers to download the files from the legacy system before the migration decreases the cutover activities. Nevertheless, the unextracted files can be moved from the legacy to the OCP-based MFT solution depending on the customer requirement using custom mechanisms.

 

Code / Configurations

All the custom configurations (business processes, services, adapters, property files, etc.) must be exported from the old MFT and imported into the new instance on OCP using the out-of-box functionality (except the property files, which needs to be imported using customization UI). This can be done before the migration commences. Customer must ensure any subsequent configuration changes made to the old MFT environment are reflected on the MFT instance deployed in OCP.

 

After importing the configurations into the target environment, the configurations must be made compliant with the target environment as per the recommendations in the migration assessment.

 

Migration Patterns

The following table provides the most well-known patterns, pros, and cons. The external and internal partner migrations can leverage any of the below-mentioned patterns - either the pattern can be the same or different for the external and internal partners.

 

The outgoing connections must use the same source IP address as the current flows to make it transparent to the partners.

 

In summary, adopting the best practices and wisely planning the migration can yield a better outcome during the migration from legacy to OCP. IBM Expert Labs can help define the migration process by leveraging all the migration strategy components mentioned above and assist in migrating the partners from legacy to OCP faultlessly.

 

References

  1. Dynamic HTTP/FTP/SFTP (userid - based) routing. (n.d.). Retrieved June 23, 2022, from https://www.ibm.com/docs/en/secure-proxy/6.0.3?topic=scenarios-dynamic-httpftpsftp-userid-based-routing

 

Disclaimer

The views expressed are solely my own and do not express the views or opinions of my employer. I shall not be accountable for and do not accept any liability or responsibility whatsoever for any inaccuracies, omissions, errors, misleading information, loss, or damage howsoever arising (including without limitation, incidental, punitive, exemplary, special or consequential damages, loss of profit or damages resulting from lost data or business interruption), be it by negligence or otherwise, or expense resulting from:-

 - Using the information and contents of this article, whether with or without authorization;

 - Relying on the information and contents of this article, whether downloaded or not;

 - The performance, operation, functionality, non-performance, unavailability, inaccessibility, or corruption of this article;

 Refer to vendor-specific documentation for any latest information.



#Featured-area-2-home
#Featured-area-2
#DataExchange
#filetransfer
1 comment
772 views

Permalink

Comments

Thu June 23, 2022 12:41 AM

Very good summary Kishore !!!