Why didn't they roll back the update as soon as that was discovered? Would've caused another downtime of a few hours but better than the current chaos.
Based on the original planned 50-hour outage, I suspect that TSB chose a "big bang" migration: all-or-nothing, no rollback possible. These are technically easier (so cheaper) to develop, but far far riskier than taking a phased approach.
I have successfully argued against such approaches in the past, due to the high risk of catastrophic failure if it goes wrong (i.e., exactly what has happened to TSB).
I regard TSB's failure as an in-the-making textbook example of "how not to do it".
I remember one migration which involved lots of internal services which were all tightly coupled, meaning updates across the whole backend, not just the part that needed it and no way to do a phased rollout. It was made worse by the fact that the update was to the platform and that depended on a DB upgrade, but that upgrade was incompatible with the old version which meant everything had to be done at once.
They had no disaster recovery plan. They got it done, but I'm sure a lot of people involved went grey early thanks to that nightmare.
Of course the business had no idea of the utter mess that caused all of this and continued to make harmful decisions in the name of saving money and further underfunding the IT department.
In the specific case of TSB, I have my suspicions about the reasons for cutting corners in this migration, given: https://www.thetimes.co.uk/article/missed-deadlines-leave-1m...
Tech support switched me over to a part of the site that had not been updated, and that worked for a while. Then it didn't. Back to the bank I go, with a new customer service representative, who really didn't grok the issues (new to the company?), and who became quite snippy.
Very aggravating.