OK, I apologize for the laundry list of questions, but I have spent considerable time trying to wade through the myriad of posts and haven't found clear answers. I am sure they are out there, but I need to report upwards on a plan of action sooner rather than later.
We are planning a customer upgrade from NAV 2013 to D365 Business Central On-Premise (with the vision of eventually transitioning to Cloud)
I have a fairly good handle of the usual upgrade process but have yet to do one with the conversion of logic to events/extensions, etc.
I think migrating all/most of the business logic to events and extensions is pretty straightforward, my questions are mostly around Table Data.
QUESTION: If I convert existing custom fields (50000..99999) to table extension fields will the upgrade toolkit manage these, or do I need to create interim step processes to manage this? If I have to create an interim step, does anyone have recommendations on best practices?
OK thank you. I knew that moving the 'code' would be a manual process, I was hoping that there might be a tool to migrate the 'data' itself. I will bring this information back to the team
Thanks again!
There's no upgrade toolkit that can perform a data conversion from C/AL to AL, you can use Txt2Al to migrate your objects to the new platform but moving to extensions is a step that you have to perform "manually".
Obviously, BC on-premise supports C/AL again, so if you want to move your C/AL codebase you can do that with upgrade toolkit without problems (by merging objects and so on). Moving your application to extensions is instead something different.
Yes, I understand that there is no direct migration from NAV 2013 to BC - I suspected that I would have to migrate them (objects and Data to 2018), but I would like to pull the custom fields out of the database between 2018 and BC - will the upgrade tool be able to manage this? The ID's would be the same, the difference being that the field wouldnt actually be on the table, but rather in the tableextension.
There are no plans for migration tool from NAV 2013 to BC. What you can do (and this what personally I’ve done) is to move customization from C/AL to AL. Then move your customer first to BC on-premise by importing all data you need (master data and transactional data) from NAV 2013 to BC (you can do that in different ways, from RapidStart to direct SQL inserts), then move to the cloud in a second step. For this second step, you can use Intelligent Cloud for automatic replication of your BC onpremise db to the SaaS platform. Pre-requirements: all must be Extension-based.
Stefano will you provide more detail on your data migration statement? Is this only master data or are you referring to master data AND transactional data. If a client is on NAV 2013 R2 hosted their goal was to be in the cloud in the first place and that was the best option when they launched. At this point I don't have a clear understanding of how to get them to D365 BC Cloud while giving them access to their historic transactional data. Since they are hosted and have no infrastructure it isn't practical for them to pull all of the NAV data into SQL and make SQL inquiries because they will have to pay for space on a server somewhere for the NAV data and for their BC instance. Ultimately, the goal is to provide the most economical way to modernize them to BC Cloud while providing access to historic transactional data. The question is if transitions like this are on the development path forward for Microsoft or not. I don't want to make the client wait for something that isn't going to be available anytime soon.
Thanks for all the information that you provide. It is very helpful.
No, upgrade toolkit does not manage that changes.
Data migration is not a very big problem in my opinion, you can use Rapidstart and export data from the original system in an excel file and import them into the new D365BC database.
The biggest problem is obviously rewriting code with the new extension model (mandatory if you want to go to the cloud, not mandatori for BC on-premise).