Häufig gestellte Fragen
Greenfield or brownfield – when does each approach make sense for SAP S/4HANA?
Brownfield technically converts the existing system and continues it, which is usually faster and cheaper, while greenfield sets up the ERP completely from scratch, making it cleaner but more demanding. Greenfield is recommended above all when legacy systems are heavily customised, data quality is low or processes fundamentally need overhauling; brownfield is more suitable for well-maintained systems with a tight time window. The selective or bluefield migration, which carries over proven parts and rebuilds others, is considered a pragmatic middle path. Market observations show a trend towards such hybrid strategies; there is no universally 'right' choice — it depends on data quality, custom solutions and time pressure.
How much does a greenfield implementation cost?
There are no reliable flat rates, as costs depend heavily on company size, industry, number of sites and desired adaptations. In the mid-market, extensive greenfield projects (for example at SAP S/4HANA level) frequently fall in the single-digit millions range, and in large corporations they can be considerably higher. Importantly, software licences usually account for only a smaller share of the total costs — industry estimates often put them at around a quarter to a third — while the bulk goes to implementation, customizing, data migration, training and the subsequent stabilisation and hypercare phase. Because of the complete rebuild, the initial effort with greenfield is generally higher than with a technical brownfield conversion.
How long does a greenfield ERP implementation take?
The duration varies considerably and ranges from a few months to well over a year, depending on scope, data quality and integration complexity. Simpler mid-market ERP implementations often fall within a range of roughly three to twelve months, while extensive greenfield projects with many sites or high adaptation needs — for example at SAP S/4HANA level — frequently take twelve to eighteen months or longer. Greenfield projects tend towards the longer end because processes, configuration and the data model have to be developed from scratch. Planning realistic testing, training and change phases is critical to success, as an overly tight schedule is a common cause of project problems.
Which data is carried over in a greenfield project?
Unlike a full takeover, greenfield migration is deliberately selective, typically carrying over only cleansed master data and active transactional data such as open items and balances. Historical documents and data stocks that are no longer needed are usually not transferred to the new system but kept in an archive system or data lake. This approach allows a start with high data quality but requires careful prior data cleansing and clear decisions about what is really needed. It should be noted that valuable historical information can be lost if the archiving and access strategy — including with regard to statutory retention obligations — is not considered from the outset.
When is a greenfield approach the better choice?
Greenfield makes particular sense when a legacy system that has grown over years contains so many custom solutions that maintenance and updates have become disproportionately burdensome. The rebuild also plays to its strengths with fundamentally changed business models, in the course of cloud or SaaS strategies, or when processes are to be redesigned and standardised anyway. It makes it possible to consistently use the standard functions and best practices of a current software product and to shed technical legacy. The prerequisite, however, is the organisation's willingness to undergo noticeable change and sufficient resources for change management and training.
What risks and disadvantages does a greenfield implementation have?
The biggest disadvantage is the higher effort: greenfield means longer timelines, more upfront investment and more intensive change management than a technical conversion. Because working practices change noticeably, training and employee acceptance are critical to success, and a big-bang switchover carries the risk of business interruptions. Since existing customisations and historical data are not carried over automatically, there is also the danger of implicitly losing important custom logic or valuable historical data if they are not deliberately reconstructed or archived. These risks are offset by the long-term benefits of lean, standard-based processes, which is why an honest weighing of effort, risk and benefit should come at the start.