Greenfield Is a Diagnosis, Not a Prize
Teams ask for a rewrite as though greenfield were a reward for enduring the old codebase - it is a diagnosis with a test attached, and misdiagnosis is how rewrites fail. Part 1 of 2 on choosing the field you build on.
Greenfield is the word engineers say the way other people say holiday. It arrives loaded with longing — no legacy, no ancient framework pinning the roadmap, no data contract from 2014 that nobody dares touch — and that longing is exactly what makes it dangerous. I have watched teams campaign for a rewrite as though greenfield were a prize, something you earn by suffering the old codebase long enough. It is not a prize. It is a diagnosis — a statement of fact about the constraints you are actually under — and like any diagnosis it can be wrong, and the misdiagnosis is where the money goes.
This is part 1 of a two-part mini-series: the decision here, the execution in part 2. Everything in it is my own synthesis from years on both kinds of project; where I lean on someone else's published thinking I credit it in prose, and part 2 does that explicitly with a playbook I partly disagree with.
What the words actually mean
Both terms are borrowed from civil engineering. A greenfield site is undeveloped land — you survey it, you plan freely, you build what the requirements demand. A brownfield site has been built on before: there are foundations in the ground, services of unknown routing, and sometimes contamination from the previous use. Software took the metaphor and it fits unreasonably well, right down to the contamination. Practitioners used both terms informally for years; brownfield got its book-length software treatment in Hopkins and Jenkins' Eating the IT Elephant: Moving from Greenfield Development to Brownfield (IBM Press, 2008).
Brownfield development, in plain terms, means building new capability inside or alongside systems that are already alive. The old estate is serving production traffic and must keep doing so while you work. A large share of your effort goes not into building anything new but into understanding what is already there — which schemas mean what, which integrations exist because of a decision nobody remembers, which behaviours downstream teams silently depend on. Integration is not a phase near the end; it is the first conversation. And in my experience, most enterprise work is brownfield in practice — the genuinely clean slate is the anomaly, however many project charters claim otherwise.
The test is independence, not emptiness
An empty repository is not what makes a project greenfield. What makes it greenfield is decision independence — the freedom to choose the architecture, the data model, the stack and the release rhythm from today's requirements rather than yesterday's commitments.
So run the test decision by decision. For each of the big choices the new system needs — where the data of record lives, how identity works, what the deployment unit is, when releases ship — ask who constrains it. If the honest answer keeps coming back “the existing estate”, you are not looking at greenfield. A new orders-api that must honour the old warehouse's data contracts, ship on the old release train and authenticate against the old identity model is a brownfield modernisation with a new folder, whatever the project charter says. That is not a lesser thing to be doing — but it must be planned like what it is.
Misidentifying this — calling work greenfield because the repository is new — is, in my experience, one of the commonest ways rewrites go wrong. You plan for freedom and then inherit obligations one integration at a time, each arriving as a surprise, each too late to design around. The team that diagnosed itself as free budgeted nothing for archaeology.
When the diagnosis is genuinely greenfield
Sometimes the diagnosis comes back genuine, and it is worth being precise about what that looks like, because the honest signals are structural, not emotional.
The strongest signal is that the current platform cannot reach the goal at all — not slowly, not expensively, but structurally. You have refactored in good faith and the reliability or performance target is still out of reach, because the constraint is load-bearing architecture, not code quality. A close second: the business is moving into territory whose natural domain boundaries contradict the ones your systems encode — the shape of the new problem fights the shape of the old solution, and forcing the fit distorts both. Compliance or security requirements that demand structural properties the platform cannot retrofit belong in the same family. And there is the drag signal: when every change, however local it looks, fans out into cross-system regressions, the estate is telling you its coupling has won.
Then there is the other diagnosis — greenfield as an emotional escape — and its symptoms are just as recognisable. The requirements are still moving weekly, which means you would be pouring foundations on sand. There is no capacity to run old and new in parallel, which means the migration plan is a prayer. The existing system could honestly be rescued by focused, modular extraction inside a couple of quarters, which means the rewrite is a preference, not a necessity. Or — the quiet one nobody writes in the proposal — the team is simply exhausted by maintenance and wants to feel the blank page again. I have felt that pull myself; it is human and it is real. But a rewrite chosen as an escape from maintenance is maintenance deferred at interest, and the old system's problems have a way of being rebuilt, faithfully, by the same organisation that built them the first time.
The way out of arguing feelings is to buy certainty cheaply: a short, time-boxed discovery exercise before any commitment, with concrete proof points — can a prototype hit the throughput target, does the failure-recovery story hold, what does the cost model say over a few years of running it. A few weeks of that converts the decision from a debate into an evidence review.
The trade, in one honest table
Written as my own field summary, not anyone's framework:
| Question | Greenfield | Brownfield |
|---|---|---|
| Where the risk lives | in the product bet - you may build the wrong thing well | in regression - you may break the right thing |
| Where the money goes | design and construction | discovery and integration |
| When it feels fast | after foundations settle - month six, not month one | immediately, then progressively slower |
| What kills it | scope swell, over-design, migration debt | invisible coupling and tacit knowledge |
The row I want you to sit with is the first. Greenfield does not remove risk; it trades regression risk for product risk. You will break nothing that exists — and you may spend a year discovering that what you built cleanly is not what anyone needed.
How greenfield fails, and what I do about it
When greenfield projects die, they die in recognisable ways. These are the ones I have seen closest, with the countermeasures I now consider non-negotiable:
| Failure mode | How it shows up | Countermeasure |
|---|---|---|
| The canvas invites everyone | with no history to say no, every stakeholder adds one more capability to the first release | a deliberately narrow first release, a written out-of-scope list, and change control that makes additions cost something visible |
| Designing for an imagined future | months of architecture for scale and features that may never arrive | design for the current goal plus one plausible growth step, and let a working slice, not a diagram, validate the shape |
| Migration as a footnote | data, identity and reporting continuity surface late, at panic prices | treat migration as a workstream from day one and rehearse it against production-like volumes before you trust it |
| Paying for two systems | the old estate runs beside the new one far longer than anyone budgeted | fund the dual-run period explicitly, and put a decommission date with a named owner into the plan |
| A stack the team cannot operate | a modern architecture failing in ways nobody present has debugged before | staff the new stack with people who have run it in production, or choose the boring stack you already know how to operate |
| Operations bolted on last | observability and incident response scheduled for “after launch” | service-level targets and telemetry in the first slice of work, not the last |
Notice the pattern across all six: none of the countermeasures is architectural. They are acts of discipline — lists, budgets, dates, rehearsals. The blank page does not supply discipline; it removes the constraints that used to impose it for free. That observation is the whole of part 2.
Where the series goes
Two parts, one decision each:
- Greenfield Is a Diagnosis, Not a Prize — this post: what the terms actually mean, the decision-independence test, when the diagnosis is genuine and when it is an escape.
- A Blank Page Still Needs Gates — the execution: greenfield delivery compressed to three questions (decide, prove, ship), and the gates an AI-assisted team still owes itself.
If there is a rewrite proposal on your desk right now, run the independence test on it before you read anything else — decision by decision, who constrains it. If the answer is “the estate” more often than not, part 2 will still help you, but it will help you as what you are: a brownfield engineer with a new folder. Next, the gates that turn a genuine blank page into a shipped system.