Migrating SA Apps to Next.js App Router

April 4, 2026

Migrating SA Legacy Web Apps to the Next.js App Router: A Case Study

Many established businesses in South Africa are currently sitting on "technical debt mountains." I see 10-year-old Laravel apps, legacy WordPress setups, and early React "Pages Router" applications that are slow, hard to maintain, and impossible to scale.

In 2026, the standard for modernizing these apps is the Next.js App Router. I recently led a migration for a large SA logistics provider. Here is the senior-level framework we used to move from a legacy setup to a high-performance modern architecture.

1. The "Why": Beyond the Hype

The primary driver for this migration wasn't just "using new tech." It was:

Performance: Moving to Server Components reduced the JavaScript bundle sent to the client by 65%. For users in rural areas on 3G, the app became usable for the first time.
Developer Velocity: Next.js's built-in patterns (Layouts, Loading states, Error boundaries) meant the team could ship features 30% faster.
SEO: The logistics provider needed their "tracking" and "service" pages to rank locally. Server-side rendering (SSR) in the App Router is best-in-class for SEO.

2. The Strategy: "The Strangler Fig" Pattern

We didn't do a "Big Bang" rewrite. That is a recipe for disaster. Instead, we used the Strangler Fig pattern:

The Proxy: We set up the new Next.js app on a subpath (or used a proxy like Cloudflare/Vercel) to sit in front of the legacy app.
Piece-by-Piece: We migrated one route at a time. We started with high-impact, low-complexity pages like the "About," "Contact," and "Blog."
The Data Bridge: We built a temporary internal API that allowed the new Next.js app to talk to the legacy database while we worked on a modern Supabase/PostgreSQL backend.

3. Handling the "App Router" Learning Curve

The shift from "Client Components" to "Server Components" is the biggest hurdle.

The Rule: Data fetching happens on the server. Interaction (buttons, forms, state) happens on the client.
The Mistake: Many devs just put
```
'use client'
```
at the top of every file. This defeats the purpose. We spent the first two weeks of the project training the internal team on "Server-First" thinking.

4. The "Local" Win: Edge Middleware

For our SA client, we used Next.js Middleware to handle regional redirects and bot protection at the edge. By running this logic on Vercel's edge nodes (including the Cape Town node), we significantly reduced the time-to-first-byte (TTFB) for local users.

5. The Result: 6 Months Later

Lighthouse Score: Jumped from 45 to 98.
Maintenance Cost: Server costs dropped by 40% due to more efficient data handling.
User Satisfaction: Support tickets related to "app slowness" vanished.

Conclusion

Migration is a marathon, not a sprint. If your legacy app is hurting your bottom line in 2026, the App Router is the path forward. It’s not just about the code; it’s about rebuilding the "tech plumbing" of your business for the next decade.

Ready to start your migration? Let's build the roadmap.

Frequently asked questions

What drove the decision to migrate this specific SA logistics provider's app?

The primary reasons weren't just about new tech. Performance was a big deal: Server Components cut the JavaScript bundle by 65%, making the app actually usable for rural users on 3G. Developer velocity also improved, with teams shipping features 30% faster due to Next.js patterns. Plus, better SEO for tracking and service pages was crucial for local ranking.

How did you manage the data during the migration from the old system to Next.js?

We built a temporary internal API. This "data bridge" allowed the new Next.js app to communicate directly with the legacy database while we worked on building out a modern Supabase/PostgreSQL backend. This avoided a risky, all-at-once data switch.

What was the biggest challenge for the development team learning the App Router?

The shift from Client Components to Server Components was the main hurdle. Many developers initially just slapped

'use client'

on everything, missing the point. We spent two weeks training the team on "Server-First" thinking, emphasizing that data fetching happens on the server, and interaction on the client.

How did Next.js Middleware specifically benefit the SA client?

We used Next.js Middleware at the edge for regional redirects and bot protection. Running this logic on Vercel's edge nodes, including the one in Cape Town, significantly cut down the time-to-first-byte (TTFB) for local users. This means a faster initial load for everyone in South Africa.