12 Best Practices for a Core Banking Upgrade

Bankers often refer to core systems migrations as open heart surgery -- the vast platforms that support all retail transactions are that critical to the life of a bank. Accordingly, the costs -- and risks -- of core banking projects are high.

To help you improve the prognosis for your core banking modernization initiative, Bank Systems & Technology asked some bankers who recently completed or are in the middle of a core banking upgrade, as well as the analysts who help them, for their advice on what makes such a project smooth and successful. Here are their top 12 tips:

1. Cleanse data before the migration. "Data cleansing is something you have to do beforehand," insists Rudiger Schmidt, head of core banking international at Deutsche Bank, which is implementing TCS BaNCS Core Banking for global transaction banking in a five- to six-year project that began last year. "Clean up the data in the old system; don't expect the new system to do it."

Getting basic information, especially account and customer data, in order is a critical first step, argrees Stefan Besterman, senior manager at consultancy LECG (Devon, Pa.). "Firms need to focus on mastering their data so they can aggregate and maintain control over all of this information," he says.

Silicon Valley Bank ($14.8 billion in assets), which is running its legacy and new core banking systems concurrently as it gradually performs its conversion module by module over five years, had engineers ensure that its reporting and online delivery systems were getting the right information from both its legacy and new core systems, according to Bruce Wallace, head of global services. The Santa Clara, Calif.-based bank put all of its customer information files on its new Oracle (Redwood Shores, Calif.) Flexcube core last year so it would have a single repository even while some accounts remain on the legacy platform. When new data is entered in one system, the other core is updated automatically.

2. Set a schedule and stick to it. "For a program like this, momentum is the most important thing; as a result, schedule is important," says Dave Curran, program director of Commonwealth Bank of Australia's (US$770 billion in assets) core banking modernization initiative. "These programs are really big, and if you lose your schedule, you'll lose your budget and everything else."

Schedule drives cost, Curran points out. "In our case, it's a four-year program. If that four-year program becomes a six-year program, it will cost 50 percent more, because the biggest cost is people. If people work 50 percent longer, it will cost 50 percent more." The price tag for Commonwealth Bank's four-year core banking project, which began in 2008, has been publicly estimated at $580 million. The Sydney-based bank is converting its platforms to SAP for Banking.

Sticking to a schedule also improves decision making, Curran notes. "If the schedule is not important, you could easily get to the point where you can't make decisions because you want to have another discussion, another meeting, another steering group or conference call, and meanwhile you've lost two or three weeks," he says, adding that the focus on keeping on schedule moves everyone along. "That means occasionally you'll make some less-than-perfect decisions. But you can tidy those up later rather than trying to build the perfect solution."

Evoking the common analogy, Curran warns, "You can't afford to leave the patient on the table too long. If you're working on the heart and see something wrong with the liver, you might have to get back to that later."

3. Create a high-level decision-making body to arbitrate between different points of view, such as lines of business or operations and IT, advises Bart Narter, SVP of Boston-based analyst firm Celent. The group -- which should include the heads of operations, IT, retail banking, commercial banking and commercial lending -- should meet at least twice a month, and decisions should be final and binding, he says. "If you're totally reengineering and creating a new system that will affect all parts of the bank, you could go into a two-month spin cycle on a certain issue," Narter notes. "You get senior people to meet once every two weeks and make decisions."

At Silicon Valley Bank, an executive steering committee that conducts periodic assessments of the core banking migration includes executives from IT, product ops, the credit group, the front office and the global team. It's chaired by Greg Becker, the bank's president, who makes final deployment decisions. "Three key executives are intimately involved in the deployment and execution of the program -- that's absolutely critical," relates the bank's Wallace.

Commonwealth Bank of Australia also has an executive steering committee for its core banking project that's chaired by the bank's group chief executive and meets monthly. "We've had 39 meetings and he's only missed one -- because he was sick," says Commonwealth Bank's Curran. "That's a clear example of priority setting."

4. Use a guinea pig. One bank in the Northeast U.S. reportedly acquired a smaller bank and piloted its new core banking system at the acquired institution in order to work out the kinks before conducting a full-scale rollout, according to an industry observer who requested anonymity. Conduct this type of test before the new signage goes up and the main bank will be insulated from complaints and criticism about early hiccups in the new software.

5. Create a reusable blueprint. Deutsche Bank has created a "migration factory" -- a set of methodologies, tools and capabilities for migrating to or from any platform. According to Deutsche's Schmidt, the bank has built a "storybook" of structured processes for migrating checklists, command center structures, communications structures and all of the other changes needed to facilitate a cutover from one system to another.

"We're formalizing it, documenting it and making it repeatable," says Schmidt, who adds that his group is leveraging experiences from former migrations, reusing formerly created tools and runbooks, and improving them. "Each and every defect we find in this migration will be later reworked in the runback."

6. Don't try to do everything at once. "You should not try to put all the items on your wish list into your requirements for the new system," Deutsche's Schmidt advises. "There will be some users who will feel that if they don't put their wish list in now, they'll never get what they want. But this is open heart surgery," he continues, recalling the common core migration theme.

"For the first transformation, reduce new functionality as much as possible -- just try to migrate your existing business on the new platform," Schmidt adds. "Once you are on a new platform, you're able to get to a new level of productivity, and then you can start implementing new functionalities."

7. Create small subprojects that can deliver value along the road. To try to make the process as seamless as possible for clients, Silicon Valley Bank is taking a modular approach to its core banking conversion, migrating one piece at a time over the course of five years. It started with foreign currency loan software, piloting it with a few existing and new clients. According to the bank's Wallace, after deploying each module, the bank reassesses its strategy, looking at the success of the deployment and what might have changed from a market or client perspective from when the bank made its original assumptions.

"We have course-corrected a couple of times along the way," he relates. "Not because the deployments didn't go the way we expected them to, but because certain dynamics or our original assumptions had changed. We continue to reassess each time we do a deployment to make sure we have the right prioritization." So far, the bank has been averaging two deployments a year, with two and a half deployments planned for 2011 -- two major deployments with a "mini release" of additional capabilities in between, Wallace says.

Commonwealth Bank of Australia, which started its core modernization with a customer data integration project and a deposit program, sees its four-year modernization initiative as a series of projects. Yet, "You've got to make sure you have regular releases to business," the bank's Curran notes. "You can't disappear into the background for two or three years. Banks and markets don't have that kind of patience."

8. Expect time and cost overruns. "I've never seen a core banking project go on time," contends Celent's Narter. "Because it's such a large, complex project, there are always surprises, and they're rarely pleasant."

9. Try to enable and retain existing IT employees, even if you're changing IT platforms. "Say you're moving from an IBM mainframe to Unix and your IT staff only knows IBM," Narter says. "It's incredibly demotivating to people to know that as soon as the project is done, they're going to be let go." Instead, invest in retraining the best existing staff on the new system. "Among other things, they understand the operations of the bank," Narter explains.

10. Have end users practice using the new system before official rollout. "They'll come up with things that don't work right," points out Narter. End-user training on the new core system is also important to user adoption and the ultimate success of the project, he adds.

11. Manage the migration strictly. "The cutover itself has to be a military-like operation to run smoothly," Deutsche Bank's Schmidt says.

Commonwealth Bank of Australia's Curran points out that good governance is important at all stages. At the "get fit before the operation" stage, Commonwealth worked to integrate all of its customer service touchpoints, upgrade its customer service and Internet platforms, and drive $200 million of annual spend out of IT budgets to help fund the core upgrade, he reports. In a later phase, the migration will involve "cloud enablement of the organization" -- Commonwealth plans both to buy services from the cloud and to make its services available in the cloud, according to Curran. "You can only do that when you have the core, service orientation and architecture right," he says.

12. Be prepared to quickly fix glitches in the new system. Half of the effort in deploying a new core banking system with zero downtime is testing, Deutsche Bank's Schmidt asserts. "But at the end, you won't be able to test everything, otherwise you'd need to replay, say, an entire year's worth of transactions, and even then you haven't covered everything," he says. "Besides very expensive testing, you have to be able to react fast to any problem after go-live, and you have to be flexible and prepared for some manual workarounds."