The pull of new technology
Choosing whether to adopt a new technology has always been hard for me. I enjoy trying new tools early, often while they are still in beta. When something feels good, I quickly start seeing where else it could fit.
At the same time, I know the safer move is often to wait, or to limit adoption to an internal project where customer impact stays low. That tension has followed me for years.
How we ended up with four stacks
Over time, I saw the same pattern across several initiatives. We identified real pain in the current system, chose a stack that looked better, and started migrating with good intent. The hardest part was rarely deciding to change. It was finishing after priorities shifted.
Like many companies, we looked at our monolith and concluded it had become too large to maintain comfortably. We extracted services and started with Laravel because our existing foundation was in PHP. The first services went well, then urgent business work took over and migration paused.
When we came back, cloud migration had become central. At the time, PHP in Lambda was less straightforward than it is now, so part of the team moved new services to Golang. That move also stalled. Reorganizations happened, people left, and eventually very few engineers were still comfortable maintaining Go services. We then shifted again toward Node.js because it matched team strengths and hiring reality better.
Almost ten years later, the monolith is still in production, with services spread across Laravel, Golang, and Node.js. None of those technologies are the problem on their own. The weight comes from carrying all of them at once.
What we missed in the migration
Looking back, I think we underestimated the cost and duration of migration at that scale. I used to think the main decision was picking the right target stack. Over time, I started seeing that migration continuity matters more than initial selection.
In practice, we might have gained more by first making the monolith easier to evolve: clearer boundaries, better separation of concerns, and more modular internal structure before extraction.
We also switched technologies too often. Stack choices are not only about capabilities today. They are also about whether your team can support them over five years, whether you can hire for them, and whether operational ownership stays realistic.
AI changes the mechanics, not the questions
AI does reduce some friction. Cross-language understanding is faster than it used to be, especially when engineering fundamentals are strong. It is easier to read unfamiliar services, migrate with assistance, and debug across stacks.
But AI does not remove architectural complexity. It does not remove the operational cost of running multiple stacks in production. It also does not replace the need to be clear about why a migration is happening in the first place.
If I face this decision again, I would slow down and pressure-test the basics: what problem we are solving, whether the migration actually removes that constraint, how long it will take to reach meaningful improvement, and where we stop if value does not materialize.
The goal is to simplify what we have to operate, not accumulate more optionality than we can sustain. There is no silver bullet here. Many stacks can solve the same problem. The practical question is which option fits our context, team capacity, and long-term constraints.
If that fit changes later, migration can still be the right move. But it needs a real plan, a realistic timeline, and the discipline to finish. Without that continuity, you end up with a collection of reasonable decisions that become heavy in combination.
- Patrick