Bluefield in IT and OT Transformation

IT and OT transformation is usually framed as a choice between two extremes: greenfield
rebuilds an architecture with no regard for what already exists — the right approach for a new plant or a new
line with no history. Brownfield modernizes inside a grown landscape and has to account for every
existing dependency along the way. Between the two sits bluefield: a deliberately selective middle
path that neither discards everything nor keeps everything.

The difference from pure brownfield integration lies in the assessment. Brownfield projects mostly assume that
what exists keeps running and has to be integrated. Bluefield projects question that assumption for every single
component: is this process, this data structure, this interface worth carrying over — or is a rebuild the
better investment at this particular point? The answer is rarely uniform across the board, and that is exactly what
makes bluefield a decision rather than a formula.

Bluefield fits whenever a system landscape should be neither rebuilt entirely from scratch nor carried over
completely unchanged — typically in ERP transformations, where configurations and
customizations that grew over years get critically reviewed; in cloud migrations, where not every
on-premises application should be lifted one-to-one into the cloud; in the modernization of data
platforms, where outdated data models are selectively replaced; and in the consolidation of
heterogeneous system landscapes after mergers or across multiple sites.

The bluefield approach pays off especially where a pure greenfield rebuild would throw away all the domain
knowledge built up over years in existing processes and configurations — and where pure brownfield integration
would carry technical debt unchanged into the new architecture. Bluefield deliberately separates the two: domain
knowledge is preserved, while the technical implementation is renewed wherever it needs to be.

Not every project benefits from it. Where a system landscape as a whole is still viable, classic brownfield
integration is enough. Where there genuinely is no relevant history, greenfield is the more direct route. Bluefield
sits between the two — and deliberately choosing that position, instead of having it forced by time pressure,
is itself already the first success factor.

The selective nature of bluefield brings four advantages that, in practice, mostly reinforce each other.

These advantages are not automatic. They only materialize if the assessment of what stays and what goes is
actually made carefully — and doesn’t swing wholesale in one direction or the other under time or cost
pressure. An assessment that is too cautious carries over too much legacy baggage; one that is too radical discards
working substance. The next section shows how this assessment can be carried out in a structured way.

Successful bluefield projects go through four steps that build on one another and cannot usefully be
skipped.

Assessment answers what stays and what goes: every relevant process, every data structure, and
every interface is judged individually on whether it justifies the effort of being carried over. Target
architecture answers where things should go — independent of what ultimately gets carried over.
Selective migration answers what actually gets carried over, and moves exactly those parts into the
new landscape. Modernization is the actual integration and rebuild: carried-over and newly built
components are brought together into a single, coherent architecture.

Without clear assessment criteria, selection quickly turns into arbitrariness — the assessment decides what stays, the target architecture decides how it fits together.

Whether a bluefield project succeeds comes down to three things. The first is analysis: are
the existing processes still viable from a business standpoint, or have they only been patched up over the years?
Can the current data model be carried over to the target architecture, or does every migration create new friction?
How much technical debt sits in the systems being considered for carry-over — and does the effort of dragging
it along outweigh the effort of a rebuild?

The second is architecture: a target architecture that only fits the current scope gets discarded
again at the next bluefield project. Scalability and uniform naming — as described in our articles on the
Unified Namespace and on IT-OT convergence
— keep every carry-over from becoming a new island instead of fitting into a shared platform.

The third is governance: who decides what gets carried over and what doesn’t? Without
clear criteria and clear ownership, the assessment turns into a negotiation instead of a structured decision —
and that is the single most common reason bluefield projects run longer and cost more than planned.

pronubes brings a structured analysis, a clear target architecture, and a controlled transformation path that
makes the assessment traceable instead of leaving it implicit.

pronubes doesn’t make the assessment decision for you — but the platform delivers the
infrastructure to implement a bluefield decision cleanly once it has been made.

pronubes Edge connects both carried-over legacy systems and newly built components through
standard protocols — OPC UA, MQTT, REST, SQL, file formats — and makes the distinction between old and
new invisible to the systems above it.

pronubes Zones provides the uniform naming that keeps carried-over and newly built components
from standing side by side as separate islands instead of fitting into a shared structure.

pronubes Insights makes it visible during selective migration whether carried-over and newly
built data sources are delivering consistently — the precondition for the assessment made during the analysis
phase actually holding up in practice.

The payoff of a bluefield project doesn’t show up in how much gets rebuilt or how much gets carried over,
but in whether both decisions still hold up in hindsight.

More about the platform