Why incremental migrations win
Most software projects today are not greenfield. Teams are constantly replacing or upgrading existing systems, and how that replacement is executed determines how much risk the business absorbs. An all-at-once "big bang" switchover concentrates that risk into a single, high-stakes event. An incremental approach — moving features or users over in phases while both systems run in parallel — spreads the risk out and lets you validate value early.
Incremental migration buys you four things:
- Smaller individual steps, so each one is easier to reason about and verify.
- A natural rollback path if something goes wrong.
- Early validation of both the technical implementation and the business impact.
- Migration without maintenance windows or downtime.
Big bang vs. incremental
A big bang migration replaces a system in one full switchover on a chosen date. All usage moves from the legacy system to the new one at once. The problems with this model are well known:
- Product flaws may surface only at the very end, when they are most expensive to fix.
- Rehearsals are hard to stage, so success is hard to predict in advance.
- You can pass a point of no return, forced to complete the migration even while serious issues are unfolding.
- The legacy system may need to go offline during the switch, costing business — and those maintenance windows often stretch as issues are discovered mid-migration.
Incremental migration comes in two flavors, which are often combined.
Vertical: feature-by-feature
Subsets of functionality are routed to the new system while the rest stays on the legacy one. Both systems operate in parallel, and the path each request takes — new or legacy — depends on whether its feature has been migrated.
Horizontal: user-by-user
Traffic is moved in shards, typically by entity. A "user" or "organization" is often the right unit because those divide cleanly with minimal cross-shard interaction. Complex migrations frequently layer horizontal sharding on top of a vertical feature-by-feature rollout.
The cost of going incremental
The main trade-off is extra engineering effort to make the new and legacy systems interoperate while they run side by side. That cost is most acute when the two systems need to access each other's data. If the systems have a shared datasource, choosing the right shard unit becomes the crucial decision that keeps data dependencies from leaking across the migration boundary.
Frontend migrations are easier
Frontend migrations are a special case: the backend stays stable, and only the rendering and processing layer changes. Because the "system of record" for stateful data doesn't move, these migrations are simpler to execute. The same principle extends beyond UIs — even when whole systems are replaced including their primary database, keeping the data warehouse layer stable while both legacy and new systems feed into it concurrently reduces the blast radius.
That stable analytics layer also gives you a trusted yardstick to measure the new system's performance against.
Escaping the monolith
A common scenario is a legacy system that never separated frontend from backend. If the goal is a new frontend, you may be able to introduce an API into the monolith and treat it purely as a backend while a new frontend is layered on top. This works because companies that bought into coupled monolithic systems often want more control over their UI — so they break out a frontend and demote the monolith to an API service.
The reverse proxy as the migration primitive
The key tool for incrementally migrating a web frontend is a reverse proxy, which lets one primary domain serve content originating from multiple web servers. Any migration to new serving infrastructure should start by placing a reverse proxy in front of everything, with zero change in functionality.
The proxy can live in three places:
- Co-located with the new frontend (recommended).
- On the legacy frontend.
- As a dedicated system introduced specifically for the migration.
Co-locating with the new frontend is best because it exposes the new infrastructure to production traffic without any expected behavior changes. When this stage is done, the new infrastructure is formally in production, but all actual logic still runs on legacy — which makes success easy to verify: there should be zero behavior change.
From there, the new system gradually takes over. In a web shop, you might start serving only product detail pages from the new system while everything else is proxied. That increment can be validated before moving on. Over time, the percentage of traffic the new system serves directly climbs until it hits 100%, at which point the proxy to the legacy system can be shut down.
Traffic migrations and dark launches
Traffic migrations are a horizontal incremental migration variant that uses dark launches: a secondary system is introduced while the existing system continues serving user-facing traffic. Both systems receive the traffic, and responses are compared to confirm identical behavior. Dark launches cost extra resources — both systems process the same requests — so typically only a subset of traffic runs through the dark path.
A dark-launch rollout follows a repeatable loop:
- Route a percentage of traffic to both systems.
- Compare responses for differences.
- Fix the new system's behavior if needed.
- Validate that the new system hits its goals, such as better latency or lower CPU usage.
- Switch that same percentage of traffic entirely to the new system.
- Repeat until 100% of traffic is migrated.
Migrating to Vercel is often a frontend migration of this kind. The platform's built-in reverse proxy supports staged adoption, and Edge Middleware can program the proxy to implement migration increments and adapt requests between new and legacy systems.
