The myth of the clean start

The classical “greenfield project” pitch sounds wonderful:

• new hardware
• modern designs
• clean addressing
• thoroughly reviewed security policies
• everything documented from day one

In workshops, the diagrams are straight, the colours are pretty, and no one mentions emergency changes at 02:00, external partners with special demands or that one legacy app that still needs a strange exception.

In reality, even a greenfield network carries baggage:

• organisational structures that won’t change
• existing CMDB, IPAM, ticketing and monitoring tools
• compliance frameworks that restrict design choices
• skill sets and habits of the engineering team
• future projects already queued on top of this “clean” base

The soil is never empty. It’s just freshly turned. From the very first config commit, the network starts to age. Decisions from day zero become someone else’s “historic design choice” a few years later.

When greenfield becomes Brownfield: On day one!

Think about what happens in the first weeks of a new environment:

• quick workarounds for that one special customer
• a temporary firewall rule that “we’ll clean up later”
• a naming decision that doesn’t quite match what was written in the design document
• a one-off routing tweak to make a test work under time pressure
• slightly different approaches between two engineers who both know what they’re doing

Technically, everything still works. Structurally, the drift has already begun.

The point isn’t that people fail. The point is that real networks live — and living systems never stay as clean as the whiteboard.

A true greenfield stays green only if you treat it like a future Brownfield from the very first change.

What this means for design and operations

If we accept that “greenfield is actually Brownfield in slow motion”, a few consequences follow:

1. Day-one documentation matters more than day-one diagrams.
   If you don’t capture state and intent early, you are just creating tomorrow’s archaeology.
2. Standardisation must start before the first rollout wave.
   Templates, naming rules, policy models and roles must exist and be enforced from the beginning, not bolted on later.
3. Automation has to see the future, not only the present.
   Workflows need to be built so they can handle more sites, more teams, more exceptions and more systems than exist right now.

This is exactly where neops enters the picture.

neops as a “Day 0.5” platform

neops doesn’t wait for the network to become messy before it adds value. It can sit at the centre of a so-called greenfield from the first steps:

• builds a Source of Truth that matches how the network will be operated, not just how it was designed
• turns design intentions into repeatable workflows instead of one-off build scripts
• enforces consistent templates for routers, switches, firewalls, NAC and monitoring from the first device onward
• captures state and history early, so future Brownfield phases have clean data to build on
• connects to CMDB, IPAM, ticketing and monitoring via APIs instead of leaving each system to improvise its own view

The result: years later, when the environment has grown, been extended, merged, and patched under pressure, there is still a coherent operational model underneath. You didn’t avoid Brownfield. You made it manageable before it arrived.

A semi-serious example — today’s greenfield, tomorrow’s merger

Picture this:

A large enterprise rolls out a brand new core and access network, proudly labelled as greenfield. The design is crisp, migration runs well, and everyone agrees this time the documentation will stay current.

Three years later, the company acquires another business. Suddenly:

• new sites must be connected
• addressing schemes collide
• security concepts differ
• tools don’t match
• nobody has time to redraw everything

If neops had been part of the initial rollout, the story would look different:

• the original network already followed strict, automated workflows
• devices were built from shared templates
• all changes, states and exceptions were stored in a structured model
• connecting the acquired network becomes an extension of known processes, not a fresh puzzle

The “greenfield” wasn’t really green. But it was prepared.

‍