Figure 1.1: An API gateway routes traffic per-endpoint, migrating the monolith one function at a time.
Why “Rewrite Everything” Is the Wrong First Move
The instinct to rewrite a monolith from scratch is understandable and almost always wrong. A full rewrite freezes feature development for months, carries enormous risk, and often reproduces the same architectural mistakes in new syntax.
Every migration we run uses the strangler fig pattern, new serverless functions gradually take over responsibilities from the monolith, until eventually there’s nothing left to strangle.
- Months of feature freeze while the business waits
- The new system inherits the old system’s bugs, in different syntax
- A single high-risk cutover event instead of many small, reversible ones
- No way to validate the new architecture against real production traffic incrementally
An incremental migration trades a dramatic relaunch moment for something much more valuable: a migration nobody outside engineering even notices happening.
The pressure to modernize is real, but so is the risk of over-correcting, we've seen teams migrate a perfectly well-behaved steady-state service to serverless purely because 'serverless is the modern approach,' only to see effort and latency both get worse, which is exactly the outcome careful workload assessment is meant to prevent.
“The goal of a serverless migration isn’t a rewrite, it’s removing risk from the monolith one function at a time, without ever betting the whole system on a single cutover.”
The Strangler Fig Pattern in Practice
We put a routing layer in front of the monolith first, an API gateway that can direct specific endpoints to new serverless functions while everything else continues hitting the existing application unchanged.
- An API gateway placed in front of the monolith before any migration begins
- Endpoints migrated one at a time, starting with the lowest-risk candidates
- Shadow traffic to validate new functions against real production data before cutover
- Instant rollback to the monolith for any migrated endpoint if issues appear
This pattern is what turns a risky architecture migration into a series of small, individually reversible deployments.
Data consistency across the migration boundary needs explicit design attention, because a serverless function calling back into the still-running monolith's database introduces new failure modes around connection pooling and transaction boundaries that don't exist when everything runs in one process. We use connection pooling proxies specifically designed for serverless's bursty concurrency patterns, since a traditional database connection pool sized for a steady-state application can be quickly exhausted by serverless functions scaling instantly to hundreds of concurrent invocations.
Choosing What Actually Belongs in Serverless
Not every part of a monolith benefits from going serverless. We evaluate each service boundary against workload shape, bursty, event-driven workloads are ideal candidates, steady, latency-sensitive workloads often stay better served by containers.
- Good candidates: scheduled jobs, webhooks, image or file processing, notifications
- Better left alone: steady-state high-throughput APIs, cold-start-sensitive workloads
- A mixed architecture is normal and expected, not a sign of an incomplete migration
Forcing every workload into serverless because that’s the migration often creates worse performance than leaving well-suited services alone.
Deployment and rollback tooling gets rebuilt for this architecture too, a serverless function needs versioned deployments with instant rollback capability, since a bad deployment can affect thousands of concurrent invocations within seconds in a way a traditional rolling deployment to a fixed server fleet would never allow. We treat this tooling as part of the migration deliverable, not an afterthought configured once functions are already live.
Strategy 1: Event-Driven Function Candidates
Strategy 2: Steady-State Workloads Kept on Containers
Case Studies: Migrations With No Customer-Facing Outage
An e-commerce client’s monolith buckled every Black Friday under order-processing load that spiked 40x normal volume. We migrated the order-processing pipeline to serverless functions first, the following Black Friday, it auto-scaled without a single incident.
In each case, the first migrated service was chosen specifically because it was safe to get wrong, building confidence before tackling anything core.
A B2B logistics platform needed to process incoming EDI documents from hundreds of trading partners, each arriving on its own unpredictable schedule, a textbook bursty, event-driven workload that was previously forcing the monolith to run always-on worker processes sized for a peak load that only occurred a few hours a week. Migrating just this component to serverless functions cut compute spend on that workload by over many while improving processing latency.
- Media platform: video transcoding migrated to serverless, cutting processing effort by 55%
- Fintech: fraud-detection scoring moved to event-driven functions
- SaaS platform: background report generation migrated first as the lowest-risk candidate
Scope, Cold Starts & Observability
Serverless commercial setup can surprise teams that migrate without understanding their traffic patterns. We model expected invocation volume against serverless commercial setup before migrating anything.
Without this modeling, serverless can quietly become more expensive than the monolith it replaced, depending entirely on traffic shape.
We set explicit alerting on concurrency throttling and cold-start rates for every serverless function in production, failure modes that don't exist in traditional server architectures, and a team without monitoring built specifically for them can go weeks without realizing a function is silently throttling under load.
A mistake worth avoiding explicitly: migrating a workload to serverless before establishing observability for serverless-specific failure modes. Teams that skip this step often discover cold starts or throttling issues only after users complain, because traditional server monitoring dashboards don't surface these metrics by default. We stand up serverless-specific observability, invocation counts, cold start frequency, concurrency limits, before migrating the first workload, not after, so the team has a clear baseline to compare against as the migration progresses.
- Scope modeling against actual traffic patterns before migration
- Provisioned concurrency for latency-sensitive, user-facing functions
- Distributed tracing across the monolith and serverless functions
- Alerting tuned for serverless-specific failure modes
What to decide next
A monolith-to-serverless migration succeeds through incremental, reversible steps, not a single risky rewrite. The strangler fig pattern and upfront scope modeling are what make the migration boring in the best possible sense.
If your monolith is straining under a specific, bursty workload, that’s usually the right first candidate to migrate.
The migrations that go smoothly share a common trait: the team resisted the urge to migrate everything at once, proved the pattern on one low-risk workload first, and let that early win build the operational muscle needed for anything higher-stakes.
Serverless Migration Scope & Serverless vs Containers
As a serverless migration company, we commercial setup by workload, not by monolith size, migrating your bursty order-processing pipeline first is a very different, and cheaper, project than a full application rewrite.
The serverless vs containers decision isn't binary, most successful monolith to serverless migration services engagements end with a deliberately mixed architecture, each workload on whichever compute model actually fits its traffic pattern.
We open every migration with a workload audit, profiling your actual traffic patterns to categorize each service as a strong serverless candidate, a poor fit, or genuinely ambiguous pending further data. The first migrated workload is always chosen specifically to be low-risk and high-learning, proving the strangler fig pattern and gateway routing approach before touching anything business-critical. Each subsequent migration follows the same validated pattern: shadow traffic, gradual cutover, and an instant rollback path kept live until the team is fully confident in the new implementation.
- Full incremental migration: scoped per workload using the strangler fig pattern
- Serverless wins on scope for bursty, event-driven workloads
- Containers often win on scope for steady, high-throughput, latency-sensitive services
