Hudsonbanc Billing System Upgrade Two regional banks with similar geographic territories merged to form HudsonBanc. Both banks had credit card operations and operated billing systems that had been in- ternally developed and upgraded over three decades. The systems performed similar functions, and both operated primarily in batch mode on mainframe computers. Merging the two billing systems was identified as a high-priority cost-saving measure. HudsonBanc initiated a project to investigate how to merge the two billing systems. upgrading either system was quickly ruled out because the existing technology was considered old and the costs of upgrading the systemere estimated to be too high. HudsonBanc decided that a new component-based, Web-oriented system should be built or purchased. Management preferred the purchase option because it was assumed that a purchased system could be brought online more quickly and cheaply. An RFP (request for proposal) was prepared, many responses were received, and after months of business modeling and re- quirements activities, a vendor was chosen. Hardware for the new system was installed in early January. Software was installed the following week, and a random sample of 10 percent of the customer ac- counts was copied to the new system. The new system was operated in parallel with the old systems for two months. To save costs involved with complete duplication, the new system computed but didnt actually print billing statements. Payments were entered into both systems and used to update parallel customer account databases. Duplicate account records were checked manually to en- sure that they were the same. After the second test billing cycle, the new system was declared ready for operation. All customer accounts were migrated to the new system in mid-April. The old sys- tems were turned off on May 1, and the new system took over operation. Problems occurred almost immediately. The system was unable to handle the greatly increased volume of transactions. Data entry and customer Web ac- cess slowed to a crawl, and payments were soon backed up by several weeks. The system wasnt handling certain types of transactions correctly (e.g., charge corrections and credits for overpayment). Manual inspection of the recently migrated account records showed errors in approximately 50,000 accounts. It took almost six weeks to adjust the incorrect accounts and update functions to handle all transaction types correctly. On June 20, the company attempted to print billing statements for the 50,000 corrected customer ac- counts. The system refused to print any information for transactions more than 30 days old. A panicked consulta- tion with the vendor concluded that fixing the 30-day re- striction would require more than a month of work and testing. It was also concluded that manual entry of account adjustments followed by billing within 30 days was the fast- est and least risky way to solve the immediate problem. Clearing the backlog took two months. During that time, many incorrect bills were mailed. Customer support telephone lines were continually overloaded. Twenty-five people were reassigned from other operational areas, and additional phone lines were added to provide sufficient cus- tomer support capacity. System development personnel were reassigned to IS operations for up to three months to assist in clearing the billing backlog. Federal and state regulatory authorities stepped in to investigate the prob- lems. HudsonBanc agreed to allow customers to spread payments for late bills over three months without interest charges. Setting up the payment arrangements further aggravated the backlog and staffing problems.

What type of conversion was this? Classify the type of conversion as you describe it.

How could this have been better implemented?