Card Management system migrations and conversions are lined up globally across credit card issuers. Credit card domain is witnessing a sharp rise in platform migrations primarily due to:
- Regulatory challenges – Guidelines from national central banks regarding consumer data placement and security
- Financial institution mergers – shifting economies resulting in merger & acquisitions in BFSI sector
- Institutions opting for processor platform instead of in-house processing
- Keeping pace with changing technologies – Migration to more robust platforms
- Product upgrades – Platform upgrades with latest version
All migration initiatives have common factor for success – Testing. A comprehensive testing ensures successful portfolio switch over with No to Minimal impact on Bank and customer’s business as usual activities.
This blog will focus on key migration testing challenges and possible control steps.
Migration testing projects typically have 4 phases:
Let’s list down associated challenges at each stage:
- A medium to large scale migration program may have an all-inclusive timeline ranging from 6-12 months. It is practically impossible to freeze process changes on source platform for such duration due to swift changing customer behavior and industry demands. These changes result in scope extension and also impact the next phases – Planning/Execution.
- Another scope challenge is inadequate documentation. Over the number of years with old platform, a considerable change gets seed in system leaving behind little to No documentation due to repository miss management or resource movement. This creates a scope GAP in certain areas which only surfaces during test execution phase
- A Business requirement traceability matrix must be maintained with a track of changes during migration
- Testing teams should be agile enough to include such changes in planning and execution cycle
- BAU/Business operation teams must be consulted for a broad scope review. This will help to identify any missing process. This approach can act as a supplement of missing documentation.
- Planning timeline: Most clients plans to have a larger execution window rather than spending time on proper test planning. This is done in order to reduce overall migration timeline. Shorter timeline limits the comprehensive test coverage and at many instances, plans are revised during execution to accommodate findings.
- Final parameter set up on migrated platform is generally not available during planning phase and a base parameter oriented planning is conducted. This result in frequent revisit of test plans as soon as final parameters starts flowing in.
- Batch processing, most of the card processing activities like Due calculation/Payments/Collections etc. takes place in batch mode. This puts an extra load on test planning as different functions will have different batch requirements such as Daily batch/Month End batch.
- Discussions with product teams can help to arrive at a near right parameter set up on migration platform. This will reduce the planning update during execution phase
- Always consider batch requirements during planning phase. Cases with specific batch requirements must be clubbed.
- Testing consultants with prior migration expertise and re-usable test repositories can significantly reduce test planning time
Even in ideal scenario, it is not feasible to clear all challenges in scope and planning phase, as a result certain challenges will always flow into execution phase.
- New system readiness – Test environment preparation and readiness sometimes eats up the execution timelines due to interface readiness, correct parameter set up and batch performance
- Change in solution/business process – such changes impacts the test plans followed by execution plan updates
- Blocker defects – This area is extremely crucial for execution. Identification and closure of blocker defects has an important role to play in smooth execution and over all test timeline
- Execution teams must closely monitor system and interface readiness and adjust execution plan as per system availability
- Change is solutions should be scoped in a separate execution plan to minimize impact on existing execution plan
- Execution team must set a function wise execution priority and monitor the business requirement traceability matrix
- All major functions and business process related base parameter set up should be verified at execution start time to identify blocker defects at beginning of execution phase
- At this phase, test activities are at its last phase and a sum up of execution results is in process. This phase identities the system readiness to proceed with production implementation. This phase is not encountered with multiple challenges however; one common challenge is Go/No-Go decision. Test team plays a crucial role to assess project state and recommends on the Go/No-Go decision based on execution test results.
- All open defects must be carefully observed and should be assessed as per severity
- A walkthrough of all open items should be arranged with working group for final assessment
- Test teams must ensure that all stakeholders understand the open defects and associated risk
- A formal agreement should be made for Go/No-Go recommendation
In the end, these challenges may vary on case to case basis. Above expected challenges and its awareness can be helpful to identify associated risks and its mitigation plan.
I started my career with Kanbay as COBOL developer writing codes for the customization or support requests from business for their credit card system (VisionPLUS). This allowed me to learn and grasp nuances of the credit cards business.
Then in year 2011, when we started with Verinite, it was always our vision that we would be involved in the consulting piece at-least for the cards industry and that too from technology as well as business stand point. Over last 3 years, we have executed 5 such assignments with varied degree of complexity and delivered exceptional value to our customers as all the clients implemented the recommendations made by us. The nature of consulting assignments involved:
- Bank in Vietnam – They wanted to replace the existing card management system (credit + debit + prepaid). We executed a 14 week assignment for them which involved selecting a right and future proof system out of the 6 shortlisted product vendors.
- One of oldest Islamic bank in Malaysia – Bank wanted us to review the technology strategy in light of the 5 year business strategy put together for the next 5 years. It involved reviewing the current system, processes, people aspects and vendors evaluation.
Through these varied kind of experiences, the consulting team at Verinite put together a vendor evaluation methodology to help financial institutions to select right systems to support their medium and long term needs. I hope this methodology will provide insight and prove helpful for everyone.
I am happy to hear your thoughts !!!
Please click on image below.