This session (at GHC15) was of immense interest to me because I have been in this situations so many times at work.
You know?
When the code base is borderline unbearable and some hard decisions have to be made that would weigh on cost and developer resources.
Anyways, the session was more of a discussion though than an expose and I will try to reproduce it here as well as I can.
One question was: How do you minimize risk when migrating to a new code version?
A great way to do that is to maintain multiple versions, and run parallel versions before migrating. This basically means running the new and old platform at the same time for a while for proper tests and checks before actually migrating your data and users to the new.
Another way to minimize risk when deciding to go with refactor or rewrite is testing. Unit testing. Documentation of every little change/step is also very helpful.
A third helpful tip is for you to measure as much as you can. While migrating measure every thing that you can to see that all is going well, if not, adjust. Also incremental changes help for easy roll backs if things aren’t going well.
Backups too shouldn’t be forgotten. Absolutely necessary.
Trisha on of the speakers emphasized a little more on testing. She said that it is important to make sure your current users are not adversely affected by any changes to data, and a way to ensure this is testing with production data to make sure everything is fine.
One should also keep in mind the fact that some techniques used to minimize risks can increase risks in other areas.
Then the discussion moved to how the speakers had dealt with a wrong decision to rewrite code.
Some dealt with it by scratching the whole product itself when it turned out that the rewrite made the product more complicated and difficult for users to use, despite being a great product, that is.
Also, If you are going to onboard customers to a new version you have to do a lot of hand holding, Support them every step of the way to help them get used to the new flow.
On resource allocation, it was agreed that recreating a system -especially a working system- is always a huge engineering investment. It normally takes more time than was anticipated.
Sometimes recreating a platform will not even be of interest to customers, so a balance has to be stricken and things weighed appropriately before making these decisions.
On prevention, there are ways to minimize legacy Code that is not maintainable.
One way to prevent this is by doing code reviews
Another is Peer programming, and that makes so much sense.
Also, a constant aim should be to improve your existing code,constantly ask question about things- like if is the most efficient way- and constantly assess things to know if they are optimized.Even if it’s documentation.
Sara Tansey said that she tried as much as possible not to start over if she could help it in any way.
Lastly, Be willing to change Code. Have everyone on the team on all of the code. Let go of Code Ownership- that thing where each developer owns a section of the code and doesn’t want anyone else to work on it.
All in all, I would say I concluded that rewriting code was to be avoided in favor of refactoring when working with Legacy code that is hard to maintain. If it could be helped, that is. 
