Why brownfield differs from greenfield
A live environment carries mixed hardware generations, several management systems, unsupported software, inconsistent configuration and incomplete documentation. Services must keep running while the work proceeds, and the true dependencies are often known only to the people who built the original systems. Decisions about replacement or migration made before those dependencies are understood tend to be reversed later.
Discovery and dependency mapping come first
- Build an inventory of hardware, software, virtual machines, network devices and licences, with support and end-of-life dates.
- Map the application inventory to the infrastructure it uses: servers, storage, network paths, databases, identity, name services and external interfaces.
- Observe real traffic and utilisation over a representative period, because configuration files do not show what is actually used.
- Interview the owners and operators of each system; record assumptions that cannot be verified.
- Compare documentation with what the walk-through and discovery tools find, and correct the record.
Choose a disposition for each item
| Disposition | Meaning | Typical trigger |
|---|---|---|
| Retain | Leave in place, possibly with updated support or monitoring | Supported, performing, low risk |
| Refresh | Replace like for like or with a current generation | End of support, hardware failures, capacity limits |
| Migrate | Move the workload to another platform | Platform consolidation, cloud or private-cloud adoption |
| Consolidate | Merge several systems into one | Under-used capacity, duplicate functions |
| Retire | Decommission after confirming nothing depends on it | Redundant or unused systems |
Sequence by dependency and risk
Group applications that depend on one another and move them together. Start with lower-risk groups, so the team gains experience before moving critical systems. Where a shared service such as network, identity or storage underlies many applications, prepare the new platform for it first.
Plan for coexistence
During the transition, old and new will run in parallel. Plan network connectivity between them, identity across both, data synchronisation, monitoring of both, and who is responsible for what at each stage. Keep addressing and name resolution consistent to avoid breaking dependencies that were never documented.
Define downtime windows, validation and rollback
- Each migration group has an agreed window and a stated maximum outage.
- Pre-checks confirm backups, capacity at the target and availability of the people involved.
- Validation tests, agreed with application owners, are run before the source is released.
- A rollback point and procedure exist and the decision point for using it is defined.
- The source remains available until post-migration monitoring confirms stable operation.
Capture knowledge as you go
Modernisation is the opportunity to correct the documentation gap. Update diagrams, configuration records, asset registers and runbooks as each group is completed, and decommission the old records along with the old equipment.