Replatforming a SaaS Product in 2026: A Decision Guide

TL;DR: Most SaaS teams replatforming in 2026 should default to the Strangler Fig pattern ($50K-$200K, 4-8 months) for partial monolith decomposition. A full rewrite is only justified when the stack is functionally dead or the data model itself is wrong ($200K-$800K, 6-12 months). Lift-and-shift earns its place only when cost reduction or data-center exit is the explicit goal, not modernization ($20K-$80K, 2-4 months). MarsDevs has run replatforming engagements for SaaS teams across Django, Rails, Node, and Java monoliths since 2022. The decision frame, the three engagement tiers, and the failure modes are below.

What "Replatforming" Actually Means (And What It Doesn't)#

Replatforming is the targeted modernization of a working SaaS product by moving it to a better foundation (new runtime, new data layer, or new service boundaries) while keeping the product live and customers unaffected. It is neither a full rewrite (which discards the working product) nor a lift-and-shift (which keeps the same code, just on different infra).

That distinction matters because most agency conversations collapse the three approaches into one word. They are not interchangeable. They have different cost shapes, different risk profiles, and different definitions of done. The AWS Prescriptive Guidance 7 Rs framework lists seven migration strategies (Rehost, Replatform, Repurchase, Refactor, Retire, Retain, Relocate). Three of them dominate SaaS conversations. The table below is the version most teams need.

A useful test: if your engineering team cannot name which of those three rows they are picking, they are not yet ready to start. Pick the row before scoping the work.

Why SaaS Teams Replatform in 2026 (The Five Forcing Functions)#

Five forcing functions push a SaaS into replatforming in 2026: deploy time creeping past 20 minutes, multi-tenant noisy-neighbor incidents at the data layer, a scaling ceiling on a single bottleneck, vendor lock-in or framework end-of-life, and AI-readiness gaps the current architecture cannot host. Most teams hit two or three of these at once. Replatforming usually starts when the third one shows up in a board meeting.

1. Deploy time above 20 minutes. Iteration velocity dies first. When the deploy pipeline takes 25-45 minutes, engineers batch changes, hotfixes stall, and the team quietly shifts to "ship Fridays." That is the canary. (CI/CD foundations for startups usually need the first round of work.)

2. Multi-tenant noisy-neighbor incidents. One tenant runs a query that takes down the database for everyone else. Then it happens again. Then your three biggest accounts ask for "dedicated infrastructure," and you have a renewal at risk. The multi-tenant vs single-tenant SaaS decision re-opens, except now you are renegotiating it under fire.

3. Scaling ceiling on a single bottleneck. A single Postgres write throughput. A single-process queue worker. A single Redis instance fronting the whole app. Vertical scaling has hit the wall, and the team has run out of ways to make the bottleneck go away without changing the architecture.

4. Vendor lock-in or framework end-of-life. Heroku-era stacks getting expensive. Rails 4 with no upgrade path. Python 2 holdovers that nobody can patch. A managed service the vendor deprecated. The cost of staying still has crossed the cost of moving.

5. AI-readiness gap. The product roadmap now includes inference, RAG, agentic workflows, or model-routing. The current architecture has no clean place to put any of it. The team realizes the modernization is not optional. (SaaS architecture patterns for startups need a hosting layer that does not yet exist in the codebase.)

When two of these forcing functions hit in the same quarter, replatforming is no longer a choice the team is making. It is one the business is making for them.

Strangler Fig vs Rewrite vs Lift-and-Shift: The Decision Frame#

Default to Strangler Fig when the product is alive and the team has 4-8 months ($50K-$200K, partial monolith decomposition). Choose a full rewrite only when the data model itself is wrong or the stack is unmaintainable ($200K-$800K, 6-12 months). Pick lift-and-shift only when the goal is cost reduction or data-center exit, not modernization ($20K-$80K, 2-4 months).

The decision turns on four variables: stack age, customer-facing risk tolerance, runway, and whether the data model needs to change. The table below is the version we walk every CTO through in a discovery call.

Three reference points are worth naming. Martin Fowler's original Strangler Fig essay (2004) coined the pattern. Microsoft Learn's Strangler Fig pattern doc is the canonical Azure version. Anti-corruption layers and bounded contexts trace back to Eric Evans' Domain-Driven Design (2003); those primitives are what makes the façade routing work without leaking legacy semantics into the new services.

The load-bearing third-party data point: analysis of 41 enterprise strangler projects (2022-2025) from Modernization Intel found that 68% stalled before 90 days, and projects that extracted under 5% of monolith functionality in the first 90 days hit a 92% failure rate. That same dataset reports a 76% success rate across 29 projects that did extract early, with a median $640K in annual savings post-migration. Early velocity is the single strongest predictor of success.

One more reference point for the contrarian case: Amazon Prime Video's 2023 re-monolithing of its audio/video monitoring service cut infrastructure cost by roughly 90% when the team consolidated microservices back into a monolith. Replatforming has a direction, but the direction is not always toward more services. It is toward fewer load-bearing assumptions. The microservices vs monolith decision frame for startups is the architecture choice that precedes replatforming.

The Three MarsDevs Replatforming Tiers (With Real Costs and Timelines)#

MarsDevs runs replatforming engagements in three tiers. Light ($20K-$80K, 2-4 months) is a single-service refactor or framework upgrade. Standard ($50K-$200K, 4-8 months) is partial monolith decomposition into 3-5 services with staged data migration. Heavy ($200K-$800K, 6-12 months) is full re-architecture, multi-stage data migration, observability rollout, and team training. All three are typically staffed by a 7-8 person pod ($20K-$35K/month) sized down for Light or scaled up for Heavy.

A note on what these bands include and exclude. The cost covers the engineering pod. It does not cover cloud bills, third-party tooling (Datadog, Snowflake, etc.), or customer-facing product work that happens in parallel. Most teams budget another 15-25% on top for those line items.

If you are comparing replatforming to a full rebuild from scratch, the comparison is not close. A new SaaS platform build runs $10K-$50K for the lean version and well into six figures for anything complex (what a new SaaS costs to build from scratch breaks that out). Replatforming preserves three to five years of domain logic, customer data, and revenue. The fact that it costs less than a rebuild is almost a side effect; the bigger point is that it costs less than the wrong rebuild.

Scoping a replatforming? MarsDevs runs a two-week paid discovery and tells you which tier you actually need before you commit a budget. Talk to our engineering team.

Light Replatforming: A Single-Service Refactor in 10 Weeks#

Light replatforming is the right tier when one bounded context inside the monolith is causing 80% of the pain. The fix is to extract that one context behind an API façade, replace the implementation, and leave the rest of the monolith alone. The engagement closes in 8-12 weeks with a 4-person pod.

Client archetype: Series A B2B SaaS, vertical SaaS in HR-tech and people-ops at roughly $4-6M ARR. The extracted module was the legacy billing system. Engagement length: ~10 weeks. Team composition: 2 senior engineers, 1 PM, 1 DevOps.

The Problem. The team had a working Django monolith with one module that had become a velocity tax on the rest of the codebase. Every change risked breaking the other modules. Onboarding new engineers to it took weeks because the implicit coupling was undocumented. The CTO had been told three times that a full rewrite was the answer, and three times had said no.

What We Shipped. We extracted the troubled module into a standalone service behind an API façade. The monolith kept handling the rest of the product. The new service got its own data store, its own deploy pipeline, and a thin anti-corruption layer translating between the legacy schema and the new domain model. We shipped behind a feature toggle, ran parallel for two weeks, then cut traffic over.

What Worked. Scoping the work to a single bounded context made the timeline defensible. The team committed to a hard deletion date for the anti-corruption layer (it shipped, served its purpose, and got deleted six weeks later). Nobody on the customer side saw any change.

What Went Sideways. An undocumented Celery task in a sibling app was reading directly from the billing tables every 15 minutes. We discovered it during the week-4 staging cutover when the new service started missing those reads and a downstream report quietly stopped updating. The fix routed the Celery task through the new API in week 5. The fix took a sprint we had not budgeted for. We absorbed it.

The Numbers. ~10 weeks. Cost in the Light tier band ($20K-$80K). One service extracted. Deploy time on the extracted service dropped from the monolith's 22-minute pipeline to under 4 minutes. Zero customer-facing incidents during the migration. This kind of single-service work is also where most of our real cost of our last 5 SaaS builds ended up doing follow-on work.

Standard Replatforming: Decomposing a Monolith in 7 Months#

Standard replatforming is the load-bearing tier. It is the work most Series B SaaS teams actually need: decompose 3-5 services out of the monolith, run dual-write data migration through an anti-corruption layer, ship behind feature toggles, and keep the product live throughout. The engagement runs 6-8 months with a 7-8 person pod.

Client archetype: Series B multi-tenant SaaS, B2B vertical SaaS in legaltech and contracts at $15-25M ARR. A 6-year-old Django monolith (1.11 origin, upgraded to 3.2 mid-engagement) serving roughly 340 tenants. Four services extracted, in priority order: billing, notifications, search (Elasticsearch-fronted), audit log. Engagement length: ~7 months. Team composition: 3 senior engineers, 2 mid engineers, 1 PM, 1 DevOps, 1 UI/UX.

The Problem. A Django monolith that had served the company well for four years had hit three forcing functions at once: deploy time at 32 minutes, two noisy-neighbor incidents in the previous quarter, and a Postgres write-throughput ceiling that the team had already hit twice on peak days. The board had given the CTO 8 months and a budget envelope. A full rewrite was off the table.

What We Shipped. We applied the Strangler Fig pattern in five extractions, in priority order, with the highest-traffic vertical slice first (this matters; the Modernization Intel data is unambiguous that <5% extraction in the first 90 days predicts a 92% failure rate). Each extraction got its own bounded context, its own dual-write phase, its own cutover window, and its own anti-corruption layer with a written deletion date. We instrumented every service before extracting the next one. The data layer split happened in three staged migrations using parallel run and reconciliation jobs.

What Worked. Picking a thin, high-traffic vertical slice for the first extraction was the right call. Velocity in the first 90 days was the strongest predictor of the second-half cadence. The team committed to feature freeze on the legacy product surfaces being extracted (PM owned enforcement). The multi-tenant vs single-tenant SaaS tenancy model held; we did not need to re-tenant during the extraction.

What Went Sideways. Dual-write reconciliation drift on the billing service. Two webhook retries landed inside the same Redis-lock window and produced an idempotency-key collision: the new service wrote one invoice line, the old service wrote a second. The eval harness comparing old/new invoice totals caught the drift within 12 hours. We fixed it by rotating idempotency keys with a deterministic suffix derived from the webhook payload hash. We caught it in the parallel-run window. The fix shipped before cutover. Zero customer incidents.

The Numbers. ~7 months. Cost in the Standard tier band ($50K-$200K). 4 services extracted. Deploy time per service dropped to under 8 minutes. P95 latency on the highest-traffic surface (search) dropped from 920ms to 410ms. Zero customer-facing downtime. The microservices vs monolith decision frame for startups had been re-litigated; the answer was "yes, but only for these 4 services."

Heavy Replatforming: A Full Re-Architecture Across 10 Months#

Heavy replatforming is the tier when the stack itself is no longer survivable. The framework is end-of-life, the data model is wrong in foundational ways, and the team needs not just new code but a new operating model. The engagement runs 9-12 months with a pod that scales up to 10 across phases.

Client archetype: Series C-D scale-up, B2B SaaS in workforce management and scheduling at roughly $28-45M ARR. Original stack: Rails 4 on Heroku, single Postgres, Redis queues. Target architecture: containerized services on AWS ECS Fargate, event-driven integration via EventBridge + SQS, managed Postgres on RDS Aurora, observability on Datadog. Engagement length: ~10 months. Team composition: scaled to 10 across phases.

The Problem. A 6-year-old monolith on a framework that the customer's own engineering team could no longer hire for. Two acquisition attempts had stalled on technical due diligence. The PE-backed board had set a budget envelope in the seven figures and made one thing clear: customers were not to see any change during the work.

What We Shipped. Full re-architecture in four phases. Phase 1: containerize the monolith and move it to managed infra (lift-tinker-shift; this bought breathing room and surfaced the observability gap). Phase 2: introduce an event bus and an API gateway as the new integration surface. Phase 3: extract the four highest-value services using Strangler Fig (this is where the Standard-tier playbook applies inside the Heavy engagement). Phase 4: observability rollout plus team training so the customer's own engineers could own the new architecture by the end of the engagement.

What Worked. Sequencing was everything. The lift-tinker-shift in phase 1 was the unsexy decision that made everything else possible. Observability before extraction (not after) caught two bugs that would have shipped silently otherwise. The team training in phase 4 was scoped as part of the engagement, not a bolt-on; the customer's engineers paired with our pod on the last two service extractions and owned the post-engagement roadmap.

What Went Sideways. An 8-hour nightly batch ETL had no equivalent in the new architecture. The team had assumed it could be replatformed as-is, but it depended on a Postgres extension that is not available on RDS Aurora. We re-designed it mid-stream as a Step Functions workflow with Aurora-compatible queries. We re-scoped that phase by two weeks. The total engagement stayed inside the original budget envelope.

The Numbers. ~10 months. Cost in the Heavy tier band ($200K-$800K). Full re-architecture across 4 phases. Zero customer-facing downtime. The customer's engineering team owned the new platform by month 12. The SaaS architecture patterns for startups that anchor the new platform are the same ones a greenfield team would have picked on day one; the difference is they got there without throwing the working product away.

Six Failure Modes We Have Hit (And How We Fixed Them)#

Replatforming fails in predictable ways. Every engagement we have run has hit at least one of these six. The fixes are not exotic. They are about commitment and sequencing more than about technology.

1. The 90-day stall. Modernization Intel's analysis is unambiguous: 68% of strangler projects stall before 90 days, and <5% extraction in the first 90 days predicts a 92% failure rate. Fix: pick a thin, high-traffic vertical slice as the first extraction. Instrument it before extracting anything else. Velocity in the first 90 days is the predictor that matters.

2. Dual-write drift. Parallel-run data divergence between old and new stores. The new service writes; the old service writes; reconciliation surfaces a 0.4% drift that nobody can explain. Fix: idempotent writes, a reconciliation job that runs continuously, and a hard cutover deadline the team commits to in writing. Drift that is allowed to live indefinitely will live indefinitely.

3. The half-migrated monolith. Project loses funding at month 5. The team now owns two systems for the next 18 months. Fix: scope every extraction to be independently shippable. Never start an extraction you cannot finish in a single quarter. Half-extracted services are worse than the original monolith.

4. Anti-corruption layer rot. The façade was supposed to be transitional. Two years later it is a permanent feature with its own test suite and its own bug backlog. Fix: every façade gets a deletion date in the engagement charter. The deletion ships as a tracked work item, not an aspiration.

5. The rewrite that became a re-imagining. The team treats the rewrite as a chance to fix product decisions the PM never agreed to. Scope creeps. The 6-month rewrite ships in 14 months and is unrecognizable from the original brief. Fix: feature freeze on the legacy product for the duration of the rewrite. PM owns enforcement. The rewrite is not the time to redesign the product.

6. Replatforming with the same team that built the original. Cognitive lock-in. The team that built the architecture cannot see the architecture; they see the history of decisions. Fix: at minimum, rotate the architect. Better, bring in an outside engineering pod for the extraction phase. (This is where MarsDevs typically gets called.)

We have hit each of these failure modes ourselves. A two-week paid discovery surfaces which ones your codebase is exposed to before you commit a budget. Scope a discovery with our engineering team.

When NOT to Replatform: Four Anti-Patterns#

Don't replatform if you have under 12 months of revenue history (you don't yet know the right boundaries), if your engineering team has under 8 people (you cannot afford the split focus), if your runway is under 9 months (you will run out mid-migration), or if the real problem is product-market fit rather than code.

Anti-pattern 1: Replatforming before product-market fit. The product is 14 months old. Revenue is below $1M ARR. The team thinks the architecture is the problem. It is not. The product is still finding its boundaries; replatforming now locks in the wrong ones. What to do instead: stay on the current stack and instrument the failures. The forcing functions that justify replatforming will declare themselves. Do not pre-empt them.

Anti-pattern 2: Replatforming with a 6-engineer team. The math does not work. To run a Standard-tier replatforming you need a pod of 7-8 that can focus on the work without the legacy product stalling. A 6-engineer team that tries to split focus ends up shipping neither side. What to do instead: bring in an outside pod for the extraction phase, or wait until you have hired the headcount.

Anti-pattern 3: Replatforming with under 9 months of runway. This is failure mode 3 in the previous section. You will run out mid-migration. The half-extracted monolith is worse than the monolith you started with. What to do instead: lift-and-shift only (the Light tier), or defer the work until after the next round.

Anti-pattern 4: Replatforming the architecture when the problem is the product. Customers are churning. The team blames the codebase. The actual problem is that the value proposition is unclear, the onboarding is broken, or a competitor shipped a better feature. What to do instead: fix the product. Code does not retain customers; the product does. (Amazon Prime Video's 2023 re-monolithing is the canonical reminder that replatforming has a direction, and the direction is not always "more architecture.")

FAQ#

What does replatforming actually mean for a SaaS product? Replatforming is targeted modernization of a working SaaS by moving it to a new runtime, data layer, or service boundaries while keeping customers live. It is not a full rewrite (which discards the working product) and not lift-and-shift (which keeps the same code on new infra).

What is the Strangler Fig pattern, in one sentence? The Strangler Fig pattern incrementally replaces a legacy system by routing traffic through a façade that gradually shifts requests to new services, until the legacy is dead. Coined by Martin Fowler in 2004; documented in AWS Prescriptive Guidance and Microsoft Azure Architecture Center.

How long does it take to replatform a SaaS product? At MarsDevs, replatforming runs three tiers. Light (single-service refactor): 2-4 months. Standard (partial monolith decomposition, 3-5 services): 4-8 months. Heavy (full re-architecture, multi-stage data migration, observability): 6-12 months. Enterprise programs that attempt full rewrites typically run 12-36 months.

How much does it cost to migrate a monolith to microservices? At MarsDevs, $20K to $800K depending on tier. Light: $20K-$80K. Standard: $50K-$200K. Heavy: $200K-$800K. Modernization Intel's data on 29 successful strangler projects shows median $640K annual savings post-migration; failed projects had a median sunk cost of $2.1M.

Strangler Fig vs full rewrite, which should I pick? Default to Strangler Fig. Pick a full rewrite only when the data model itself is wrong, the stack is unmaintainable (end-of-life framework, no hireable talent), or the codebase is unrecoverable. Full rewrites have a markedly worse track record on timeline and budget than incremental replacement.

When should I NOT replatform? Don't replatform if you have under 12 months of revenue history (boundaries unclear), under 8 engineers (cannot afford split focus), under 9 months of runway (you will run out mid-migration), or if the real problem is product-market fit rather than code.

What's the difference between lift-and-shift, replatform, and refactor? Lift-and-shift moves code as-is to new infra. Replatforming makes small targeted changes during the move (for example, self-managed Postgres to managed RDS). Refactor re-architects for cloud-native (microservices, containers, serverless). The 7 Rs framework from AWS Prescriptive Guidance lists all seven migration strategies.

Can a replatforming run without a customer-facing freeze? Yes, that is the whole point of the Strangler Fig pattern. Traffic shifts through a façade incrementally; customers see no change. Parallel-run, dual-write, and feature toggles cover the data-migration phase. Full rewrites are different and almost always require a cutover window.

What's the most common failure mode in a replatforming? The 90-day stall. Analysis of 41 enterprise strangler projects (2022-2025) found 68% stalled before 90 days; projects extracting under 5% of monolith functionality in the first 90 days had a 92% failure rate. Early velocity is the strongest predictor of success.

How big a team do I need to replatform? For the Standard tier (4-8 months, $50K-$200K), MarsDevs ships a 7-8 person pod: 3 senior engineers, 2 mid engineers, 1 PM, 1 DevOps, 1 UI/UX. Smaller pods handle Light tier (single-service refactor); Heavy tier scales to 10+ across phases.

Where to Go Next#

Replatforming is the work most Series A-D SaaS teams will hit at least once. The decision frame above keeps it from becoming the work that ends the company. The three tiers (Light, Standard, Heavy) cover the engagement shapes we see most often. The failure modes are the ones we have hit and fixed.

MarsDevs is a product engineering partner for early- and growth-stage businesses. We embed senior engineering pods that scale software from MVP to platform, with multi-quarter engagements, outcome ownership, and AI-native by default. Founded in 2019, we have shipped 80+ production systems across 12 countries, including replatforming projects, multi-year SaaS builds, and AI integrations into existing products.

If your monolith is straining and you are scoping the next quarter, the next move is a two-week paid discovery. We run the codebase, the data layer, the deploy pipeline, and the team dynamics, and we come back with a written recommendation on which tier you actually need and what the realistic timeline looks like. Talk to our engineering team.

Related reading:

• Microservices vs monolith decision frame for startups
• SaaS architecture patterns for startups
• Multi-tenant vs single-tenant SaaS decision
• The real cost of our last 5 SaaS builds
• What a new SaaS costs to build from scratch
• CI/CD foundations for startups

Related reading#

• How to Build a SaaS Product
• AI Development Cost in 2026
• MVP Development Cost
• How to Build a Fintech App
• AI in Fintech