Let’s Compare: GP to BC Managing Upgrades and Updates
One of the largest differences between Dynamics GP compared to Microsoft Dynamics 365 Business Central is how software and version updates are executed. In the GP world, we have been fully in-charge of how and when we consume the code updates provided by Microsoft and ISV solutions. Many GP environments have rightfully adopted the ‘every other year’ cadence, which balances the need to apply bug fixes, and enhance functionality, with the disruption and risk a major system update can create for the users and some companies as a whole.
In the Business Central SAAS world however, the tools, techniques and timing are very different, and the process is a whole lot more automated. This post runs down many of the specific differences between updating the environments, from a system admin perspective, for Dynamics GP and BC.
Dynamics GP Upgrades
While Microsoft has traditionally been putting about 3 updates per year into position for Dynamics GP, rarely does a customer actually apply them all. The October release has the new features, the November/December release has the Year-End update for payroll users, and the spring release has some bug fixes and localization updates. While the end of life has been announced for GP, we still want to apply updates to remain current, secure, and on a supported release. Here is what to expect for the next few years:
Over the past 2+ decades, I have had the distinct pleasure of performing well over 400 GP upgrades of all shapes and sizes. I’ve heard horror stores, seen and inflicted a few battle wounds, and cleaned up a lot of messes from failed or sloppy GP installations. It takes a lot for anyone to fully understand all that could go on, in, around or through GP, and I commend all of those who do, especially for the really large and complex environments.
One of the topics I’ve enjoyed helping GP users with is planning for and executing on a GP update (usually the latest patch, often done in-place) or a GP upgrade (typically more than one version hop is required per the supported upgrade path/hot topic). The freedom to be totally in control of when, where and how the updates are applied is important for a system administrator.
To learn more, please visit this DynamicsCon Virtual YouTube video called “Stack the Deck for Success on your Next Dynamics GP Upgrade” where I cover 14 steps to an upgrade project you should know about. Please smash a THUMBS UP on it before you leave! The DynamicsCon folks have done a great job curating incredible educational content for both GP and BC, among other platform applications, and I am incredibly honored to have been a part of it 4 times now training on GP, BC, and of course…Power BI!
Business Central Updates
Business Central updates are different than GP because they are constant, you don’t have to download any new code. In fact you don’t have to do much, or really anything at all! I know for some, this sends shivers down the average GP Admin’s body because they suddenly lose control of the situation. Rest assured, that is not entirely true, so let’s have a good look at the update process for BC, to help quell any fears and position you for how things actually dramatically change for the better.
You should first know there are two primary ‘wave’ updates made ‘Generally Available’ in April and October each year. There are also monthly minor updates that roll into Business Central seamlessly as well every month. The schedule below highlights the two big waves, and the timelines you are granted for creating a Preview environment (new version, but not your data) and a new Sandbox environment (new version can be applied separately from production to your data for testing and development work).
The D365 Business Central Admin Center is your command and control center for managing all of your BC environments (both Production and Sandboxes). It offers you a one-stop-shop for managing the ‘database’ environments from a UI perspective. This site is reserved for true BC administrators, referred to as a ‘Delegated Admin,’ and assigned in Azure to their Entra user account.
As new releases have become generally available, the BC Admin Center has been accumulating more sophistication, and playing an increasingly more important role for the BC administrator. Click the button for all of the latest details, but here I’ll summarize a few key elements that it controls:
Create New Environment - This is truly remarkable. For comparing this ONE BUTTON in the BC Admin Center to setting Dynamics GP to the same level, it is equivalent of:
Setting up a brand new server
Installing SQL server and all of the related services
Creating the backup jobs for disaster recovery
Installing all of the products / dictionaries available on the installation media
Installing the sample database
Publishing the new environment available to anyone who needs it
Copy Existing Environment to Sandbox - This button will initiate a FULL COPY of the production environment (e.g. ALL companies, setups, security, and reports) and port them over to a separate, brand new sandbox environment. This is also remarkable for GP administrators because this is the equivalent of standing up a completely separate server, such as a GP DEV or TEST environment. Most GP customers don’t really invest in this because it comes with so much overhead (e.g. another server, SQL instance to manage, prog files install, reports and product dictionaries, security and access, Windows updates, services, etc.)
Delete Environment - This is the equivalent to GP of retiring a server. Unplug it, take the server offline, or power it down.
Restore Environment - Thankfully, BC keeps your deleted environments for 2 weeks, just in case, so the equivalent here to GP would be plugging the server back in, powering it back on, and making sure you can log in and see everything again.
Rename Environment - In Dynamics GP, we are pinned to the SQL Server name for data connections. The equivalent here would be a lot like renaming the SQL Server instance and the SQL Server name, but without all the other file-level and network-level issues that come with authentication after the change sometimes, and redoing the ODBC on the workstations and other data sources. Renaming an environment is an important part of the BC Disaster Recovery process. The name of the environment lives in the URL, and is the point of entry for end users with their browser.
The BC Admin defines who gets notifications in advance when an update is going to be pushed out to BC, so anyone who has a stake in knowing about upcoming updates can be in the loop without a lot of extra effort.
Overseeing ‘disk space usage ’ is done in the Admin Center as well. The Capacity page gives you insights, similar to what we would be able to observe in SQL Server Management Studio and Windows for running Dynamics GP. However because the SQL data environment is managed in the cloud, key statistics and drill-thru links to large table data can highlight where consumption actually lies within the database.
Business Central updates can be initiated on-demand as well, and they usually process in a matter of minutes, so if you saw one you wanted to ‘force-apply’ it can easily be completed.
In March 2025, Microsoft is extending the window we have to adjust and prepare for major updates to five months. In the admin center, once the release becomes available, the administrator can set the update date out much further, which allows more time for developers and the rest of the integrating or reporting products to prepare and test in a sandbox.
What happens if people were IN Business Central when the update occurs? In its most simplistic form, their sessions first get paused, and then the environment drops ‘offline’ while the update is processed. Once the environment is back online and available again, the URL becomes valid, and users can log back into BC. The major updates take longer than the minor ones do, regardless, they frequently take less than 5 or even 10 minutes to update all companies. Naturally, the larger the data environment, and the larger changes in the update, the longer the update process will take.
Telemetry
The savvy BC administrator can also utilize Telemetry and either Subscriptions or Alerts in the Power Platform to monitor validations, code updates, and more, regardless of their outcome. These Application Insights can be helpful to know about as they highlight a number of elements about preparation for, and completion of an upgrade, you otherwise would not have.
Telemetry happens to be one of my favorite topics to introduce new users to at conferences, and one session I put together that has gotten so much great response is called “Breaking Into the Benefits of BC Telemetry.” In the presentation, I cover a number of examples showing what the update process looks like using the dashboards within the telemetry reporting app. For example, this screenshot below shows where Business Central had run validation on customizations for the next 10 build updates!
Another benefit of using Telemetry is reviewing all of the permission changes that come about, especially in one of the major updates, however be sure that permissions are definitely updated in the smaller ones too!
Another benefit of telemetry is seeing how long it takes to process the update, and a little of what happens ‘behind the curtain’. It’s a lot like what we do with GP updates, but it is completely automated.
I have to thank Kennie Pontoppidan and his team from Microsoft for all the support and advice he has given about telemetry not just for myself but the BC community as a whole! The telemetry Power BI applications have been super-helpful and insightful over the years, and for a GP System Admin, I have found them insightful in my transition to Business Central.
So…How to prepare before all of these automatic updates!?
Stay on top of what is changing in BC, and determine regularly if the changes even remotely effect your environment. Many times there is a wide window of time allowed to adopt or adjust to structural changes in the database and application, but having your antennae tuned to what might require some level of testing or shakedown will pay dividends.
Microsoft has an online planner which I use to see upcoming features and changes, and I bookmark the items I want to follow and monitor. Visit periodically because it does get updated frequently, especially around the wave releases when new features are announced and ready to roll.
One trick when using this online tool is to make sure you have it filtered to ONLY D365 Business Central, or the list will be incredibly long when you add in all of the other products! Don’t be shy though - check out the other product enhancements like Power Bi and be on top of your game there too. The features are categorized, and laid out by timeline as well, which makes it easy to see what might sideswipe, or more likely enhance, your ERP environment!
Each feature has a pop-down description that summarizes the change, provides a link to learn more, and a timeline for when the change will be available. There are various phases to releasing new features for BC, such as early access, preview, and general availability. One nugget I learned along the way is that the minor updates are just as important as the major ones sometimes. Microsoft tends to announce new ‘wave’ features, but not actually make them active or available for a couple of months after the major, instead coming out in a minor release.
Customizations
If you have customizations, BC validates each Per Tenant Extension (PTE) prior to applying any base code changes. Notifications are emailed to the BC notification list. If there is an update coming where a validation has failed for a particular version, it will require a developer to adjust their code to comply with the forthcoming change, and then deploy an update to their extension in Production, before the actual BC update will be successful. Ultimately, if you wait too long, BC will update their code and disable yours, so ensure you pay attention to the email notifications that get sent all the time.
Failure notices get sent if there are any issues with an update. While I don’t love getting hate mail from my ERP system, the rollback is all handled as part of the process by Microsoft and I don’t have to put anything ‘back’ like I would if if was GP. Thankfully this is all purposefully designed to keep it working with 99.99% uptime! That is a comfort I have embraced with BC now, having supported hundreds of Dynamics GP environments, where anything can go wrong at about any possible time.
New functionality and deprecation of prior code units are introduced with new updates as well. This can be tricky to maintain, so make sure you have a good code repository and a developer who can quickly assess if any of your customizations are at risk when tables, fields, or code units are changing or being removed entirely. For example, learn more about a big upcoming initiative for v26 we are all studying up on now:
ISV solutions on AppSource
Apps from AppSource that update automatically are usually very reliable, however they can also create some challenges with your customizations and even reports in BC. Many times their code is completely blacked-out when debugging an unexpected issue a user reports, and you have no idea what they are doing in their extension. If you utilize AppSource ISV solutions in your environment along with customizations or integrations, it is advisable to actively engage in a full-out test in the short window of time you get when you can copy a pre-update PROD environment to a new SANDBOX, apply the wave update, push in PTE and test customizations and integrations.
Integrations
For the most part, when integrating with Business Central, you are using the API, much like you would use the eConnect service or Web Services with Dynamics GP. If you are still using Integration Manager however, that is a different story entirely.
With the BC SAAS platform, your integrations will actually be coming from a lot more, and more diverse connections. Some integrations are indeed push-button in BC, but others are timed events in the Job Queue, and many are pushed in from outside applications. Generally after creating a Sandbox environment, you need to manually enable each integration, but for updates in a BC Production environment, the API would be available after the environment came back online from an update.
Power BI Reports
When BC goes offline and does its automatic updates, you may get an email from the Power BI Admin Service indicating a transient refresh issue. Watch to see if there are any more on scheduled reports, to make sure there aren’t any issues with the BC Web Service endpoints used in them.
Feature Management
Not found in the BC Admin Center, the Feature Management page in the BC application would allow the administrator to perform the initialization of new features or code which pose new opportunities after an update, or perhaps enable the early use of a new component for Business Central.
So much more!
The essence of this post is to help the GP user see how Business Central is different from a wide variety of angles with respect to managing automatic updates to the ERP system, because it is a wild departure from what we are used to in GP. Manageable? ABSOLUTELY! It has been a great experience for this veteran button-pusher!
Furthermore, the BC Admin Center has a whole lot more to offer than I am covering here in terms of functionality, but that is a topic for another day. Each new release brings changes and opportunities to explore with how we can support and administer BC. While the specific tasks, tools and techniques are different in the two ERP systems, there are definitely still separate roles to play for the everyday user vs the BC administrator.
My experience administering Business Central has been a huge relief versus that of Dynamics GP. While I loved making sure everything was installed at the proper version, with the right products, on all the machines, across the entire network with GP, the burden doing all of this with Business Central is a mere fraction that of GP.
I’m grateful should this experience or these insights be helpful to you on your journey…until next post!