Open Forum

  • 1.  BC 14: When to plan upgrade to BC ?? (20?)

    SILVER CONTRIBUTOR
    Posted 11 days ago
    Hi,

    We just completed our upgrade from Nav 2015 to BC 14/On Prem.  It went really well - and in only 48 hours we were operational.

    After the dust settles, we'd like to develop a plan to upgrade to current BC.   We use Vicinity Manufacturing along with BC - and we'd like to make use of the "latest and greatest" features involving the integration of the 2 platforms, which requires us to be current on BC (I think, anyway.)

    How big of a project is it, to convert from BC 14 to "current BC?"

    (I'm thinking that it's not as big of a jump, as it was from NAV 2015 to BC 14, but, I am not a NAV/BC Upgrade professional.)

    We are already discussing planning a conversion project for fall of 2022, well before Thanksgiving.

    Is this a good plan?  Are we better off to wait, or go sooner?   Does it make sense to jump from BC 14 to current?  or, should we go in smaller jumps?

    Any advice, especially from those with upgrade/conversion battle scars, will be appreciated.

    Thanks,

    -Kevin

    ------------------------------
    Kevin Brennan
    Director of IT at Mayco Colors
    Hilliard, OH
    ------------------------------


  • 2.  RE: BC 14: When to plan upgrade to BC ?? (20?)

    Posted 7 days ago
    Congratulations on upgrading from NAV 2015 to BC 14. We recently just did the same upgrade over a weekend and have the same goal as you: to get to "current BC".

    I'm not a dev, but here is what I know:
    The challenge past BC 14 is that any C/AL code cannot carry forward. For us, we have a two ISV solutions that run on C/AL, plus years of custom development that uses C/AL too. This will all need to be re-factored into AL code (aka extensions + eventing). We plan to start tackling our custom development soon (and all new development going forward we will use AL code so as not to further increase our technical debt). We still need to engage with our ISVs to asses what the migration path is to their newer code. It's very early days for us on all of this, but I think the total time will be measured in quarters or years, not weeks or months.


  • 3.  RE: BC 14: When to plan upgrade to BC ?? (20?)

    SILVER CONTRIBUTOR
    Posted 7 days ago
    So, we have similar projects ahead of us.  It's very helpful to me (as I'm new to my company and new to BC in general) to know that we're on a shared path with other companies.

    My first big challenge or big question is:  how to define the scope of work:

    How do we inventory the list of c/al objects that need converted/managed?

    Of, if an inventory list is not available, how do we detect those objects?

    Worst case:  we could convert into a new environment and use the Test Catalog (manually running all of our test scenarios) to expose "what doesn't work the way we expect it to," due to missing code/missing functionality.  That would be a very large effort.

    Best case:  there's a list someplace in BC of "custom objects."

    Is there a way to take a standard BC 14 environment and run a "what's different between our prod environment" and the clean copy?  I'm thinking back to my database days - I think we had a tool to point out the differences between 2 databases (structurally, such as tables, views, etc).  I wonder if something similar exists to compare a "client's BC 14" to "BC 14 out of the box."



    ------------------------------
    Kevin Brennan
    Director of IT at Mayco Colors
    Hilliard, OH
    ------------------------------



  • 4.  RE: BC 14: When to plan upgrade to BC ?? (20?)

    GOLD CONTRIBUTOR
    Posted 7 days ago
    Edited by Robert Jolliffe 7 days ago
    Hi Kevin and Doug,

    We have done quite a few NAV 20xx to BC 14 upgrades in the last year or so.

    To be honest - we stopped migrating the C/AL from the old system to using C/AL back when we upgraded customers to NAV 2018 (AL was in NAV 2018).  The reality is that the tools used to migrate C/AL code to a new version take almost the same time as migrating C/AL to AL.

    The big challenge is that the AL tables (the tables created by code) are actually different SQL tables.  After trying some different methods, we finally wrote a tool that creates all the SQL statements needed to migrate the data.

    Here's what I would do if I were you. Copy your live company, copy the entire SQL Database and spin up a test instance.

    1) Identify your modified objects (there is a "modified check" in C/AL - and the Version should have a "note")
    2) Start converting your C/AL to AL - ForNAV makes a great tool to help with this
    3) Create the SQL statements you will need to move data from the Live database to the Test database
    4) Get some users to test in the TEST instance as you make changes
    5) As you finish off some code and its working, delete the C/AL code and copy the new AL code into your LIVE database, run your SQL and transfer the data.

    Basically rinse, wash and repeat until you get rid of all your C/AL code.

    Once you have no C/AL code and all your custom fields and tables are in AL extensions - the move to the cloud is actually really simple.

    if you are going to upgrade to BC 14 (locked in but haven't started really) then I 100% think you should convert your C/AL To AL everywhere you can.  Here's a walk through of the upgrade process and there's an associated video too if you want to see what that looks like (not the AL coding - more the upgrade). https://www.sabrelimited.com/blogs/10-easy-steps-upgrade-dynamics-nav/

    And I recorded a YouTube that more or less walks through the process to run a cloud migration. https://www.youtube.com/watch?v=DxhTHOLyuqU

    That video has a bit of an older process but I did it again a few weeks ago and it's almost exactly the same.

    Hope that helps someone


    ------------------------------
    Robert Jolliffe B.A.Sc, MCSE, MCS - NAV Manufacturing Expert
    President
    Sabre Limited
    Cambridge
    robert@sabrelimited.com
    www.sabrelimited.com
    ------------------------------



  • 5.  RE: BC 14: When to plan upgrade to BC ?? (20?)

    SILVER CONTRIBUTOR
    Posted 6 days ago
    Thanks, Robert,

    This gives me a structured approach for how to start the work.

    2022 will be an interesting year.  We're highly motivated to pay off our technical debt.


    ------------------------------
    Kevin Brennan
    Director of IT at Mayco Colors
    Hilliard, OH
    ------------------------------



  • 6.  RE: BC 14: When to plan upgrade to BC ?? (20?)

    Posted 7 days ago
    Here are my recommendations for upgrading your current BC 14 on-prem environment.

    First, you definitely should upgrade to the latest BC version available. This is because the effort is the same to go from BC 14 to the next version or the latest version of BC.

    Secondly, this particular upgrade is where your technical environment will change. For instance, during this upgrade you will move from:

    1.  The C/AL to the AL development environment.

    2.  All modifications to base objects - both for BC and your ISV add-ons - will need to be decoupled from the base and "evented" and then published as extensions. The good news is that once this is done, your upgrades will be significantly easier, less costly, and less disruptive to the organization.

    3.  To tie in with number "2" above, all add-ons have to be migrated from their C/AL to AL Extension version. You will need to reach out to Vicinity to see if they provide a migration path or toolset to move your data and possible customizations between the versions. You should check with your partner to see if they have created tools to migrate your data and customizations if the ISV does not provide assistance.

    As a further note, although you may be using the Web client today, the Role Tailored Client (RTC) will go away and all users will need to use the Web client.

    For sure, the best plan is to plan now. Moving to the latest BC version will get you to what we call "utopia" - again whereby your upgrades will be so much more simplified going forward. You should be able to keep pace with the Microsoft release schedule at this point if you so desire.

    We have completed 100s of upgrades, and we have found that the key factor affecting the upgrade project length from start to finish depends upon the number of customizations to base objects in your current environment that need to be migrated forward / decoupled and evented.

    Best of luck to you.

    -Christine

    ------------------------------
    Christine Satariano
    Upgrade Specialist
    ArcherPoint Inc
    Cleveland OH
    ------------------------------



  • 7.  RE: BC 14: When to plan upgrade to BC ?? (20?)

    SILVER CONTRIBUTOR
    Posted 6 days ago
    Thanks, Christine

    Great overview - Very helpful.


    ------------------------------
    Kevin Brennan
    Director of IT at Mayco Colors
    Hilliard, OH
    ------------------------------



  • 8.  RE: BC 14: When to plan upgrade to BC ?? (20?)

    GOLD CONTRIBUTOR
    Posted 22 hours ago

    Kevin, You shouldn't have to use SQL scripts to move your data from old to new. MS supplies a new upgrade toolkit with each minor and major release. Those toolkits include all the migration scripts. There are exceptions. When you create your table extensions(one for each modified base table), you need to move the data from the modified tables to the extended table. I would do this in code. We have a generic codeunit that does that. It uses RecRef, FieldRef. This allows you to use the same methodology for moving data for each company, table field etc... SQL Scripts are one time use and may not seem like a problem, but after performing hundreds of upgrades over the past couple decades, I've seen nightmares with SQL scripts. They are un-maintainable and largely for one time use. Perhaps my opinion is biased because it's coming from a Partner perspective where repeatability is huge.

    There is currently one upgrade toolkit for the latest, BC19 that upgrades you from BC14 to BC19. If you're going to SaaS, it's a button push to replicate. To quantify the work you need to perform prior to your next upgrade, look at your modified objects in Object Designer, which still exists in BC14. The count of the modified base objects (the objects that aren't yours, i.e., MS's, ISV's) will be the count of new objects needed that you will put those customizations and subscribe to events to execute the code as it was before. Once you've done that, you are ready to upgrade.



    ------------------------------
    Jon Long
    Director of ArcherPoint-Upgrades
    ArcherPoint Inc.
    GA
    ------------------------------



  • 9.  RE: BC 14: When to plan upgrade to BC ?? (20?)

    SILVER CONTRIBUTOR
    Posted 8 hours ago
    Thanks, Jon

    This:

    "To quantify the work you need to perform prior to your next upgrade, look at your modified objects in Object Designer, which still exists in BC14. The count of the modified base objects (the objects that aren't yours, i.e., MS's, ISV's) will be the count of new objects needed that you will put those customizations and subscribe to events to execute the code as it was before. Once you've done that, you are ready to upgrade."

    Is a key part that I was missing:  How to define scope:  how to create the list.  How to know when we're done (without solely relying on exhaustive testing.)




    ------------------------------
    Kevin Brennan
    Director of IT at Mayco Colors
    Hilliard, OH
    ------------------------------



  • 10.  RE: BC 14: When to plan upgrade to BC ?? (20?)

    GOLD CONTRIBUTOR
    Posted 6 hours ago
    Hi @Jon Long !

    The upgrade toolkits do not migrate C/AL custom fields to AL fields in a new database.  They do migrate data from existing NAV tables to new NAV table structures when Microsoft has changed them, but you have to write your own code to move data from a C/AL custom field in a standard table to a new AL field in a database.

    If you know of any automated process Microsoft has created to do this I'd love to know!  We do a lot of on-prem upgrades to BC 14 for customers to prepare them for a cloud migration.  We're yet to find ​​a good way to do those C/AL to AL field data migrations.

    We personally use SQL because it is SUPER FAST.  It can take 10 seconds to move 1,000,000 rows if the two databases are located on the same SQL Server.  I think writing a Codeunit to do this can also work - but it gets tricky because you need to leave the fields in the database somewhere to be copied, while we can revert the new upgraded DB to Vanilla BC, add the new extensions, and copy the data from the previous version's SQL Database to the new BC with Extensions SQL database in minutes.  Much easier.

    I spent a little time in some old SQL code to build some scripts to make this easier by building the SQL Statements for me.  It's a bit of black magic, but we (the community) only need to do this for a while until customers migrate to AL.

    ------------------------------
    Robert Jolliffe B.A.Sc, MCSE, MCS - NAV Manufacturing Expert
    President
    Sabre Limited
    Cambridge
    robert@sabrelimited.com
    www.sabrelimited.com
    ------------------------------



If you've found this thread useful, dive deeper into User Group community content by role