Taming the Monolith: How We Leveraged Thailand’s Biggest Holiday for Major Code Cleanups

Every engineering leader has faced that moment: staring at a massive codebase that desperately needs modernization, but finding the “right time” feels impossible. I want to share a story about how we turned a cultural celebration into an unexpected engineering opportunity.

The Challenge: Large-Scale Code Changes in a Living System

If you’ve ever worked with a large monolithic codebase, you know the pain. Those seemingly simple bulk operations — standardizing code style, updating naming conventions, or restructuring folders — become nerve-wracking exercises in merge conflict resolution. I’m talking about the kind of changes that touch thousands of files across millions of lines of code.

We faced this exact challenge. Our repositories were buzzing with activity — 10 to 30 pull requests daily across multiple teams. Every attempt at large-scale refactoring felt like trying to change the tires on a moving car.

The Unexpected Solution: Songkran

Here’s where working in Thailand offered us a unique advantage. During Songkran, the famous water festival, we discovered our golden opportunity. It’s a time when most Thai people return to their families, and with over half our engineering team being Thai, we typically saw 60–70% of our engineers taking extended breaks.

Instead of fighting against this natural lull, we embraced it. We developed a strategy: freeze code contributions two days before the holiday, giving us a clear window for major refactoring work.

The Battle with Tools

Our first attempts were… humbling. I distinctly remember our first go at it — Visual Studio with ReSharper, pointing it at our monolithic solution, clicking “Clean Up Code” and watching it hang for two hours before crashing spectacularly. Even in later years when JetBrains’ Rider came out, we were excited by its 64-bit architecture, it still struggled with our codebase’s size.

We adapted. Rather than tackling everything at once, we broke it down into manageable chunks. Some of our pull requests still ended up massive — between 4,000 and 20,000 lines — but at least we could generate them without our IDEs packing it in. Below is a screen shot from one of these to show the scale and fun:

Modern Times and Lessons Learned

As our stack evolved to include more React and modern JavaScript, our challenges shifted to ESLint and codemod operations. The principle remained the same: find your window of opportunity and use it wisely.

Tips for Your Own Refactoring Adventures

If you’re looking at your own monolithic codebase thinking “this needs work,” here’s what I learned:

Look for natural lulls in your development cycleCommunicate early and clearly with all teams involved, get buy-in, not just permissionBe prepared for tool limitations — test your refactoring approach on a smaller scale firstBreak down the work into manageable chunksHave a clear plan for handling inevitable merge conflicts, especially around configuration files

The Payoff

Was it worth it? Absolutely. Despite the stress of managing massive pull requests and the occasional heart-stopping merge conflict, the readability gains transformed our codebase. More importantly, it made future maintenance and feature development significantly smoother.

Remember, sometimes the best engineering solutions come from embracing your organization’s unique rhythms rather than fighting against them. For us, it was Songkran. What might it be for you?