UPDATE STRATEGIES for Business Central.
In our blog series, we explore the strategic options for migrating from Dynamics NAV or older versions of Business Central to a current version of Business Central. We categorize the various strategies, highlight the opportunities and risks, and show you what matters most when making a sound decision in practice.
Part 02 – Legacy Run, Brownfield Upgrade, or Greenfield Reimplementation: Which Strategy Fits Your Situation?
In the first post of our series, we introduced the three basic approaches to upgrading to the latest version of Business Central: Legacy Run, Brownfield Upgrade, and Greenfield Reimplementation.
At first glance, it seems natural to rank these strategies. Legacy Run then appears to be a mere continuation of the existing system, Brownfield a pragmatic middle ground, and Greenfield a particularly thorough modernization. However, this classification does not do justice to the issue.
Each of the three strategies has its own distinct rationale. Which one is right for your company depends on your starting point, your target vision, and the associated risks. After all, none of the three strategies is risk-free. Rather, they differ in terms of which existing risks are carried forward or reduced and which new risks arise from a modernization project.
What distinguishes these three strategies from one another?
Legacy Run, Brownfield Upgrade, and Greenfield Reimplementation differ primarily in how they handle the existing system, its data, its customizations, and established processes.
Legacy Run: Deliberately Continuing to Operate the Existing System
With the Legacy Run, the existing version of Dynamics NAV or Business Central remains in use. The focus is on reliable operation, maintenance, and the careful management of the resulting risks. No fundamental technical modernization will take place at this time.
This avoids the immediate burdens and risks associated with a major change project. Processes, data, interfaces, and work methods remain largely unchanged. At the same time, the risks associated with the existing system landscape persist. These may include outdated technologies, limited vendor support, components that are difficult to replace, or dependencies on specific personnel.
A legacy run should therefore not be equated with unplanned continued operation. Even the long-term use of an older NAV version can be a reasonable decision—provided that the risks are known, are consciously accepted, and are regularly reassessed.
Brownfield Upgrade: Modernizing Existing Infrastructure
In a brownfield upgrade, the existing system—including its data as well as key customizations, enhancements, and integrations—is migrated to a current version of Business Central.
This helps reduce the risks associated with an outdated technical platform in particular. At the same time, historical data, established processes, and custom features that are still needed can be retained.
However, “brownfield” does not simply mean migrating the system to a new version number from a technical standpoint. Customizations, interfaces, and third-party solutions must be analyzed and reevaluated. The primary risk is carrying over unnecessary complexity and past architectural decisions into the modernized solution. Conversely, over-simplification can overlook functionally relevant features or dependencies.
Greenfield Reimplementation: Reevaluating the Existing Solution
In a greenfield reimplementation, an existing Business Central solution is rebuilt from scratch. Processes, data, and custom functions are not automatically carried over in their entirety but are reevaluated based on the target state.
This makes it possible to reduce complexities that have developed over time, reorganize processes, and review existing system boundaries. Functions that were integrated into the ERP system over time—even though they would be better suited to another system from a business or technical perspective—do not need to be reimplemented in Business Central.
In contrast, project and change risks are regularly on the rise. Processes must be redesigned, data selected, requirements prioritized, and employees prepared for new ways of working. A greenfield reimplementation is therefore not just a technical fresh start, but often also an organizational change initiative.
The three strategies therefore differ not in whether risks arise, but in where those risks lie.
What risks are present in your current situation?
Before making a decision, it is important to understand your own starting point. It is not enough to simply look at the version being used, the scope of the custom code, or the expected project costs.
Technical, business, and organizational risks influence one another. A technically outdated solution can still function well from a business perspective. Conversely, a system that is still technically manageable may provide insufficient support for today’s business processes. And even a business-wise modernization can fail if decisions are not made or if the organization is unable to cope with the changes.
How safely can the existing system continue to operate?
For older versions of Dynamics NAV and Business Central, vendor support may be limited or have expired. It may now require increasing effort to continue developing and maintaining interfaces, third-party solutions, or technical components.
Additional risks may arise from a lack of knowledge about the existing solution. Customizations are often only incompletely documented. Key components may be understood only by individual employees or long-standing service providers. If this knowledge is lost, a previously manageable dependency can quickly lead to significant pressure to act.
Such risks do not automatically lead to a decision against the legacy run. However, it is important to be aware of the existing dependencies, the potential impact of a failure or a necessary change, and the measures available to mitigate these risks.
Does the solution still meet the technical requirements?
In addition to the technical condition, it is important to determine whether the ERP system continues to effectively support today’s business processes. Signs of a growing functional gap may include manual workarounds, data maintained in multiple places, key functions implemented in spreadsheets or third-party applications, and system logic that no longer aligns with actual processes.
At the same time, the opposite can also be problematic: functions were integrated into the ERP system simply because it was technically possible, even though they would be better suited—from a business or technical perspective—in a different system. As part of a modernization effort, it is therefore important to assess whether the existing system boundaries still make sense.
For Brownfield, this means that not every existing feature should automatically be modernized. Greenfield allows for a more fundamental restructuring. With Legacy Run, the existing structures and dependencies are initially retained.
What level of complexity will still be needed in the future?
A high degree of customization is not, in and of itself, an argument for or against a strategy. Even a highly customized solution can be a good technical fit for the company. Conversely, minimal customization can lead to significant dependencies.
It is therefore crucial to determine which adjustments are still necessary, which functions are now available in the standard system or in appropriate apps, and how well the relationships between code, data, and interfaces are understood.
With a brownfield project, there is a risk of perpetuating complexity simply because it already exists. With a greenfield project, conversely, there is a risk of underestimating necessary interdependencies or rediscovering them only late in the project.
What changes can the company handle?
The more a strategy changes processes, roles, and work practices, the greater the demands on project organization, decision-making, and communication. This includes the availability of relevant departments, clear priorities, binding decisions, appropriate testing, controlled data migration, and limiting the scope of the project.
A clear commitment from management is particularly important in greenfield projects. This support must not be limited to the budget and the project mandate. Management must visibly champion the objectives, resolve conflicts of interest, and actively support the change process.
Change management that accompanies a project is not merely a supplementary communication topic. It reduces risks arising from a lack of direction, resistance, or unclear responsibilities.
Brownfield can also bring about noticeable changes. With the Legacy Run, the immediate scope of change is smaller; nevertheless, it must be clear which limitations and risks are being consciously accepted.
How should costs and project duration be assessed?
Cost and duration obviously play a role. However, a simple comparison does not provide a realistic picture.
A legacy system may require minimal investment in the short term, while maintenance costs and reliance on personnel increase over the long term. A brownfield project can involve significant effort due to the need to modernize code, data, and interfaces. A greenfield project entails additional effort related to process design, data migration, testing, and change management.
It is even more difficult to assess the economic impact of potential risks. Therefore, costs and project duration should not be considered in isolation from the respective risks. A strategy that is more cost-effective in the short term may result in higher costs in the long term. Conversely, a potential long-term benefit does not automatically justify every large-scale modernization project.
When might each approach be appropriate?
An analysis of the risks does not result in a checklist that automatically leads to a strategy. The various aspects must be evaluated in context.
Legacy Run
A legacy run can be a sensible option if the system continues to support essential business processes and the risks associated with its operation are known and currently manageable. This also applies if a major modernization project would itself pose significant risks at this time—for example, because of a lack of personnel, because other projects take priority, or because fundamental decisions have yet to be made.
The prerequisite is a conscious and risk-oriented decision. The current situation should not be maintained simply because it has worked so far. Even a longer-term legacy run can be justified; however, the underlying risk assessment should be reviewed regularly.
Brownfield Upgrade
A brownfield approach can be useful if the existing solution continues to meet the organization’s business needs and significant parts of the existing system are to be retained. This includes data, established processes, customizations that are still needed, interfaces, and existing knowledge of the solution.
A prerequisite is that the existing complexity is sufficiently understood. Customizations, integrations, and data structures must be analyzed before the effort and risks involved in their migration can be assessed.
A brownfield upgrade is therefore not merely a technical “lift-and-shift.” It combines continuity with the need to reevaluate past decisions and abandon structures that are no longer needed.
Greenfield Reimplementation
A greenfield project can be a good option if the existing system differs significantly from the target state, either functionally or technically. This may be the case if the organization and processes have undergone fundamental changes, a significant portion of the customizations is no longer needed, or system boundaries need to be reorganized.
However, this approach requires a high degree of organizational adaptability and decision-making capacity. Management must openly champion the goal, make decisions, and support the change process.
Even with greenfield projects, there is a risk of recreating the complexity of the old solution in a new system. That is why the approach requires a clear vision, a deliberate limitation of the scope, and a willingness to truly question existing processes.
In many companies, individual factors will support different strategies. The decision is therefore based on a comprehensive assessment of the risks—not on a single factor such as the version status, the scope of customization, or the project budget.
Why a strategy that was once chosen doesn't have to be set in stone
Risk assessments can change over time. Technical knowledge is lost, applications or interfaces reach the end of their support lifecycle, security and compliance requirements increase, or organizational priorities shift.
As a result, different strategies are often implemented in sequence. A company may initially opt for a legacy run and later switch to brownfield or greenfield. Similarly, before modernization, a phase may be necessary in which the existing system is stabilized, knowledge is documented, and the subsequent project is prepared.
A more detailed analysis may also change the assessment. A brownfield upgrade that was initially planned may evolve into a greenfield reimplementation; conversely, it may become apparent that more of the existing system should be retained than originally intended.
Such developments do not constitute a fourth strategy. Rather, they show that risks and conditions are changing. A change in strategy therefore does not necessarily mean that the previous decision was wrong. The problem arises only when a decision that has already been made is no longer reviewed.
Our conclusion
Legacy Run, Brownfield Upgrade, and Greenfield Reimplementation are not stages in a progression from an outdated strategy to a supposedly better one. Each of the three options has its own distinct rationale.
However, they differ in terms of which risks they carry forward, reduce, or create anew. With a legacy run, the risks associated with existing operations remain, while the immediate risks of a major change project are avoided. A brownfield approach reduces risks associated with an outdated technical platform in particular, but may inherit historical complexity. A greenfield approach enables a more fundamental reorganization, but is associated with more extensive project and change risks.
The decision should therefore not be based solely on the version in use, the expected project costs, or the existing customizations. Equally important are the functional suitability of the existing solution, technical and personnel dependencies, the desired evolution of the system landscape, and your company’s ability to adapt and make decisions.
The key question is not which strategy is generally considered the best. What matters is which existing risks your company can continue to accept, which ones it wants to reduce, and which new risks will arise as a result of the change in question.
Since risks, objectives, and framework conditions change, this decision should also be reviewed on a regular basis.
If you are currently addressing the questions mentioned above and would like to take a structured approach to migrating from Microsoft Dynamics NAV to a current version of Microsoft Dynamics 365 Business Central, we would be happy to assist you—whether it involves an initial assessment of your current situation, evaluating the appropriate strategy, or the specific planning and implementation of your upgrade project.
You can learn more about this on our website or by contacting us directly:
In the next post, we’ll examine when it really makes sense to continue operating a legacy version. We’d like to work with you to determine when a deliberately temporary maintenance operation might be rational, what risks it entails, and what conditions should be met.
Stay up to date and subscribe to our PROTAKT blog!
About the author
DR. SVEN ODERMATT · EXECUTIVE BOARD
Board member and Team Lead Technicals – my playing field: Development, DevOps, and IT Ops.
I have been responsible for the implementation and operation of organization-wide application systems since 2002. I have been at home in the NAV/Business Central environment since 2017 – with a focus on reliable ERP operations and agile development processes that really work in everyday life.