[makomk]

That probably has very little to do with it. The immediate cause of all the problems was that Lloyds TSB was forcibly split up in order to try and increase competition and the Lloyds half kept the IT department, and when the TSB half tried to move over to the existing IT platform of their new parent company everything broke.

[lmm]

True as far as it goes, but "everything broke" as a predictable result of poor decisions they made, such as moving everyone over in one go.

[kitd]

Note that "they" in this case is the new parent company. IIRC, they were a fairly new bank, heavily reliant on technology. They had the tech but not the customers. TSB were the opposite. The parent thought their tech, which up to that point was only dealing with 100,000s of records, could deal with billions with little change. They were spectacularly wrong and it showed in all testing. But their management pushed ahead to go live anyway.

Their actions are not far from criminal negligence IMHO.

[nerdawson]

TSB’s parent company is Sabadell which is a massive Spanish corporation.

I was a Solbank (one of their brands) customer and can safely say tech isn’t their strong point. Awful UX and a pain to deal with.

[sofixa]

> such as moving everyone over in one go.

It's the core banking system of a big bank. Handling consistent state between the old and new systems while progressively migrating customers would probably have been extremely complex. They also get to have a maintenance window (few people will complain if they get warned their bank and all transactions won't work for 2 hours in the middle of the night on Monday). A "big bang" migration makes more sense, if everything is properly prepared and tested, which it wasn't.

[PeterisP]

I've been a part of multiple "big bang" migrations in banking (generally scheduled to the coincidences of local banking holidays next to a weekend, so you can afford multiple days of semi-downtime) and all of them had explicit multiple testing gates for potential rollback during the migration, where after pretty much all the stuff is on the new system, the board convenes and after looking at the difficulties (there inevitably are some unexpected difficulties) make the decision whether they "accept" the switch to the new system or postpone the switch.

Part of your preparation and testing is the rollback of a partial migration - if you're irreversibly committed to the "big bang" before you know its outcome, then your preparation and testing has failed.

[JackFr]

> A "big bang" migration makes more sense, if everything is properly prepared and tested, which it wasn't.

That sounds like ‘A “big bang” migration makes more sense, if it works.’

Your rollback plan should never be an afterthought. Your rollback plan should be designed like you expect to use it. If your rollback plan is “Burn the ships” and fix-forward, you shouldn’t be working at a bank.

[flerchin]

Definitely been the plan at a variety of places I've worked. Including a bank.

[908B64B197]

It's funny how there's always a cheap offshored bodyshop involved in these stories yet it's never their fault. Cue in the 9$/hour indian coders working for Boeing.

Here's the thing I've learned over the years: Never touch offshored code. Always go for a complete re-write. Don't add features to it, don't refactor it, don't extend it. Just re-write. In my experience it's the best approach.

I know guys who made it their whole business to go and completely re-write projects from scratch after offshoring efforts failed.