As everyone of you already know, Dynamics 365 Business Central is actually available on-premise and in the cloud (SaaS). Despite the Microsoft proposition, many customers are still full with doubts on what is the best choice for them: am I ready to switch to a fully cloud-based solution or do I need more time for this transformation? Do I need to stay in the on-premise world?
These considerations must be carefully evaluated case by case and saying that the cloud is the way to go for everyone is absolutely wrong.
Despite these considerations, here we want to analyze the impacts on moving your ERP to the cloud by focusing our attention not on the development platform (we’ve talked about it in the previous articles) but instead on two totally different aspects: upgrades and data migration.
In the on-premise world, you are responsible of the platform and you manage the upgrades. Microsoft will never force you to upgrade the platform, so it’s totally your responsibility to be updated and patched or not. You are responsible to perform platform and data upgrade and checking schema changes.
Regarding upgrades for the on-premise, Microsoft has introduced the Upgrade Tags in order to exacly know if an upgrade is applyed to the platform. An Upgrade codeunit that uses Upgrade Tags has the following pattern:
With this pattern, you mark your code with a tag (format as per your choice) that identifies the upgrade phase and you can know the state of your platform.
In the SaaS world, all is instead managed by Microsoft on its own datacenters. The SaaS platform upgrade is actually managed with the following phases:
- Monthly releases: they will contain minor changes and bug fixing, but no breaking changes. These upgrades are normally considered as safe and they will not need data migration codeunits.
- Releases every 6 months: this is normally a major release with major changes. This release could have an impact on your extensions and you need to carefully check for that. This could require data migration codeunits.
During the upgrade phase, Microsoft will automatically try to perform the tenant upgrade in a transparent way for you. If you want, you can set the desired upgrade time slot for your tenant (via the tenant Admin Portal) and this ensures that your tenant will never be updated in that time slot.
During the upgrade phase, extensions are disabled, platform is upgraded and then all is enabled again. Your tenant will then run on the new platform.
If the tenant upgrade fails, remember that:
- The tenant is automatically rolled back to the old version;
- A bug ticket is created on your admin portal (you have an alert that the upgrade is failed);
- If there are extensions that break the tenant upgrade (normally this is the cause) you (or the extension’s developer) need to fix the issue as soon as possible (the slot is normally 2-3 weeks, but this is not official). After that period, the extension is uninstalled and the tenant is upgraded to the new version.
Regarding database (extensions upgrades) remember that in the SaaS platform SQL schema breaking changes are ALWAYS not allowed. If you have breaking schema changes (table changes, field changes, key changes and so on) you need to handle that by using the ObsoleteState property in your objects as described in Stefano Demiliani blog post here.
- Fields are set as ObsoleteState = Pending in the current release
- Fields are set as ObsoleteState = Removed in the next major release
One important thing to remember that could affect a tenant upgrade: do you remember the wonderful (but not so much) In-Client Designer? The In-Client Designer permits to an advanced user or a consultant to customize a Dynamics 365 Business Central page without using Visual Studio Code and AL. With the In-Client Designer you can add new fields to a page by choosing from the available fields in the source table or you can add new actions or sub pages. When you save this customization, the In-Client Designer creates an extension for you (and you can also download the source code):
What’s the bad part of that?
Unfortunately, actually the In-Client Designer creates an extension that is dependent from all the extensions installed on that tenant. If your consultant has created an extension is this way (maybe to satisfy a customer request), a future tenant upgrade could be affected (the upgrade could fail because you can have an extension that is dependent from a missing or removed extension and so on).
When using In-Client Designer, remember that you need to always download the code and remove dependencies if you want to be safe. Dynamics Partners is hoping Microsoft will soon change this behavior and the generated extension will be dependent only on what it really needs.
If you have published an app on AppSource, you should continuously test that this app works with the next Dynamics 365 Business Central version (Insider builds). The Insider builds are normally updated daily and the tenants are updated monthly to this version. When the tenants are updated to this version, the image is also released on docker hub for the public.
When moving to the SaaS environment, you need to handle the task of data migration. This data is needed for your customer and you need to find a way to move this data to the new cloud tenant.
There is no possibility to access the database in the SaaS environment and no possibility to write the data directly via SQL or similar tasks. To handle data migration from NAV to D365BC SaaS, we suggest one of the following choices:
- Use Rapidstart (Configuration Packages).
- Use Intelligent Cloud.
- Use custom import via APIs.
Configuration Packages are useful if you need to import not too large amounts of data by using Excel sheets and for a consultant it’s the first choice. You can check the data with your customer and when they’re ready you can import it via the Dynamics 365 Business Central UI:
APIs and web services are more “developer oriented” way of performing data import (we don’t want to talk too much about that here) but if you need to load a large amount of data, in my opinion it’s one of the most effective way. You can expose your entities and you can load data from on-premise to the cloud by using an Http Client that performs POST operations.
The Intelligent Cloud is a great service that permits you to sync an on-premise Dynamics 365 Business Central installation with a SaaS tenant.
When activating the sync, remember that Business Central (SaaS) determines data that will be replicated. Ensure that your installed Business Central (SaaS) extensions match your installed Business Central (on-premises) extensions. Business Central (on-premises) will determine companies, which are available to replicate data from. Data replication will overwrite any existing data, which you have stored in your Business Central (SaaS) tenant.
To activate Intelligent Cloud configuration, you need to have installed Intelligent Cloud Base extension on your system:
You can specify the tables, which must be replicated by using the new ReplicateData property (available in AL and C/AL):
The schema between the on-premise and on-cloud instance must match. Otherwise, the table will not be synced. You will not be able to have modification in C/AL in your on-premise table.
To perform an upgrade and migration to the SaaS platform using the Intelligent Cloud, you need to:
- Migrate your C/AL customization to extensions.
- Upgrade your on-premise database to D365BC on-premise and use only extensions.
- Sync data to the SaaS tenant using the Intelligent Cloud.
To start the data sync process, you need to start from the Intelligent Cloud Setup and provide the credentials to access your on-premise database (SQL Authentication is required to access the on-premise DB). The connection string is securely passed to Azure and stored in the Azure key vault. You need to download and install the Self Hosted Integration Runtime application, which is required to enable the connection between on-premise data and the cloud tenant (it can be installed once and it can support multiple pipelines).
You can check the sync process by accessing the Intelligent Cloud Management page in D365BC:
- View replication history.
- Trigger a manual replication.
- Schedule the replication.
- Manage the authentication key.
- Disable the Intelligent Cloud (you can do this at any time without affecting on-premise or on-cloud data).
If you have Extensions V1 in your on-premise database (for example NAV), remember, that they’re not supported anymore. These extensions must be uninstalled and upgraded to a V2 version. The data must be read from the archived data of the V1 (NAVAPP.RESTOREARCHIVEDATA) and updated accordingly.
Do not forget an actual “problem” with Intelligent Cloud: when Microsoft applies a cumulative update to the online tenant, this CU can create schema differences with your on-premise tenant (in the case if you’ve not applied the same CU in your server). This will affect the sync process with the cloud (the sync will stop). Microsoft is working to solve this and we hope it will be completed in the nearest future.
Intelligent Cloud is a good way to start moving your data to the cloud. You can continue working with the on-premise version, but at the same time you can have a live tenant in the cloud and start using it for different purposes (for example data analysis) or use as your main platform when you’re confident to switch.
Simplanova team is ready on helping Dynamics Partners on this transition journey. We have made more than 110 happy customers on different NAV upgrade projects. Our team is ready to ensure your professional transition from Dynamics NAV to Dynamics 365 Business Central. We offer Add-on Upgrade to Extensions in Microsoft Dynamics NAV, Microsoft Dynamics NAV / 365 Business Central Development, Dynamics NAV Extensions Workshop and more services, related to Dynamics NAV upgrades or development. Now it’s your decision to make the jump. Contact us and get a FREE Quote of your project.