...
I should also say, that while I commend you on your ability to quickly build working CLRs, in my opinion if you've got a reasonably close pure SQL solution it's probably better to simply go with it. Less in your CLR library to maintain. And in this particular case, the problem seems so specific I'd be surprised if the need ever came up again in the same application - it looks like a data migration (or student problem) kind of thing to me. To me "common library routines" should consist of a set of utility-oriented functions that are reusable many times under many different circumstances, rather than for one-off cases.
Hard to disagree on the above!
I guess my CLR function is just a good indicator of the performance difference between string operations in T-SQL and managed code, especially as my version of CLR does exactly the same as T-SQL version with CHARINDEX and SUBSTRING's.
While the OP question is most likely an one-off data-fix (for which, I guess any T-SQL solution will do, even the most slowest one), in case where you need to do complex string manipulations on a regular bases, you should remember about what CLR option can give you in terms of performance.
And just a bit about CLR maintainability: maintainability concern is regularly raised when there is a talk about CLR. However, it should be admitted, that most of the time this concern is raised by pure T-SQL developers/DBA's. Personally, I don't take it at all! (There many more things in SQL Server database, which require regular maintenance and attention). I guess it's more about change/release. However, when a proper change release processes are in place, having CLR's doesn't create any maintenance hassles.
It's a great feature of SQL Server. Since SQL2005, together with some another features (eg. partitioning, SSAS and some other), ability of writing managed code for SQL Server makes SQL Server an enterprise level RDBMS product. Before that, not many serious players would use it instead of ORACLE for enterprise level systems.