Module 1: Why Not Rewrite
The case for incremental
Overview
The three previous lessons built the case against the rewrite: the business doesn't stop, the second system inflates the scope, the tacit knowledge gets lost. But knocking down one option isn't enough —you have to show that the alternative is truly better, and why—. This lesson builds the case for incremental, and it does so with numbers, not slogans. The thesis is that transforming a system by slices wins for two measurable and distinct reasons: it delivers value early and it risks little at each step.
The first reason is about the timing of value. In an incremental migration, each slice you modernize goes into production and starts paying immediately: the first slice delivers value from the first period, it doesn't wait for the end. In a big rewrite, on the other hand, there's no value until the final cutover —all the benefit is concentrated at a distant point in the future, and value that arrives late is worth less than value that arrives early, because during the entire wait it wasn't working for you—. The second reason is about risk. In each incremental deploy, what can go wrong is bounded to one slice: if it fails, you revert a small piece. In a big rewrite, the cutover changes the whole system at once, so the risk at stake in that single moment is maximal: if it fails, everything falls. This lesson measures both —the accumulated value-periods (the area under the curve of delivered value) and the risk at stake per deploy— so that incremental's advantage stops being a belief and becomes a measurement.
Connection with the module. This is the module's hinge: it closes the case against the rewrite (lessons 2-4) and opens the case for the alternative. The two metrics you run here —value-periods and risk at stake— are the quantitative counterpart of the incremental advantage. Lesson 6 gives this alternative a name and an image with the strangler fig metaphor, and lesson 7 delimits when incremental is truly the right option (almost always) and when it isn't. The mechanics of how a slice is delivered without shutting down the system is module 3 onward; here, the measured why.
An analogy: two ways to pay for a house
Imagine two ways to own a house. In the first, you save for twenty years without touching the money, and at the end of year twenty you buy the house in cash. In the second, you put down a deposit today and you move in this week, and you pay the rest little by little while you already live in it. Suppose the total cost is identical in both. Are they equivalent? Not at all. In the first, you spend twenty years without a house —renting, waiting— and only in year twenty do you start to enjoy it. In the second, you enjoy the house from the first week: you have twenty years of "living in your house" that the other option doesn't have. The same money, but one gives you the benefit now and the other gives it to you at the end, and the "now" accumulated over twenty years is worth much more.
Software value works the same. Modernizing by slices is moving in this week: each modernized piece starts delivering benefit (better performance, unlocked features, less maintenance) from the moment it goes into production, and that benefit accumulates over all the time left to finish the rest. The big rewrite is saving for twenty years: you enjoy nothing until the final cutover, and all the "value time" the incremental migration was accumulating, the rewrite simply lost. And there's a second difference, the risk one: in the house on installments, if one month you can't pay, you adjust one installment; in the cash purchase, your entire twenty-year estate is in a single transaction, and if that transaction goes wrong, you lose it all at once. Let's measure the two differences.
Worked example: value-periods and risk at stake
We're going to model a system of 8 modernizable slices over a horizon of 12 periods. The "live modern value" in each period is how many slices are already modernized and serving. Incremental modernizes one slice per period, so its live value rises little by little from period 1. The big rewrite delivers the 8 all at once at the cutover —optimistic in period 8, or slid to 12 if it runs late—. We sum the live value of each period (the area under the curve) and compare:
SLICES = 8 # Mercado's monolith has 8 modernizable slices
HORIZON = 12 # periods we observe
def live_value(strategy, t):
# "live modern value" in period t: slices already modernized and serving.
if strategy == "incremental":
return min(t, SLICES) # a new slice each period
if strategy == "rewrite_ok":
return SLICES if t >= 8 else 0 # all together at the cutover (optimistic)
if strategy == "rewrite_slip":
return SLICES if t >= 12 else 0 # the cutover slips to the end
strategies = ["incremental", "rewrite_ok", "rewrite_slip"]
print(f"{'period':>8}{'incremental':>13}{'rewrite_ok':>12}{'rewrite_slip':>14}")
print("-" * 47)
totals = {s: 0 for s in strategies}
for t in range(1, HORIZON + 1):
row = {s: live_value(s, t) for s in strategies}
for s in strategies:
totals[s] += row[s]
print(f"{t:>8}{row['incremental']:>13}{row['rewrite_ok']:>12}"
f"{row['rewrite_slip']:>14}")
print("-" * 47)
print(f"{'TOTAL':>8}{totals['incremental']:>13}{totals['rewrite_ok']:>12}"
f"{totals['rewrite_slip']:>14}")
print(f"\n Accumulated value-periods (area under the curve) in {HORIZON} periods:")
print(f" incremental : {totals['incremental']:>3}")
print(f" rewrite_ok : {totals['rewrite_ok']:>3} "
f"({totals['incremental'] / totals['rewrite_ok']:.1f}x less than incremental)")
print(f" rewrite_slip: {totals['rewrite_slip']:>3} "
f"({totals['incremental'] / totals['rewrite_slip']:.1f}x less)")
# Risk "at stake": the biggest unvalidated change deployed all at once.
print("\n Risk at stake per deploy (slices that change all at once):")
print(f" incremental : 1 slice -> if it fails, 1/{SLICES} of the system is reverted")
print(f" big rewrite : {SLICES} slices -> if it fails, the whole system goes down")What to expect. When you run the file, the output is exactly this:
period incremental rewrite_ok rewrite_slip
-----------------------------------------------
1 1 0 0
2 2 0 0
3 3 0 0
4 4 0 0
5 5 0 0
6 6 0 0
7 7 0 0
8 8 8 0
9 8 8 0
10 8 8 0
11 8 8 0
12 8 8 8
-----------------------------------------------
TOTAL 68 40 8
Accumulated value-periods (area under the curve) in 12 periods:
incremental : 68
rewrite_ok : 40 (1.7x less than incremental)
rewrite_slip: 8 (8.5x less)
Risk at stake per deploy (slices that change all at once):
incremental : 1 slice -> if it fails, 1/8 of the system is reverted
big rewrite : 8 slices -> if it fails, the whole system goes down
Read the columns as three ways to spend the same time.
The incremental column starts delivering value from period 1: 1, 2, 3, 4... each period there's one more slice alive and serving. By period 8 the system is fully modernized (value 8), and from there on it holds at 8. The sum of the whole column —the area under the curve— is 68 value-periods. That's "living in the house from the first week": each slice accumulated value over all the periods it was alive.
The rewrite_ok column is the big rewrite's optimistic scenario: it delivers the 8 slices all at once in period 8 (right when it planned) and holds at 8 until the end. Its area is 40 value-periods: 8 slices × 5 periods alive (from 8 to 12). Notice that the final figure —the modernized system— is identical to incremental's: both end with 8 modernized slices. But incremental accumulated 68 and the rewrite only 40, a difference of 1.7x, and that difference is pure lost value time: the seven periods in which the rewrite delivered 0 while incremental was already delivering 1, 2, 3... The rewrite doesn't deliver less at the end; it delivers the same, but later, and arriving late costs.
The rewrite_slip column is the realistic scenario —the one lessons 2 and 3 made inevitable—: the cutover slips to period 12. Its area is barely 8 value-periods: it delivered everything in the last period and had no time left to accumulate anything. Against incremental, that's 8.5x less value. The same modernized system, but so late that almost all the value time was lost. And remember lessons 2 and 3 showed that the cutover usually slips beyond the window —in which case the area would be 0, and the factor, infinite—.
Now the second block, the risk at stake one. Here the asymmetry is even more brutal. In incremental, each deploy changes one slice, so what can fail all at once is 1/8 of the system: if the slice goes wrong, you revert that piece and the other 7/8 stay intact. In the big rewrite, the cutover changes the 8 slices at once, so the risk at stake in that single moment is the whole system: if the cutover fails, it's not one piece that falls, it's everything. Incremental doesn't just deliver earlier: it delivers with a net, because it never puts more than one slice at risk at a time. The rewrite bets the entire system on a single roll.
Put the two measurements together and you have the case for incremental in its clearest form: more accumulated value (1.7x to 8.5x, depending on how much the cutover slips) and less risk per step (1/8 vs 8/8). It's not that incremental is "prettier" or "more fashionable": it's that it dominates the rewrite in the two dimensions that matter, value and risk, at once.
Deep dive: why early value is worth more (and why bounded risk compounds)
The value-periods result captures an idea that in finance is called the time value of money, and in product is called time to value: a benefit you receive today is worth more than the same benefit received two years from now, because during those two years today's benefit was working —reducing costs, retaining customers, enabling other things—. When incremental modernizes the catalog in period 1, that modernized catalog doesn't just "get ready earlier": it's saving maintenance costs and enabling improvements over the next 11 periods. The rewrite, by concentrating all the value at the end, forgoes that compound work. The 68 against 40 aren't a difference in the quality of the result —the final result is the same—; they're a difference in when it started paying off.
The risk result captures something complementary and perhaps more important for a system that can't go down. A deploy that changes 1/8 of the system has two properties that one changing 8/8 doesn't have: it's cheaply reversible (if it fails, reverting one slice is fast, against reverting a whole system, which is sometimes impossible because you already migrated the data) and it's diagnosable (if something breaks right after deploying one slice, you know almost for certain it was that slice; if something breaks after changing the whole system, the cause is in any of a thousand places). Bounded risk doesn't just lower the probability of a disaster: it lowers the cost of each problem, because it makes it small, reversible, and easy to trace. And since each slice teaches you something before the next, incremental's risk even drops over time —by slice 8 you've mastered the mechanics—, whereas the rewrite's accumulates quietly until it explodes at the cutover.
Accumulated value Risk at stake
(more is better) (less is better)
incremental ████████████████ 68 █ 1/8 (reversible, diagnosable)
rewrite (on time) █████████ 40 ████████ 8/8 (all or nothing)
rewrite (late) ██ 8 ████████ 8/8 (all or nothing)
There's an honest objection worth answering: "incremental has an overhead —the facade, the coexistence of old and new, the piecemeal data migration— that the rewrite doesn't pay." It's true: modernizing by slices requires building scaffolding (module 3's router, module 5's anti-corruption layer, module 6's dual-write). That scaffolding costs. But the example shows why it pays for itself: the difference in value-periods (28 to 60 units, depending on the slip) and the reduction of the risk of a total disaster buy that scaffolding with room to spare. Incremental's overhead is insurance with a small premium; the rewrite's "savings" is not buying insurance right in the riskiest operation you'll do.
Common mistakes
Comparing only the final state, ignoring the path. What happens: someone says "in the end both finish with the modernized system, so they amount to the same," and chooses the rewrite because "it doesn't have the scaffolding overhead." Why it happens: the final state is easy to imagine; the value accumulated during the path is invisible if you don't measure it. How to spot it: if the comparison between rewrite and incremental only mentions the result ("a modern system") and not the value time or the risk per step, 90% of the analysis is missing. How to fix it: measure the area under the curve, not the final point. The example makes it explicit: same ending (8 slices), but 68 vs 40 vs 8 value-periods depending on when each one arrived. The path is the difference, because the business lives in the path, not in the final point.
Underestimating the cost of an "all or nothing" deploy. What happens: the rewrite plan treats the cutover as just another technical event —"we deploy and done"— without dimensioning that that cutover puts the whole system at simultaneous risk. Why it happens: the cutover is seen as the happy ending, not as the most dangerous moment of the project. How to spot it: ask "if the cutover fails, how much of the system goes down, and how much does it cost to revert?". If the answer is "everything" and "we're not sure we can revert" (because the data was already migrated), the risk at stake is maximal. How to fix it: recognize that the blast radius of a deploy is a design variable, not a fixed given. Incremental keeps it at 1/8 by construction; the rewrite takes it to 8/8. A critical system like Mercado can't afford a deploy that risks 100% at once —lesson 6 shows how the strangler keeps that radius small with the system always alive—.
Discarding incremental for its scaffolding without measuring what it buys. What happens: the team sees the cost of the facade, the coexistence, and the piecemeal migration, and concludes that "it's more work than rewriting all at once." Why it happens: the scaffolding is a visible and concrete cost; the value it buys (value time + bounded risk) is diffuse and has to be calculated. How to spot it: if the argument against incremental is "it's more complex / more pieces" without putting the value-periods gained or the risk avoided in front of it, the accounting is half done. How to fix it: treat the scaffolding as what it is —an insurance premium— and compare it against what it prevents: the window of silence, the moving target, the tacit-knowledge regressions, and the all-or-nothing deploy. In a live and critical system, that premium is almost always a good deal; lesson 7 gives the criterion for when it isn't (small systems, without users, where the scaffolding costs more than it protects).
Exercises
Exercise 1 — Compute the value-periods. A system has 4 slices and a horizon of 6 periods. Incremental modernizes one slice per period (live value = min(t, 4)). A rewrite delivers the 4 all at once in period 4. Compute the accumulated value-periods of each one and incremental's advantage factor. Then say what happens to the factor if the rewrite slips to period 6.
See solution
Incremental (live value = min(t, 4) per period, t from 1 to 6): 1 + 2 + 3 + 4 + 4 + 4 = 18 value-periods.
Rewrite in period 4 (value 0 at t=1,2,3; value 4 at t=4,5,6): 0 + 0 + 0 + 4 + 4 + 4 = 12 value-periods. Incremental's advantage factor: 18 / 12 = 1.5x.
Rewrite slipped to period 6 (value 0 at t=1..5; value 4 at t=6): only 4 value-periods. Factor: 18 / 4 = 4.5x.
The lesson: the final state is identical in all three cases (4 modernized slices), but the accumulated value goes from 18 to 12 to 4 depending on when it arrived. And incremental's advantage factor grows the more the rewrite slips —from 1.5x to 4.5x—, which is exactly what lessons 2 and 3 predict will happen in a live system: cutovers slip, and each slip enlarges incremental's advantage.
Exercise 2 — The cutover's risk. Mercado is going to modernize its payment system. Team A proposes a big rewrite with a single cutover: turn off the old system one Saturday at midnight and turn on the new one. Team B proposes diverting 5% of the payment traffic to the new system, measuring, and raising the percentage only if all goes well. Compare the "risk at stake" of each proposal and explain which you'd prefer for a system that handles money.
See solution
Team A (single cutover): the risk at stake is 100% of the payments, concentrated in a single moment. If the new system has a bug —and lessons 3 and 4 showed that a rewrite almost always has hidden rules badly reimplemented—, that bug hits all the customers who try to pay on Saturday at midnight and until it's detected and reverted. And reverting can be very hard: if in those hours real payments were already processed through the new system (with migrated data), going back to the old means reconciling money transactions, not just "turning off and on." It's the all-or-nothing scenario in the most sensitive operation possible: the one that moves money.
Team B (5% incremental): the risk at stake is 5% of the payments. If the new system fails, it affects at most 1 in every 20 customers, it's detected fast (the small and controlled volume makes it easy to compare against the old), and it's reverted by returning that 5% to the old system, which stays alive handling the other 95%. Besides, each increment (5% → 10% → 25%...) teaches something before the next, so the risk drops as confidence rises.
Preference: for a system that handles money, team B, no doubt. The reason is exactly this lesson's metric: the risk at stake. A badly processed payment isn't a crooked pixel; it's real money, disputes, and broken trust. Putting 100% of the payments at risk in a single cutover is the worst possible play in the most critical module. Incremental keeps the blast radius at 5%, with the old one as a net, and that's precisely the strangler fig mechanics that lesson 6 and module 3 develop. (The formal decision of when to assume each risk, with its record, is the decisions guide; here we only compare the risk at stake.)
Exercise 3 — Answer the scaffolding objection. A colleague says: "incremental sounds good, but setting up the router, maintaining the old and new at the same time, and migrating the data in parts is a bunch of extra work the rewrite doesn't have. Isn't it simpler to rewrite all at once?". Answer using the lesson's two metrics and acknowledging what's true in their objection.
See solution
What's true in their objection: yes, incremental has a real overhead. Setting up the router (module 3), sustaining the old and new coexisting, and migrating the data by slices (module 6) is scaffolding the rewrite doesn't pay. There's no denying it: incremental is, step by step, more moving parts.
Why it pays for itself, with the two metrics:
- Value-periods. The example showed that incremental accumulates 68 value-periods against 40 (rewrite on time) or 8 (rewrite late). That difference —28 to 60 units of value delivered earlier— is real benefit that flows to the business while the rewrite still delivers nothing. That early value pays for the scaffolding with room to spare: the router costs, but the modernized catalog that's already in production in period 1 pays off over 11 periods.
- Risk at stake. The "simpler" rewrite puts 100% of the system at risk at the cutover; incremental, 1/8 per step. Incremental's scaffolding (the old as fallback, the gradual diversion) is exactly what buys that risk reduction. In a critical system like Mercado, avoiding an all-or-nothing deploy isn't a luxury: it's the difference between a bounded problem and a disaster.
The reformulation: incremental's scaffolding isn't "wasted extra work"; it's insurance with a small premium. The rewrite's "savings" is not buying insurance right in the riskiest operation. The right question isn't "which has fewer pieces?", but "which delivers more value with less risk?", and in both, incremental wins. (The only exception —when the scaffolding costs more than it protects— is lesson 7's narrow region: small systems, without users, where rewriting all at once is indeed the simple and correct thing. Mercado isn't that case.)
Summary and next step
In this lesson you turned the module's argument around: from knocking down the rewrite to building the case for incremental. You saw, with the two ways to pay for a house, that the same result delivered early is worth much more than delivered at the end, because the "now" accumulated during the wait is value time the rewrite loses. And you measured it in two dimensions: incremental accumulates 68 value-periods against 40 or 8 for the rewrite (1.7x to 8.5x more value, depending on how much the cutover slips) and risks 1/8 of the system per step against the 8/8 of the single cutover. Incremental dominates the rewrite in the two things that matter —value and risk— at once, and its scaffolding is an insurance premium those advantages pay for with room to spare.
Before moving on you should be able to: explain why early value is worth more than late value; compute the value-periods of a migration and incremental's advantage factor; argue why an all-or-nothing deploy is the riskiest moment of a project; and answer the scaffolding objection with the two metrics.
Lesson 6 gives a name and an image to this alternative you just justified with numbers. It's the metaphor that titles the whole technique of this guide: the strangler fig, the tree that grows enveloping another and replaces it cell by cell without felling it —the system always alive, the old one as fallback—. You'll see why that gradual replacement avoids the big-bang cutover blackout, and you'll measure the impact of an incident in both paths. (The metaphor and the why here; the router mechanics, in module 3.)
Resources
- Sam Newman, Monolith to Microservices (O'Reilly, 2019), ch. 3 "Splitting the Monolith" — the full development of why incremental migration delivers value and controls risk, with the techniques modules 3 through 6 detail. This lesson's central reference. In English.
- Martin Fowler, "StranglerFigApplication" (2004) — martinfowler.com/bliki/StranglerFigApplication.html. Incremental replacement as a way to deliver value and reduce risk at each step. Lesson 6's metaphor. In English.
- Don Reinertsen, The Principles of Product Development Flow (Celeritas, 2009) — the rigorous treatment of the "cost of delay" and why early value is worth more: the economic basis of this lesson's value-periods. In English.
- Jez Humble and David Farley, Continuous Delivery (Addison-Wesley, 2010) — why small and frequent deploys reduce risk compared to large and infrequent ones; the foundation of the bounded "risk at stake." In English.