<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Migration on Severin Bucher | Blog</title><link>https://severinbucher.com/tags/migration/</link><description>Recent content in Migration on Severin Bucher | Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 11 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://severinbucher.com/tags/migration/index.xml" rel="self" type="application/rss+xml"/><item><title>Upgrading a Legacy Monorepo to React 18: What Nobody Warns You About</title><link>https://severinbucher.com/posts/upgrading-a-legacy-monorepo-to-react-18/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><guid>https://severinbucher.com/posts/upgrading-a-legacy-monorepo-to-react-18/</guid><description>&lt;p>React 18 shipped in March 2022. We merged our upgrade in April 2026. If you do that math, yes, we were four years behind. This is a post about what that upgrade actually looked like across a large, multi-generational codebase, and the specific issues that ate most of the time.&lt;/p>
&lt;p>Spoiler: the &amp;ldquo;breaking changes&amp;rdquo; in the official React 18 migration guide are the easy part.&lt;/p>
&lt;h2 id="the-starting-point">The Starting Point&lt;/h2>
&lt;p>Our frontend isn&amp;rsquo;t one app. It&amp;rsquo;s four generations of React code living in the same monorepo, piled up over years of product growth:&lt;/p></description></item></channel></rss>