Jonathan “J.” Tower

For most of my career, recommending a full rewrite to a client was the fastest way to lose credibility. I've spent years talking clients out of rewrites and into incremental migrations. Lately, though, I've had to adjust my advice. Teams haven't just avoided rewrites on principle. A rewrite often means digging through 10-20 years of undocumented business rules in the legacy codebase, all while it keeps changing underneath you. This is a perfect storm for timelines and budgets. AI turns out to be useful against exactly those problems. It can read the code nobody understands anymore and explain what it was trying to do. It writes tests that pin down how the system actually behaves today, before anyone changes a line. And the mechanical parts of a migration turn out to be the kind of grunt work it's happiest doing. That doesn't make rewrite an automatic yes, but it does mean every modernization decision your team made under the old regime deserves a second look. In this talk we'll modernize the same legacy application both ways, look honestly at where AI helps and where it doesn't, and build a working decision framework for choosing between rewriting, replatforming, and refactoring in place.