As we delve into the latest features and upcoming versions of Business Central, it’s essential to understand the implications of the newly introduced concept of the “jump version.” Let’s explore what a jump version means, how it affects partners and customers, and the benefits it brings to extensions.
Understanding the Jump Version
So, what exactly is a jump version? Essentially, it’s a fresh name for an existing concept that has evolved over time. In the past, when upgrading from earlier versions of NAV, users often encountered several hurdles. For instance, if someone was transitioning from NAV 2009 to Business Central 14, they had to upgrade to Business Central 2015 first. Thus, 2015 was considered the jump version. This process was cumbersome and often fraught with complications.
However, with the advent of Business Central 24 and 25, users can now upgrade directly from any previous version to Business Central 25 or Business Central SaaS. This eliminates the need for intermediate upgrades, simplifying the entire process. This shift is monumental because it means that when upgrading a customer, they no longer need to go through multiple versions before reaching the latest one.
The Future of Upgrades
Looking ahead, the new upgrade strategy dictates that if a customer is on Business Central 14, they will need to upgrade to Business Central 25, which becomes the designated jump version. From there, they can move to 26 or 27 on-premises or transition to Business Central SaaS. This requirement is crucial because it ensures a streamlined upgrade process without the complications of previous versions.
It’s important to note that this is not just a one-time change. Moving forward, every five major releases will introduce a jump version. This means that 25 is a jump version, followed by 30.x, and so on. So, if a customer wishes to upgrade to version 26.x, they must first upgrade to 25.x.
The Rationale Behind Jump Versions
Why has Microsoft implemented this jump version strategy? The answer lies in the management of obsolete fields and tables. Back in NAV, Microsoft had introduced a property at both the field and table levels called “obsolete state.” This property could mark tables or fields as obsolete, pending removal or confirmed removal. However, many of these obsolete items still lingered in the database, impacting performance.
With the introduction of Business Central, particularly in SaaS environments, Microsoft has adopted a different approach. They can no longer make destructive changes, such as deleting fields or tables, without a significant impact. Instead, they must navigate these obsolete items carefully. The jump version strategy is a way for Microsoft to clean up the underlying database by ensuring that upgrades align with the latest schema, thus removing the risk of obsolete clutter.
Benefits of the Clean-Up
- Improved database performance: Removing unused schema elements will optimize performance and reduce technical debt.
- Unified Base Applications: Multiple countries (such as, Sweden, Denmark, Czechia, India, and Iceland) and partner-localized regions will move towards a unified Base Application. The goal is to have all countries based on the same codebase.
- Improved maintainability: By removing more than 10% of tables and table fields, Microsoft has simplified development and made it easier for developers and product owners to manage changes.
- Streamlined codebase: Cleaner code results in fewer errors and easier maintenance for developers.
Implications for ISVs and Partners
The introduction of jump versions has significant implications only for Microsoft.
Independent Software Vendors (ISVs) and partners developing solutions for customers don’t have that option yet. ISVs must adhere to Microsoft’s policy of avoiding destructive changes. This can lead to a buildup of obsolete fields within their applications, making it essential to monitor how these changes are managed during jump upgrades.
For partners and independent developers, the ability to delete obsolete fields during the upgrade process is something I expect should be added. This means you can break down extensions into logical pieces, simplifying maintenance and ensuring that the codebase remains clean and comprehensible for new developers joining the team.
Preparing for Future Changes
As we anticipate the release of Business Central 26.x, keeping a close watch on the upgrade processes is crucial. This version will likely provide glimpses of how Microsoft handles obsolete fields and tables. The excitement surrounding these changes is palpable, as they promise to make our code cleaner and easier to maintain.
The jump version strategy is a significant step forward for Business Central. It simplifies the upgrade process, ensures cleaner databases, and offers opportunities for developers to refine their applications. As we move closer to the release of version 26.x, let’s continue discussing these changes and exchange insights on adapting to this new framework.
Join the Conversation
What are your thoughts on the jump version initiative? Do you see it as a valuable step forward? Check out my video on “Breaking New Ground: The First-Ever Jump Version of Business Central” for further insights and share your perspective with the BC/NAV UG Community!
The post The First-Ever Jump Version of Business Central appeared first on Dynamics Communities.