From Netlify to Vercel: My Migration Story
Why I migrated my Next.js applications from Netlify to Vercel and the benefits I've experienced along the way.
I ran a Next.js app on Netlify for a long time and, for the most part, it worked. Netlify is a solid platform and I wouldn’t hesitate to recommend it for many use cases. But as my app grew more dynamic and leaned further into modern Next.js patterns, the cracks started to show.
This wasn’t about a bad migration experience or a single breaking change. It was about ongoing friction. Small issues that kept resurfacing, especially where Netlify’s abstractions collided with how Next.js actually wants to behave.
Eventually, it became clear that the platform was shaping my architectural decisions more than I was comfortable with.
Netlify Forms vs Next.js Reality
Netlify Forms are great in principle. Drop a form into your markup, add an attribute, and submissions just work. For static sites, this is brilliant.
In a Next.js app, though, things get messy quickly.
Forms rendered via React components don’t always play nicely with Netlify’s build-time form detection. This often leads to workarounds like hidden static forms, duplicated markup, or fragile build hacks that exist purely to keep Netlify happy.
Spam handling adds another layer of friction. Netlify’s built-in spam protection is helpful, but tightly coupled to how forms are submitted and processed. Once you start introducing client-side validation, custom submission flows, or server actions, you’re effectively fighting the platform.
At some point I had to ask why my form architecture was being dictated by hosting constraints instead of application needs.
Plugins, Build Hooks, and Framework Interference
One of Netlify’s strengths is its plugin ecosystem. The flip side is that plugins can interfere in subtle and surprising ways.
In a Next.js context, plugins that modify headers, inject scripts, alter build output, or hook into deploy stages can cause behaviour that’s hard to trace. When something breaks, it’s not always obvious whether the issue is Next.js, a plugin, or Netlify’s build pipeline itself.
This becomes more noticeable as you adopt newer Next.js features. Server components, edge rendering, image optimisation, and routing behaviour all expect a fairly opinionated runtime. Adding another layer that mutates output or execution can introduce inconsistencies between local development and production.
Nothing was catastrophically broken, but debugging became slower and more mentally expensive than it should have been.
Spam, Bots, and the Limits of “Built-In” Solutions
Spam protection is one of those things you don’t think about until you really have to.
Netlify’s approach works well for simple forms, but it becomes restrictive when your app needs finer control. Custom bot detection, rate limiting, or integration with third-party services often ends up awkwardly bolted on rather than cleanly integrated.
In contrast, handling forms server-side within Next.js made it much easier to reason about validation, abuse prevention, and data flow as part of the application itself rather than a hosting feature.
That shift alone simplified my mental model of the system.
When the Platform Stops Being Invisible
The common thread across these issues was that Netlify stopped being invisible.
I was thinking about platform constraints during feature design. I was adjusting implementation details to satisfy build behaviour. I was second-guessing whether a bug lived in my code or somewhere in the hosting layer.
That’s not a failure of Netlify. It’s a sign that the app had outgrown the platform’s sweet spot.
Netlify shines when you want a powerful, framework-agnostic platform with lots of batteries included. My app needed something narrower and more opinionated.
Why Vercel Made More Sense for This App
Moving to Vercel wasn’t about chasing performance benchmarks or hype. It was about alignment.
Vercel’s platform is designed around Next.js assumptions. Forms, server logic, rendering behaviour, and deployment all live within the same conceptual model. I wasn’t working around platform features, I was using the framework as intended.
There were fewer hidden layers. Fewer plugins modifying behaviour. Fewer questions about whether production matched development.
The app felt simpler, even though the codebase hadn’t changed much.
This Isn’t a Verdict on Netlify
Netlify is still excellent at what it does. For static sites, content-heavy projects, marketing pages, and multi-framework environments, it’s often the right choice.
But for a Next.js app that relies heavily on server logic, modern rendering features, and custom control over things like forms and spam handling, the trade-offs started to outweigh the benefits.
Switching platforms wasn’t about Netlify being bad. It was about choosing a tool that interfered less with how the app wanted to be built.
Sometimes the best hosting decision is the one that lets you stop thinking about hosting altogether.