Legacy migration and interoperability – 5 Phase approach

Continue Reading

Knowledge Capture

Devil is in the details. Capturing all the business and technical details consume energy and migration is half done when details to the nth level are laid out. 

The major challenges usually faced are 

• Non-availability of resources who are familiar with pre-implemented business use cases and reluctant to share the information
• No interface documentation
• No reporting dashboards, system monitoring tools, and change control procedures
• Non-availability of existing production issues in one place

These challenges can be overcome with 

• Detailed analysis of the integration platform and code
• Each interface is reverse engineered and documented to have a thorough understanding of the functionality and identify the patterns

This process also presents a unique chance to optimize existing integration process and deprecate outdated logic and interfaces. Potential security vulnerabilities are assessed and laid out. 

Logical Grouping and Prioritization  

With many numbers of interfaces and endpoints to be migrated, it always makes sense to group them logically and migrate in a phased manner.

Following factors are to be considered at the least for effective grouping of interfaces:

• Application Endpoints – Internal and external application dependencies (like SAP, API, cloud, Databases, Social Media) and grouped by criticality and data to be integrated 
• Criticality – Client/partner based, frequency, volume, data-specific interfaces
• Business process – Custom client specific processes and standard processes like order-to-cash or fulfillment and grouped by a complexity
• Integration patterns – transformations and validations, style – scheduled/event-based, web services/messaging 
• Odd ones – No commonality with other interfaces

Project timelines and external dependencies also play a major role in prioritizing the interfaces.

Following are the factors to be considered for prioritization:

• Start with simple interfaces to help mature the migration process covering the operational and support procedures
• Deal with the most complex and critical interfaces in the last wave of migration
• Align with business teams in the prioritization discussions
• Take into account the external dependencies like client resource availability for testing and infrastructure. 

Design Patterns and Implementation 

As the number of interfaces implementing an integration pattern increases, it makes real sense to spend more time designing those patterns and make them available for reuse to reduce the implementation timeline.

The following are considered for design:

• Automation framework and Productivity tools to 
  • Migrate artifacts like maps, schemas and business processes to new platforms 
  • Migrate Partner profiles
  • Gather production archive files (input and output) for multiple business use cases
  • Compare production output files with actual output
• Framework to enhance the process monitoring and document tracking
• Common frameworks for logging, error handling and archiving
• Reports and Notifications channels

Connectivity to all integration endpoints from the new platform also plays a key role in the implementation.

Validation and Production Readiness

Considering the fact that the old platform is supporting millions/billions of businesses, one of the critical objectives of the migration process is to have the least impact on the ongoing business. A robust testing process is required to not jeopardize the production interfaces.

Following are to be considered:

• Over a year of production archive data for each interface is collected and tested. 
• Stress testing to gauge the throughput, latency and memory utilization in the new platform. This should be done in user acceptance environment.
• More test files coverage for longer duration helps to cover all business scenarios
• Testing framework to speed up the go-to-market timeline
• Regression of as-is functionality of maps, processes, and adapters
• Negative testing
• Bulk data comparison per interface
• End to end testing with partners
• Rollback and deployment testing

Testing with business partners and customers are done based on volume, criticality and their availability. 

Production Cut-over and Support

Once we have all the interfaces tested and deployed in new integration platform, Production cut-over must be done based on the following factors

• Cut-over time – Best done during the least impactful time to the client and the end users. Weekends or non-business hours would be ideal. 
• Each interface should be disabled in the old platform and enabled in the new platform
• Watch out for any failed messages in the new platform to be addressed by the support team
• Post-migration support for a couple of weeks ensures business continuity.

Conclusion

The phased delivery model combined with a high emphasis on leveraging automation frameworks and productivity tools ensure a smooth transition, consuming less time and money for the migration.