Replatforming legacy SaaS without a full rewrite.
A working framework for migrating a five-year-old SaaS to a modern stack without stopping shipping. Stranglers, parallel runs, traffic gates, and the four moves that keep customers happy while engineering replatforms.
TLDR
Full rewrites consistently miss their deadlines and force a long feature freeze that competitors will use to eat your lunch. The replatform that ships keeps the old stack live, runs the new stack in parallel under traffic gates that move from 5% to 100% over months, and never stops shipping customer features in the meantime. Four moves: strangler, parallel data, gated traffic, contract test.
"We need to replatform" usually arrives in one of three flavors. The framework is broken in ways the team cannot fix in place. The infrastructure cost is climbing faster than revenue. Hiring is hard because the stack is unfashionable. All three are real reasons. None of them is a reason to do a full rewrite.
The full rewrite is the most expensive way to fail. Joel Spolsky's "things you should never do" essay holds up. The pattern repeats every cycle: most full rewrites miss the deadline by a year or more, ship something customers reject, or get killed before completion.
The replatform that works is structurally different. It does not stop the business. It does not need a feature freeze. It does not bet the company on the new stack working better than the old before customers see it. Here is the shape.
The two approaches, side by side.
Full rewrite
Six month feature freeze. Build new stack to feature parity with old. Cut over in one weekend. Customers experience the new stack only after it ships. Most of these projects miss the deadline by a year or get killed.
Strangler with traffic gates
New stack lives alongside old. Routes migrate one at a time. Traffic ramps from 5% to 100% per route. Old stack retires when its last route is gone. No feature freeze, ever. The business keeps shipping while engineering replatforms.
The four moves.
Strangler at the edge
Put a routing layer in front of the legacy stack. Cloudflare Workers, AWS API Gateway, or a Caddy in front. Every request still goes to the old stack. Nothing changes for users. What you have bought: the ability to route requests selectively without changing application code.
Parallel data, single source of truth
Stand up the new database alongside the old. Set up CDC (change data capture) so every write to the old DB streams to the new one within seconds. Reads still happen against the old. Now both stacks can serve the same data with the old as authoritative. Verify lag tolerances; most replatforms need sub-5 second propagation, some need sub-100ms.
Contract tests on the old stack
Before migrating any route, write contract tests that pin the existing behavior of that route. Request format, response shape, edge cases, error codes. The new implementation must pass the same contract before any traffic moves. This is the single biggest quality-of-replatform predictor; teams that skip it consistently ship customer-visible regressions on the routes they did not pin.
Gated traffic ramps
Move traffic in deliberate steps. 5% to internal users only. 5% to a friendly customer cohort. 25%, 50%, 100%. Each step holds for at least 48 hours with monitoring. If error rate or latency moves, gate stays. Most routes complete the ramp in two to four weeks; complex ones take longer. The whole replatform is the sum of these per-route ramps.
What the traffic gate looks like in practice.
What goes wrong, and the early signal.
Failure 1: Skipping contract tests
Team builds the new route, gates 5% traffic, sees that errors look fine, ramps to 100%. Two weeks later a customer reports a regression on an edge case the team forgot. Without contract tests pinning the behavior, every regression is found by customers, not by tests. Early signal: the team cannot list every edge case of the existing route from memory.
Failure 2: Letting the data layer drift
CDC pipeline lags during a high-write period. New stack reads stale data. Bug reports are intermittent and route-specific, hard to debug. Early signal: the team does not have a monitor on replication lag, or the monitor's threshold has never alerted in production.
Failure 3: Stopping mid-ramp because "it is good enough"
50% of traffic is on new stack. The team gets pulled to a customer feature. Replatform pauses. The double-running cost is meaningful, the team carries two stacks for a year, and the original goal (retire old) never lands. Early signal: the per-route ramp does not have a deadline; whichever PM is loudest reroutes attention.
What this costs.
A 12-month replatform of a non-trivial SaaS, executed with this framework, runs €300K to €800K in engineering cost at EU senior rates. The framework is more expensive in nominal infrastructure cost than a full rewrite (you run two stacks for months) but dramatically cheaper in expected value, because the ship probability is materially higher when the business never stops shipping.
For a studio engagement, the framework breaks into shippable chunks. The first move (strangler at the edge) is a four to six week fixed-scope build. The second move (parallel data) is six to eight weeks. Subsequent route migrations are typically four week chunks each. A founder running this against an internal team with senior advisory on architecture would buy a fractional CTO retainer to keep the framework honest while their team executes.
This is the framework that produced the Relokate HR replatform between 2024 and 2025. The technical detail of that engagement is on the platform page; the shape above is what shipped.
Replatforming a SaaS this quarter?
The studio takes one to two replatform engagements per year, scoped against this framework. From €30K capped at €60K for a single move, fractional CTO retainer for the multi-move arc. Discovery call is 30 minutes.
Read the build detail →