Framework-Agnostic Frontend Architecture: Migrate from Angular to React Without a Rewrite

MVC vs. “Just the View”

The classic Model-View-Controller pattern splits an application into three jobs. The model holds data and business rules, the view shows it, and the controller responds to user actions and updates the model. Frameworks have blurred these lines over the years, but the split is still the most useful lens for a migration.

Angular is a full framework. Out of the box it gives you components and templates (the view), services with dependency injection (a natural home for models and controller-like logic), a router, a forms system and an HTTP client. It's an opinionated, batteries-included toolkit, which is a big reason teams pick it.

React is, famously, “just the V.” It renders UI and leaves routing, data fetching, forms and state architecture to you or to other libraries. That flexibility is a strength, but it means an Angular → React move isn't like-for-like: you're replacing a whole toolkit with a view library plus several choices.

Here's the insight that makes everything else work: the expensive part of a migration is never the view. Templates can be translated almost mechanically. What hurts is business logic buried inside Angular services, tangled with dependency injection, RxJS pipelines and lifecycle hooks. If the model and controller logic lived in plain TypeScript from the start, a framework migration would only ever be a view migration. That's the whole idea of a framework-agnostic frontend.

The Framework-Agnostic Architecture

Think of the frontend as four layers. Only the top two know which framework is in use, and both are deliberately thin.

1. 4App shellOwns routing between old and new pages, authentication, and the page frame. Lets Angular and React live side by side during the move.
2. 3Framework adaptersTiny glue: a React hook or an Angular service that connects the core to each framework. Usually a few dozen lines each.
3. 2Shared UI (Web Components + design tokens)Buttons, inputs, cards, dialogs built once as standard custom elements and styled by CSS variables, usable in both frameworks.
4. 1Core (plain TypeScript)Models, business rules, validation, API clients and state stores. The most valuable code you own, and it never imports a framework.

1. A core in plain TypeScript

The core is everything that would still be true if you deleted every component: your data models, pricing and validation rules, API clients, and state. A store doesn't need a library to be useful. It needs a way to read the current value and a way to be told when it changes:

// core/task-store.ts: no React, no Angular, just TypeScript
type Listener = () => void

export function createTaskStore(initial: Task[]) {
  let tasks = initial
  const listeners = new Set<Listener>()

  return {
    getSnapshot: () => tasks,
    subscribe(listener: Listener) {
      listeners.add(listener)
      return () => listeners.delete(listener)
    },
    toggle(id: number) {
      tasks = tasks.map(t => (t.id === id ? { ...t, done: !t.done } : t))
      listeners.forEach(l => l())
    },
  }
}

export const taskStore = createTaskStore([])

This is the same pattern successful open-source projects use. TanStack Query, Table and Form each ship one framework-free core with small adapters for React, Angular, Vue and Solid. You can apply the same design to your own product code. If you prefer a library, choose one that is framework-agnostic itself (plain observable stores, state machines, or a signals library), not one that lives inside a framework.

2. Thin adapters for each framework

Each framework gets a small wrapper that turns the store into something idiomatic. In React that's one hook built on useSyncExternalStore, which exists precisely to connect React to stores it doesn't own:

// react/use-tasks.ts: the whole React adapter
import { useSyncExternalStore } from "react"
import { taskStore } from "../core/task-store"

export function useTasks() {
  return useSyncExternalStore(taskStore.subscribe, taskStore.getSnapshot)
}

In Angular it's an injectable service that mirrors the store into a signal, so templates stay reactive the modern Angular way:

// angular/tasks.service.ts: the whole Angular adapter
import { Injectable, signal, OnDestroy } from "@angular/core"
import { taskStore } from "../core/task-store"

@Injectable({ providedIn: "root" })
export class TasksService implements OnDestroy {
  readonly tasks = signal(taskStore.getSnapshot())
  private unsubscribe = taskStore.subscribe(() => this.tasks.set(taskStore.getSnapshot()))

  toggle(id: number) {
    taskStore.toggle(id)
  }

  ngOnDestroy() {
    this.unsubscribe()
  }
}

Notice what's missing: no business rules in either adapter. When the Angular side is eventually deleted, nothing of value goes with it. Signals are also worth watching here. Angular, Vue, Solid and Preact all use them, and there's an early-stage proposal to add signals to JavaScript itself, which would make shared reactive state even more natural across frameworks.

3. Shared UI with Web Components

Your design system is the other big asset worth protecting. Web Components (standard custom elements) run anywhere HTML runs. Angular has supported them for years via CUSTOM_ELEMENTS_SCHEMA, and React 19 closed the long-standing gap by fully supporting custom elements, including setting properties and listening to custom events. In practice that means one <ds-button> can serve both apps.

Start even simpler with design tokens as CSS variables (colours, spacing, radii, type). Custom properties pass through Shadow DOM, so the same tokens style Angular components, React components and Web Components alike. You'll see that working in the demo below.

4. An app shell for coexistence

During the migration, both frameworks have to run in production at the same time. There are three common ways to arrange that, from lightest to heaviest:

• React islands inside Angular. An Angular component mounts a React root into its element. The simplest way to ship your first React page.
• Components as custom elements. Angular Elements can expose Angular components as Web Components, and React components can be wrapped the same way, so either side can host the other.
• A shell with route-level ownership. A lightweight shell (or a micro-frontend setup like Module Federation or single-spa) decides per route whether Angular or React renders the page. Best for large apps and multiple teams.

Here's how small the island approach can be:

// angular/react-island.component.ts: host a React page inside Angular
import { Component, ElementRef, OnDestroy, AfterViewInit, Input } from "@angular/core"
import { createRoot, type Root } from "react-dom/client"
import { createElement } from "react"
import { SettingsPage } from "../react/settings-page"

@Component({ selector: "app-react-settings", standalone: true, template: "" })
export class ReactSettingsIsland implements AfterViewInit, OnDestroy {
  @Input() userId!: string
  private root?: Root

  constructor(private host: ElementRef<HTMLElement>) {}

  ngAfterViewInit() {
    this.root = createRoot(this.host.nativeElement)
    this.root.render(createElement(SettingsPage, { userId: this.userId }))
  }

  ngOnDestroy() {
    this.root?.unmount()
  }
}

Try It: One Store, Two Worlds

Below, one plain-TypeScript store drives two different UIs at once. The left panel is React. The right panel is a framework-free Web Component, the kind you could drop straight into an Angular template. Tick a task or add one on either side and watch the other update instantly.

A Safe, Step-by-Step Migration Plan

This is the strangler fig pattern applied to a frontend: grow the new system around the old one, one piece at a time, until the old one can be removed. Every phase ships to production and leaves the app in a working state.

1. 0

   Assess and set a safety net

   Inventory routes and modules, map where business logic lives, and capture baseline metrics (load time, error rate, conversion). Write end-to-end tests that drive the browser, not the framework. They will keep working after the migration and prove nothing broke.

2. 1

   Extract the core

   Move business rules, validation, API calls and state out of Angular services into plain TypeScript modules. The Angular services become thin adapters. Users see no change, which makes this phase low-risk and easy to ship in small pull requests.

3. 2

   Share the design system

   Start with design tokens as CSS variables, then move the most-used components (button, input, modal) to Web Components. Both frameworks now render the same look, so mixed pages don't feel stitched together.

4. 3

   Set up coexistence

   Introduce the app shell or a React-island wrapper inside Angular. Agree the contracts: how routes are owned, how auth tokens are shared, and how the two sides send events. Ship one trivial React page end-to-end to prove the plumbing.

5. 4

   Migrate route by route

   Move one page at a time, starting with high-value, low-risk ones. Release each behind a feature flag, roll it out gradually, compare metrics against the baseline, and keep the Angular version until the new one is proven. Rollback is a flag flip.

6. 5

   Decommission

   When the last route moves, remove Angular, its build tooling and the adapters you no longer need. Check the bundle size drops as expected and celebrate. This is the step teams forget to schedule.

Where AI Coding Agents Help (and Where They Don't)

In 2026, AI coding agents are genuinely good at the mechanical parts of a migration: translating an Angular template into JSX, turning a service into a hook, generating adapter boilerplate, and writing the end-to-end tests that prove behaviour didn't change. Used well, they can shrink the “migrate route by route” phase dramatically.

But they work best on exactly the architecture described above. When logic is tangled into framework code, an agent has to reinterpret it, and that's where subtle bugs creep in. When the core is already separated, the agent only translates the view, which is a much smaller and safer job. The architectural decisions (layer boundaries, coexistence strategy, rollout order) are still a human job, and every generated change still deserves a proper review.

Honest Trade-offs

When You Shouldn't Migrate at All

Modern Angular, with standalone components, signals and zoneless change detection, is a very different framework from the one many teams adopted years ago. Before committing to a move, check that the reason is real: hiring, ecosystem, or a product direction the current stack can't support, not just fashion. And for a small app with a handful of screens, a clean rewrite may honestly be cheaper than building coexistence. Either way, the core-plus-adapters structure pays off: it makes your code easier to test and reason about even if you never switch frameworks.