For webapps you would use a reverse proxy such as nginx or haproxy and replace your application page by page. Then configure the reverse proxy to send all requests to /home to go to the new stack and all other requests go to the old stack. Then flip the switch for every page you finish converting. For backend work, it's similar. You can have an api built in a new stack and it can just have a different endpoint or use a reverse proxy. Backend workers can pick up work from a different queue or you can switch the old job worker off and turn on the new one, and then monitor that everything is working as planned. The really important thing about the strangler pattern is that you need some easy way to turn on bits of functionality while turning off the corresponding old parts. It can be feature flags, it can be routing middleware. You can rip out the guts of the angular routing mechanism and use that to flip the switch.

Seconded. Took part in a moderately big rewrite with this strategy and it worked pretty well.

Identify key components and subsystems and rewrite them one by one. From the outside you seem to be switching over one REST endpoint after the other, but of course internally it's a bit more difficult, but applications often enough have enough parts that are not SO intertwined that you can do stuff like this. It's a bit related to how you break up a monolith. Find bigger, less coupled parts and shave them off and just touch the glue code.

There's no super easy way here. One way to get this done is find independent areas of the app that can be replaced without coupling. Then start building up as you go with the new system. At some point you'll be about 70% through of which you can decide if you want to make the jump and focus your efforts to completely uproot the old one.

Sorry for the abstract reference here, but it applies to almost any replatforming out there. In most cases it is a very expensive operation for a business and needs some major reasons in order to justify such a move.

Are there any examples out there for how to do this with React in an existing AngularJS codebase?

Instead of a Single Page Application, make it an MPA (multi-page application), each of which is basically a separate SPA. You get latency when swapping between sections of your app, but on some codebases (such as for an internally-used app), that's less of a problem.

We did something similar to this when we broke up our Ember application so that we could code new things in React. We still maintain our Ember codebase, but are rewriting parts of some routes in React, and adding all new things in the React app.

We deploy ours as separate pods in a Kubernetes cluster, but you could even host them on the same server with separate nginx routes.

The initial ramp up of this is a little frustrating, as it seems you're adding extra overhead to everything, the long term goal is to have infrastructure and workflow that supports having part of your app in The Old Proven Thing, and part in The New Hotness. This is valuable whether you're switching to React, or upgrading from Ember 2 to 3, etc, as it lets you upgrade a smaller set of dependencies, and experiment with things.

The company I'm working at is doing this currently. The new product is on the web and the old one is a full client windows program. The biggest hurtle will be to find the balance between largest/smallest pieces which can be transitioned as seamlessly as possible.

I'm surprised at what gets called a pattern these days. Fowler didn't describe it as a pattern, but just because Mr. Guru said it, it is now a pattern?

The ways it's referred to as a "StranglerApplication" in this post [1] does suggest more than "just saying it".

1: https://www.martinfowler.com/bliki/EventInterception.html