- UPDATE STRATEGIES FOR Business Central – Part 1 –
- Why this issue needs to be addressed today
- Why it's not just about an upgrade
- What's Actually Changing as We Move Toward a Modern Version of Business Central
- Typical points of disruption in natural NAV landscapes
- What a viable vision looks like
- Three basic approaches to achieving this goal
- Why the right choice always depends on your starting point
- Our conclusion
UPDATE STRATEGIES FOR Business Central – Part 1 –
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.
Current Situation & Target: How do we migrate from Dynamics NAV to the latest version of Business Central?
Many companies today find themselves in a familiar situation: The existing NAV system is up and running, processes are well-established, and over the years, numerous customizations have been made to suit their specific organization. This is precisely why the question of what to do next is often put off for a long time. As long as the system meets business needs, a migration can easily seem like a technical issue that can be addressed later.
But that is exactly where the real challenge lies. In many cases, the transition from Dynamics NAV to a current version of Business Central is much more than a standard upgrade. For your company, it is not just about a new version number, but about the question of how sustainable, maintainable, and adaptable the existing ERP system should remain in the future. In this first post, we therefore deliberately focus on the starting point and the target vision. We also outline the three fundamental options for you for the first time: Legacy Run, Brownfield Upgrade, and Greenfield Reimplementation.
Why this issue needs to be addressed today
Many NAV systems have evolved over the course of years or even decades. They have been expanded, stabilized, and repeatedly adapted to new business requirements. This is precisely what makes them so effective in day-to-day operations. At the same time, this very evolution means that the transition to a current version of Business Central must be carefully planned today.
This is particularly evident with Business Central Spring 2019 (Version 14), or BC 14 for short. This version marks a technical and functional threshold because it is the last version with C/AL and, at the same time, the last version with a Windows client. Anyone upgrading from there to a current version of Business Central is therefore not simply moving from an older to a newer version, but to a different development and operating model.
For your company, this also shifts the focus away from the immediate task at hand. It is no longer just a matter of whether the existing system still works today. What matters is how resilient it is for the coming years. How well can it be maintained going forward? What risks arise from accumulated custom logic? And how realistic is it to reach a viable target state with reasonable effort?
This is where the crux of the decision lies, especially in ERP landscapes that have evolved over many years. Many legacy solutions have been refined over the years without every customization, every integration, and every technical dependency being fundamentally questioned. That is understandable. However, it does not make the starting point for modernization any easier.
Why it's not just about an upgrade
In many projects, the discussion begins with the target version. This is an obvious starting point, but it doesn’t go far enough. That’s because migrating from Dynamics NAV to a current version of Business Central is generally not merely a technical “lift-and-shift” of the existing system.
In fact, it involves creating a new target architecture. Legacy NAV solutions are often characterized by custom modifications to the standard system, close technical integration with the infrastructure, and specialized solutions that have evolved over the years. Much of this made perfect sense at the time of implementation. It only becomes problematic when these structures are tacitly treated as set in stone, even though the current Business Central environment sets different parameters.
This is precisely where the actual modernization task begins. It is not enough to simply clarify how the existing system can be migrated to a current version. Equally important is the question of which parts of the existing solution are functionally indispensable, technically viable, and sensible in the long term. Those who make this distinction too late quickly turn a manageable undertaking into a project that is difficult to control.
What's Actually Changing as We Move Toward a Modern Version of Business Central
Upgrading to the latest version of Business Central doesn’t just bring new features; it also changes the technical landscape. In the latest versions of Business Central, customizations to the standard system must be migrated to separate apps or standard extensions. At the same time, traditional legacy technologies such as .NET components, file operations, local print logic, direct SQL access, or certain client extensions are reaching their limits—especially in the SaaS model. In on-premises operations, some patterns may still be technically feasible, but they are often architecturally disadvantageous.
This is an important point in practice. The effort involved in a modernization project often depends not on the number of customizations, but on their nature. Ten smaller functional features are often easier to manage than a few technical legacy issues that are deeply intertwined with infrastructure, clients, or surrounding systems.
This is precisely why it is worthwhile at this point to take a sober look at the reality of your own system: Which individual solutions are actually business-critical? Which ones have evolved over time? Where are there technical dependencies that can no longer be easily maintained in a current version of Business Central? And where is the standard significantly stronger today than it was at the time of the original implementation?
In our view, there are several recurring patterns that companies should examine particularly closely when migrating to the latest version of Business Central.
Section 1: Amendments to the Standard
What used to be the most pragmatic approach is often now precisely the factor that makes it harder to move forward. When custom logic is deeply embedded in standard objects, the effort required for analysis, refactoring, and testing increases significantly.
2. Area: Technical dependencies
Direct SQL connections, local file handling, print-related processes that rely on infrastructure, and older .NET components are often taken for granted in legacy systems. However, during modernization, they quickly become sources of risk.
3. Area: Historically developed subject-specific logic
In ERP systems in particular, a great deal of knowledge is embedded not only in the documentation but also in the behavior of the system itself. This makes modernization a challenging task. After all, not every individual function is automatically of strategic value. Some are indispensable, others merely familiar. This distinction is central to your decision.
There is also a fourth point that is often underestimated: Many of a system’s unique features did not arise solely from technical considerations but evolved from organizational needs. Workarounds, additional logic, and special processes often reflect decisions that made sense at a specific point in time. During modernization, these elements should not be automatically carried forward but rather consciously evaluated
What a viable vision looks like
When we refer to a current version of Business Central as our goal in this blog series, we do not simply mean a successful go-live on a new release. What we mean is a system that meets business requirements and is technically configured in such a way that your company can better manage future changes, enhancements, and updates.
In our view, a viable target vision has four essential characteristics.
First: greater adherence to the standard. Not every old deviation from the standard is still necessary today. Especially in mature NAV landscapes, it is worth asking whether current standard functions now cover requirements more cleanly than historical custom solutions.
Second: cleanly separated extensions. Individual requirements should be clearly delineated as much as possible and not organized as opaque modifications to the standard. They should be migrated to an extension-based architecture to ensure updateability and maintainability.
Third: fewer technical dependencies. The more a system relies on local resources, direct database access, or specialized technology developed over time, the more difficult future updates and operation become.
Fourth: realistic change and testability. Future-proofing is not just a matter of the target version, but also of how changes are implemented, tested, and secured in the long term. A system is not future-proof simply because it was successfully upgraded to a new version once. It is future-proof when subsequent changes remain possible in a controlled and repeatable manner.
The goal, therefore, is not simply a version change. The goal is an ERP landscape that, after the project, can be operated, expanded, and further developed more effectively than before.
Three basic approaches to achieving this goal
In our view, this situation gives rise to three strategic options for action.
Legacy Run (Maintenance Mode)
With a Legacy Run, the existing solution continues to be operated with as few changes as possible. The focus is on stabilization, maintenance, and risk mitigation, but not on fundamental modernization.
A Legacy Run can be a sensible option if your company wants to deliberately buy time. However, it is not a permanent state, but rather a controlled maintenance operation with clear boundaries. The longer this path is chosen, the more important it becomes to manage risks consciously and take a realistic view of the system’s remaining future viability.
Brownfield Upgrade (In-Place Modernization)
In a brownfield upgrade, the existing system—including its code and data—is upgraded to a current version of Business Central. This approach is often the most pragmatic because processes, data history, and established system logic are largely preserved.
Brownfield upgrades are therefore often a realistic option, but not necessarily the easiest one. In particular, legacy technical issues and ad-hoc solutions that have evolved over time must be properly categorized and addressed. The advantage usually lies in greater continuity, while the disadvantage is often that some of the existing complexity is carried over.
Greenfield Reimplementation
In a greenfield reimplementation, the existing system is not technically upgraded; instead, a current version of Business Central is set up as the new standard system. Required functions are specifically reimplemented, and data is selectively migrated.
Greenfield is therefore often the cleanest approach, but it demands the greatest discipline in terms of scope, prioritization, and organizational change. The main benefit lies in the opportunity to more thoroughly scrutinize technical debt and historically developed workarounds.
Why the right choice always depends on your starting point
At this point, it would be tempting to immediately rank these options: Greenfield is best in the long term, Brownfield is the most pragmatic, and Legacy Run is merely a stopgap solution. That wouldn’t be entirely wrong. But this simplification isn’t sufficient for a sound decision.
The right strategy always depends on your specific starting point. This includes, among other things, the actual degree of customization, the type and criticality of existing integrations, the importance of historical data, the company’s willingness to change, and the question of how quickly a supportable state must be restored.
This is where the real leadership challenge lies, particularly for IT management, ERP managers, and project leaders: not to make a hasty technical decision, but first to clearly assess the reality of their own system. Only on this basis can a sensible decision be made regarding which path is viable for your company from a business, technical, and organizational perspective.
Our conclusion
The journey from Dynamics NAV to a current version of Business Central doesn’t start with choosing a target version. It starts with a realistic assessment of your current situation.
For your company, this is not just about technology, but about a more fundamental question: How sustainable is the existing ERP system, not just for today’s operations, but for the coming years? It is precisely at this point that the decision is made as to whether pure maintenance operations are still justifiable, whether a brownfield upgrade makes sense, or whether a greenfield reimplementation is the cleaner option in the long term.
From our perspective, one thing is particularly important here: Do not treat this decision as merely an upgrade issue. In many cases, it involves technical viability, future updateability, dealing with historically accumulated customizations, and a target vision that will still be manageable in a few years’ time.
If you are currently grappling with 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’s assessing your current situation, evaluating the appropriate strategy, or planning and implementing your upgrade project.
You can learn more on our website or by contacting us directly:
In the next post, we’ll take the next logical step and systematically compare legacy runs, brownfield upgrades, and greenfield reimplementations. Then we’ll examine which decision-making criteria actually hold up in practice and which typical scenarios tend to favor one approach over another.
Stay informed 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.
Space for your comments