Everybody has a legacy system. It's hard to learn, it's hard to extend, it's hard to fix, it's hard to test. It probably doesn't perform well, might not be very stable, and it's certainly not the part of the application anybody is excited to work on. Even if you don't have a whole system, you have legacy code that you wish you could get rid of.
Could you just rewrite it? Should you?
I've lived through several large legacy rewrites. Some crashed and burned. Some people got fired. Others made it to production at great cost to those involved. Others actually went well and the world became a better place. How did that happen?
I'll revisit some scars and share lessons learned along the way so your legacy migration has a chance to make your world a little bit better, including: * Do you need to really rewrite it? * No for real, do you really need to? * Ok, so you have to... What's your plan to do it piece-by-piece? * Who is your team? Who are your allies? And... the three people you didn't know you needed! * How to throw things off the boat so you can remain afloat * Whew, you've finished... how do you avoid doing that ever again?
Attendees will gain advice on dealing with rewrites and massive refactors of antiquated systems, which is common in companies of almost all ages and sizes. There will be a discussion of architectural and technical patterns that can be applied to legacy migrations, and there will be tips on reducing stress with business stakeholders and engineering organizations during high-stakes, marathon projects.