Byggdagboken strangler-fig migration
I moved a live web platform from PHP and Angular.js to Next.js, one route at a time.
- Senior Software Engineer, client engineering lead
- 2024–2026
- Architecture
Route-level canary
A CloudFront Function sends this share of requests to the new Next.js client. The rest stays on the legacy monolith.
Problem
The Byggdagboken web platform was a PHP and Angular.js monolith.
My role
I led client engineering at Byggdagboken, for web and mobile, and a small team of app developers. I owned the delivery roadmap and backlog with management. I led this migration.
Constraints
The product was live, so the migration could not stop it.
Decisions
I used the strangler fig pattern. The new client took over one route at a time, and the monolith kept serving the rest.
The monolith. Web traffic went through CloudFront to the monolith. It ran PHP on the server and Angular.js in the browser.
Route-level canaries. A CloudFront Function sends a percentage of each migrated route's traffic to the new Next.js web client. The rest stays on the monolith.
A backend-for-frontend. The native apps talk to a Node.js BFF, which aggregates their data across the microservices.
One sign-in. I moved sign-in to OAuth2 and OpenID Connect with the Authorization Code flow and PKCE. Redis holds the short-lived tokens.
Also at Byggdagboken
- I introduced new workflows and release routines. The releases that followed had zero major incidents.
- I automated the localization pipeline, and we launched 10 new languages.
- I rebuilt the apps and the web client to work local-first.