Brownfield in IT and OT
Brownfield describes any modernization that does not start on a blank slate, but inside a system and data landscape that has grown over years: existing applications, historical interfaces, and processes that must keep running while the architecture underneath them changes. Unlike a greenfield build, success in brownfield depends not only on the target architecture, but above all on the order in which the existing system is retired.
What sets brownfield apart from greenfield
The term brownfield comes from construction: an industrial site where something already
stands — unlike the undeveloped field that greenfield refers to. Applied to IT and OT, brownfield
describes any project that does not start on a blank slate, but inside a landscape that has grown over years:
existing systems, historical data models, interfaces that have been running for years, and processes nobody wants
to switch off overnight.
The difference from greenfield is not only technical, but organizational. With greenfield, you decide on a target
architecture and build it without legacy constraints. With brownfield, you also decide on a target architecture
— but then have to find a path there that does not endanger ongoing production. That is why brownfield projects
rarely fail on the technology, and almost always on the sequencing.
It is not the new architecture
that decides the success of a brownfield project, but the order in which the old one is retired.
Why grown systems are the normal case
In practice, brownfield is not the exception, it is the normal case. Most manufacturing operations run
controls, MES, and ERP systems that are ten, fifteen, or twenty years old — not out of neglect, but because they
work and are deeply woven into processes, interfaces, and the knowledge of the people running them. A complete
rebuild would be technically possible, but rarely justifiable economically: it costs time, money, and above all
production downtime that translates directly into lost revenue on the shop floor.
Greenfield remains the right choice when something is genuinely being built new — a new plant, a new line, a
site with no history. For everything else: the landscape is there before the project starts, and it stays there
throughout the project. Anyone who ignores that and plans brownfield the way they would plan greenfield ends up with
a target architecture that looks convincing on paper but has no viable path to get there.
Technical debt rarely announces itself. It accumulates over years — an interim connection that becomes a
permanent one, an interface nobody documents anymore, a data format only one person on the team still understands.
Brownfield projects that take this seriously do not start with the new architecture, but with an honest assessment
of what is actually running.
Four patterns for retiring what exists, safely
How to retire an existing system without endangering ongoing operations is one of the central design
questions of every brownfield project. Four patterns have become established for this — they are not mutually
exclusive, and in practice are usually combined.
| Pattern | Principle | When it fits |
|---|---|---|
| Strangler fig pattern | New functionality grows step by step around the old system until its core can eventually be replaced |
long-lived core systems that cannot be replaced all at once |
| Anti-corruption layer | An intermediate layer translates between the old and the new system, so both sides can change independently of each other |
when old and new coexist in parallel for an extended period |
| Parallel run (shadow mode) | The new system runs alongside without acting on production, until enough trust exists in its results |
safety-relevant or hard-to-reverse decisions |
| Big-bang cutover | A complete switch on a set date, the old system is shut down | small, clearly bounded systems with low risk — rarely the right choice in OT |
The big-bang cutover looks cleanest on paper, because there is no transition phase to manage. In production
environments, though, it is almost always the riskiest option: a failure affects the entire operation at once, and
a rollback under time pressure is rarely as simple as planned. The other three patterns buy safety with complexity
— their transition phases have to be actively run and observed.
From current state to step-by-step migration
Regardless of the pattern chosen, successful brownfield projects go through four steps that build on one
another. Each step answers its own question, and none can be usefully skipped.
Current-state assessment answers what runs today: which systems, which interfaces, which
dependencies actually exist — not what the documentation says, but what actually happens in production.
Target architecture answers where it should go: a decision that can be made independently of the
current state. Prioritization answers what gets tackled first — usually whatever delivers the
greatest benefit at manageable risk, not the technically most interesting subsystem. Step-by-step
migration is the actual execution, following one of the four patterns from the previous section.
Most brownfield projects fail not at the target architecture, but because prioritization and migration are skipped or reversed.
Uniform naming instead of more islands
Even with the right pattern and the right order, brownfield projects often stumble on an inconspicuous
point: the data side. If a value on one line is called sps-3-db12-dw4 and something entirely different
on the identical neighboring line, every extension creates a new island instead of a shared platform —
regardless of how cleanly the new system itself is built.
This is not a side issue, but often the real bottleneck: the new architecture may be technically sound, but
without uniform naming it cannot be carried from the first plant to the second without being rebuilt for each one.
How this can be solved structurally is covered in detail in our articles on the Unified
Namespace and on IT-OT convergence. For brownfield projects, the rule is: whoever
clarifies naming only at the second or third rollout ends up building it twice — once for the first system, then
again for the unification that follows.
Implementation with pronubes
pronubes does not replace existing systems. The platform delivers the infrastructure that lets brownfield
modernization happen in a structured way instead of an improvised one.
pronubes Edge connects existing controls, sensors, and systems through standard protocols —
OPC UA, MQTT, REST, SQL, file formats — and can itself act as an anti-corruption layer: old interfaces stay
unchanged, while new systems connect through a clean, uniform layer.
pronubes Zones provides the uniform naming that makes a modernization transferable from the first
plant to the second in the first place — the prerequisite for the scaling described in the previous section.
pronubes Insights makes it visible during the transition phase whether old and new data sources
are delivering consistently — in a parallel run or with an anti-corruption layer, the difference between a
controlled migration and old and new quietly drifting apart.
The payoff of a brownfield modernization rarely shows up in the first subsystem retired, but in how smoothly the
second and third follow.
- Brownfield
- Modernization or extension of an existing system and data landscape, as opposed to building new.
- Greenfield
- Building a new architecture with no regard for existing systems, for example at a new plant or site.
- Strangler fig pattern
- New functionality grows step by step around an old system until its core can be replaced.
- Anti-corruption layer
- An intermediate layer that translates between an old and a new system so both can change independently.
- Technical debt
- Shortcuts and compromises from earlier projects that accumulate unnoticed and make later changes harder.
- Governance (IT)
- Clear ownership, prioritization, and decision paths that keep modernization from adding complexity instead of removing it.
Frequently asked questions
Is brownfield always the right choice?
No. For a new plant, a new line, or a site with no history, greenfield is often the better option, because there is no legacy to consider. Brownfield is the right choice whenever something is running that needs to keep running during modernization.
What happens if you modernize without a strategy?
Without a clear target architecture and prioritization, more technical debt, media breaks, and inefficient interfaces quickly emerge — the modernization then doesn’t resolve existing problems, it multiplies them with new ones.
How is brownfield different from a classic software update?
An update replaces one version with a newer one within the same system. Brownfield changes the architecture or the system boundaries themselves — for example when a new system partially or fully replaces an old one — and therefore needs its own migration strategy.
Can greenfield and brownfield be combined?
Yes — this middle path is often called bluefield: an existing system is scaled back far enough that parts of it can be rebuilt, while stable core functions are preserved. A detailed comparison of all three approaches is available in our article Greenfield, Bluefield, or Brownfield?
How long does a brownfield modernization typically take?
That depends heavily on the pattern chosen and the size of the landscape. Step-by-step approaches like the strangler fig pattern are deliberately designed to run over months to years, but deliver continuously usable intermediate states instead of reaching a finished state only at the end.
Modernization that doesn’t put operations at risk.
30 minutes about your system landscape: what runs today, where it should go — and what comes first.
pronubes is a product of inray Industriesoftware GmbH. Over 30 years of industrial software from Germany. Innovative and reliable for manufacturing companies.
