What Lies Behind a Framework Upgrade That Didn’t Go Smoothly
- Published at
Have you ever been responsible for upgrading your company’s core application framework?
If so, when do you start?
- As soon as the new version is announced?
- After it reaches a stable release?
Most engineers know staying up to date improves DX and avoids security risks—
but let’s be honest, those points alone rarely convince stakeholders.
The Gap#
Our main web service was built on Nuxt.
When Nuxt 3 was still in beta, I wasn’t overloaded, and my manager R asked if I’d like to explore it.
I said yes—I enjoy research. I like mapping unknown territory, finding an angle that fits the company’s context, and using that to win stakeholder support.
It was also a chance to test what I’d learned from Sr. Staff Engineer V.
After some initial research and a working PoC, the excitement faded.
The upgrade required massive changes. Risks were high. The beta was still evolving, so there was no way to scope or timebox cleanly.
Half a month in, I had no shippable proposal.
No Path Forward#
What would you do?
- Drop it and say it’s not feasible?
- Keep pushing and hope for a breakthrough?
I’m not the most brilliant person in the room, but I’m patient with problem-solving.
So I met with R, shared my findings, and said:
“This isn’t feasible right now.”
But I didn’t want the research wasted.
I proposed a team meeting to turn those findings into shared direction.
A Key Meeting#
I rarely host meetings with more than 10 people, but this one needed it.
The topic cut across microservices and upgrade paths, so I included suggested reading in the invite and prepared a 30-second summary for those who hadn’t read ahead.
The discussion was more engaging than expected—probably because the outcome would shape the next 6 months of roadmaps.
That’s when I learned:
Don’t stop at the problem—look for the opportunity behind it.
We reached consensus on a lower-risk goal:
Make services modular first, then discuss upgrades.
I was assigned as project owner. Great, right?
If only it were that simple.
Reframing Through Business Value#
We had a technical direction.
From a business view, it needed a clearer value proposition.
So I reframed it around performance optimization—aligned with our Q1–Q2 goal: user growth.
I ran another PoC, extracting a high-traffic page into its own service to test for performance gains.
I also researched micro frontend strategies.
The results weren’t promising. The architecture was too tightly coupled for measurable wins without major refactors.
Given our stretched DX, this approach wasn’t practical.
The final proposal: put it on hold.
A New Perspective#
Did I give up?
No. 😌
If the real goal was reducing long-term system risk, maybe the problem wasn’t the upgrade—it was architectural flexibility.
That’s when I thought of a monorepo workflow.
Our main project had lots of shared logic and components. Splitting repos sounds great, but I’d seen the pain of out-of-sync issues in past jobs.
At the time, the team had no micro frontend or monorepo experience, so pushing it would be premature.
The idea went on the shelf.
When Ideas Get Shelved#
Was I discouraged? Yes.
It felt like: I’ve done so much, but nothing’s moving forward.
But sitting in that mindset wouldn’t help.
If I couldn’t push microservices yet, what could I do today to lay the groundwork?
I looked at our codebase and started with quality—focusing on shared logic, architectural patterns, and micro frontend–friendly boundaries.
I proposed small improvements, nudging us toward the long-term vision.
That shift—from frustration to architectural exploration—kept me moving.
Over the next two years, those shelved ideas became real projects.
Final Thought#
This taught me something important:
There’s no such thing as an unsolvable problem.
Accept that something can’t work now, and you’ll find what can.
At the time, I was just trying to salvage a dead-end effort.
But turning failure into foundation was the start of my path to Staff Engineer—
the moment I began shaping not just code, but engineering culture.