Introduction
If you've worked on a long-lived frontend, you already know the story. The app grows, features pile up, deadlines keep comi...
For further actions, you may consider blocking this person and/or reporting abuse
Just wanted to add that we’ve leaned on generative AI to make navigating our legacy Angular code less painful. The stats in this blog, like which components are purely legacy versus newly added are analyzed by Claude Code. We also use Claude.md files to locate and fix tricky bugs in legacy code, which can be hard to reason about manually. More details here
Claude Code doesn't have a back door ? There are no security concerns when it comes to sharing the code with that AI service ?
That’s a very fair question.
We’re using the enterprise version of Claude Code, so it runs under enterprise security controls and contractual data protection terms. There’s no (hopefully) “back door” access to our systems, and it doesn’t get direct access to production infrastructure.
Access is restricted to specific repositories, and we’re careful about what gets shared. No secrets, no production credentials, and no customer data are exposed. It’s treated like any other third-party engineering tool, with security review and internal guardrails in place.
For us, it’s been more like an intelligent code navigation assistant than a blind code dump into the internet.
is going to be so much better when companies can run their own instances.
That’s an interesting thought. More control and ownership would definitely appeal to a lot of people, especially those who care about privacy and governance.
If you're tracking CWV during the migration: you could use GSC’s CWV report by URL group (e.g. home vs product vs checkout) so you can see if new Next.js routes perform better than legacy ones. Lab scores (Lighthouse) help debug; field data confirms real impact.
Oh that’s interesting 👀
We’re not tracking CWV that way yet, but grouping by URL in GSC during the migration sounds like a really smart approach. Definitely something I can look into as the migration progresses.
Thanks for the suggestion 🙌
Hi Ujja,
Thanks for this post. Loved it. Was very beneficial.
I have some quick questions:
Thanks again. best wishes
Hi Alptekin, really appreciate you reading it so closely 🙂
We still have Angular in place. It hasn’t been fully replaced yet. We’re incrementally migrating features to React via web components, so Angular continues to run the legacy parts. We did minor upgrades for stability, but no major refactor of the Angular app itself.
For data flow, we didn’t build Angular ↔ React “internal APIs.” Communication happens through props and custom DOM events at the web component boundary. Data fetching goes directly from React to GraphQL services, and Angular does the same for legacy flows.
Next.js is mainly handling authentication and shared API routes, not acting as a bridge layer between Angular and React.
Happy to dive deeper if helpful 🙂
thanks for your answers Ujja.
Massive front-end undertake. Great strategy for improvement 👏
Appreciate that 🙌
It definitely feels massive some days 😅 but breaking it down feature by feature makes it manageable. The strangler approach gave us breathing room instead of forcing a risky all-or-nothing rewrite.
Still a long road ahead, but at least now it feels structured rather than chaotic.
I like when that happens. Suddenly things are easier to understand and the development experience becomes enjoyable again.
Exactly. That moment when things start making sense again is such a relief 😅
hahahah yea
I speach as profane... just for reasoning, I dont fully agree...
I think a tractor is a good substitute for a hoe, and it doesnt matter if I forget how to swing the hoe, and for muscles and keep my body in movements I can go to the gym
OK the programmer wont see the bug if he doesnt understand the code...
OK AI can introduce vulnerabilities or logic bugs...
but this is the argue... AI is the tractor... I have to learn to drive it and use it well:
And so on... everything reduces something and increases something else.
I like the tractor analogy.
I agree that every major shift in tooling changes the skill set rather than removing it. We moved from manual debugging to IDEs, from raw HTTP to frameworks, from REST to GraphQL. Each layer abstracts something and demands new discipline elsewhere.
With AI, I don’t see it as replacing understanding. If anything, it amplifies the cost of not understanding. You still need architectural judgment, security awareness, and the ability to spot when something “feels wrong.”
For me, the real shift is moving from writing every line to reviewing, steering, and validating more intentionally.
Have you tried to upgrade to Angular 21 (with signals) first? 😂
There was one problem. Now there are two )
Haha, fair point 😄
We did look at upgrading first. The problem is the app is quite fragile at this point. It has a lot of tightly coupled pieces and third party dependencies that were built around older versions. Some of those libraries either do not support newer Angular versions properly, or upgrading them changes behavior in ways that break existing flows.
So a straight jump to Angular 21 with signals was not as simple as it sounds. It would likely have triggered a long chain of upgrades and regressions across payments, auth, and forms.
Embedding React does add complexity, I agree. But for us it is more controlled and incremental. We are slowly shrinking the legacy surface instead of trying to renovate a very fragile house all at once.
How are you handling shared state between the Angular and React parts during the transition?
We avoided a shared in-memory store between Angular and React and used a props, events, and slots model.
How it worked:
Props into web components: Angular passes config and attributes directly into the React web components.
Custom DOM events out: React components emit events (e.g., registration-complete) that Angular listens to for navigation or UI updates.Though we avoided this as much as possible.
Slots for layout/content injection: Some web components expose slots so Angular can provide headers, actions, or contextual UI without managing internal state. This was mainly because of the portal structure we have.
Shared session storage: Both sides read auth/session data from the same place (cookies or localStorage).
In short, no shared Redux-style store. Angular provides inputs via props and slots, React emits events, and session data is shared through browser storage.
Also wanted to add one more point about GraphQL. We’re mainly using it within the monorepo setup right now. We haven’t fully sunset the legacy backend yet, that’s still in progress.
I’ll be writing another blog soon that dives into that part of the journey 🙂