Unified Operations & Dynamics AX Forum

Expand all | Collapse all

transitioning to D365

  • 1.  transitioning to D365

    Posted Aug 24, 2017 03:49 PM
    Has anyone already made the shift from 2012 R3 to D365?  Or planning to?   We are creating our long-term roadmap and I am looking for some honest impressions on the difficulties, where the biggest efforts occurred, quick wins, etc.

    ------------------------------
    Joseph Anderson
    AX ERP Technical Architect
    Allegion
    ------------------------------
    AXUG Summit - Post


  • 2.  RE: transitioning to D365

    TOP CONTRIBUTOR
    Posted Aug 25, 2017 04:05 AM
    there has been another thread about the same topic just a week ago, with the title "D365 Experience"

    I am trying to put a URL to the thread, but I am not sure it will work - so you should be able to find it by scrolling down a bit.
    Open Forum

    ------------------------------
    Zvika Rimalt
    Functional Consultant
    Vancouver BC Canada
    ------------------------------

    AXUG Summit - Post


  • 3.  RE: transitioning to D365

    Posted Aug 25, 2017 09:05 AM
    Edited by Neill Riordan Aug 25, 2017 09:08 AM
    Hello Joseph,

    We are currently undertaking this with a couple of clients and i will share some general steps below.

    • First off get a D365O LCS environment, your partner should have one and be working with you during this discovery.
    • Use the LCS upgrade tool on your AX2012 Model Store to assess the impacts of your current code base against the changes in approach for D365O namely extension instead of overlaying.
    • Through your partner get on the preview for the data upgrade tool so you can assess that element as well.

    You need to considered the data upgrade as a separate stream in the planning for this and the strategy your company is going to take around it.

    So the basic areas for any plan are;

    • Infrastructure analysis
    • Environment planning
    • Provisioning and configuration
    • Fix / Merge code conflicts
    • Test Base code

    • Solution Gap Analysis
    • Resolve functional design conflicts
    • Business Design Validation
    • Create new test scenarios

    • Data Upgrade (smoke test)
    • Data validation
    • Data upgrade (2nd test) + Validation
    • Data upgrade (3rd test) + Validation
    • Integration Testing
    • Cutover planning
    • User acceptance test
    • Training
    • Cutover


    Also remember the environments you will need to run in parallel during the upgrade and the cost associated with that.

    Hope this helps


    @Zvika Rimalt the thread you mention is about starting with D365 not migrating to it.  Due to the unique challenges around that i do not believe that existing discussion is the correct area for this question.

    ------------------------------
    Neill Riordan
    Dynamics 365 Solution Architect
    IBM UK
    ------------------------------

    AXUG Summit - Post


  • 4.  RE: transitioning to D365

    TOP CONTRIBUTOR
    Posted Aug 28, 2017 09:51 AM
    @Neill Riordan Thank you for your post.  I'd love to hear more about the "Data upgrade" step!  And hear about the profile of the clients you are implementing.  What parts of Dynamics are they using?

    ------------------------------
    GG Rowe, PMP
    Oregon Chapter Leader
    Chapter url: www.axug.com/portland
    IT Applications Manager
    Planar Systems, a Leyard company
    Beaverton, OR 97006
    USA
    ------------------------------

    AXUG Summit - Post


  • 5.  RE: transitioning to D365

    TOP CONTRIBUTOR
    Posted Aug 28, 2017 06:02 PM
    While the "other" discussion was about someone implementing AX, I still thinks some of the issues/concerns raised there (for example, regarding the maturity of the product or the appropriate project team) would be relevant for both upgrades and new implementations.

    ------------------------------
    Zvika Rimalt
    Functional Consultant
    Vancouver BC Canada
    ------------------------------

    AXUG Summit - Post


  • 6.  RE: transitioning to D365

    GOLD CONTRIBUTOR
    Posted Aug 25, 2017 12:22 PM
    ​I would also be very interested in the feedback and experiences.

    ------------------------------
    Kirk Blackburn
    Sr. Engineer - Software Development
    LDS Church
    Salt Lake City UT
    ------------------------------

    AXUG Summit - Post


  • 7.  RE: transitioning to D365

    GOLD CONTRIBUTOR
    Posted Aug 28, 2017 09:55 AM
    Joseph,

        We are also investigating the D365FO system and are working with our partner to get a test system.  We want our own system which requires an Azure license.  That has taken a few days, but we should get a system soon so that we can begin the review process...

      There is high interest in this new system with hopes that it will be an easy transition from AX 2009 and AX 2012 R3 systems (we have both).   We'll see about the "easy" transition.

    ------------------------------
    David Coombs
    Development Manager
    Harman Management Corporation
    Murray UT
    ------------------------------

    AXUG Summit - Post


  • 8.  RE: transitioning to D365

    Posted Aug 28, 2017 01:41 PM

    Just a few comments on the migration conversation.  First, is about the data conversion.  For many this is the hardest piece of any system switch over.  This is especially true if you have even a medium amount of AX custom fields and files.    One approach to this challenge is avoiding the costs and complexities for converting the bulk of your data.   This is worth exploring with your partner or other firms in the market. 

    Second is something some people are not focused on in their planning, reports.   You need to understand that the data source for your reporting changes with the Azure based D365 for Enterprise migration.   You cannot get at your core data any longer.   Microsoft has several options for this, with the most common of these solutions being Data Entities and O-Data access.   D365E comes with somewhere around 1,700 data entities to pull reports from. 

    You can think of these Data Entities as separate data from your core system, a data mart that traditionally have had names like data warehouses, data cubes, data clouds, and now - data entities.  Regardless of the name and structure of this secondary data; you will need to pull reports from a completely new and different set of  data.    For many companies already through the upgrade process this has meant reprogramming virtually all of their custom reporting.  

    There are various D365E paths, including ways around some of this redevelopment.  Regardless of whether you redevelop your reports or look for a solution that avoids parts of this, it is important to understand, define and budget this part of your migration to D365 for Enterprise.



    ------------------------------
    Peter Jennings
    Jet Reports
    Portland OR
    peterj@jetreports.com
    ------------------------------

    AXUG Summit - Post


  • 9.  RE: transitioning to D365

    Posted Aug 29, 2017 08:49 AM
    We are in the middle of an entire system implementation from AX2009 to D365FO.  Happy to share excruciating volume of details with anyone who wants it.

    ------------------------------
    Bob Smyk
    VP of IT
    InterDesign
    Solon OH
    ------------------------------

    AXUG Summit - Post


  • 10.  RE: transitioning to D365

    SILVER CONTRIBUTOR
    Posted Sep 01, 2017 10:36 PM
    To add to Peter's important comment on the entities....there's some good and bad with those.

    The good: conceptually they are a bit like a SQL view in that they pull data from multiple underlying tables, essentially de-normalizing the data. For example, if you look at the PurchaseOrderHeaders entity it includes both vendor number and vendor name, so you don't have to link to another table to get something like the name (there are many examples like this).

    The bad: Though Microsoft provides a lot of entities out of the box, they are not transactional entities. You get things like purchase orders, but there is not an entity for posted vendor invoices, or settlements, or receipts, etc. The same is true of customer invoices, inventory transactions, or general ledger transaction. If you want to have a real-time connection to that type of data you either need to create entities for that or get them from a partner or ISV.

    ------------------------------
    Jason Carter
    Solutions Enablement - Atlas
    Global Software Inc.
    Fargo ND
    ------------------------------

    AXUG Summit - Post


  • 11.  RE: transitioning to D365

    TOP CONTRIBUTOR
    Posted Sep 05, 2017 10:14 AM
    @Peter Jennings Thank you for your post.  You used the words "data conversion", can you say more?  I am very aware of doing a data conversion when switching systems.  However when upgrading an application, data is retained generally.  We are in the midst of a 2012 R1 to R3 upgrade, and all our data is intact even custom fields.  There were a few fields that took some special care, but it was truly only a few (we've found TWO).  Is implementing D365FOE from 2012 considered an implementation with a data conversion or an upgrade?  Or is your post stating that the data entities are newly added with D365FOE and the other tables also remain and hence data is still in tact?  Are you saying all reports and inquiries are new and only using the new data entities?  Thank you in advance for the additional information!!!

    ------------------------------
    GG Rowe, PMP
    Oregon Chapter Leader
    Chapter url: www.axug.com/portland
    IT Applications Manager
    Planar Systems, a Leyard company
    Beaverton, OR 97006
    USA
    ------------------------------

    AXUG Summit - Post


  • 12.  RE: transitioning to D365

    Posted Sep 05, 2017 12:58 PM
    GG, happy to clarify.   First for data migrate and conversion.   You are correct that there are varying levels of data conversion (and migration).   Whether or not customers move their data forward, or choose to report from both old and new AX databases in a combined Data Mart is a decision at each account.

    For instance moving within a major release, like 2012 R1 to R3 can be much easier than moving from 2009 to 2012 R3.   Within the AX community we are finding much also depends on the amount of customization.   We have clients with over 2,000 custom tables in AX.  For them the upgrade path is much more complex than our customers with 50-70 added data elements that are mostly in existing tables.   We have also seen customers leaving behind old custom work as new AX functionality replaces their customization of AX.  For these companies it often much easier to not convert and report old and new from a data mart.

    Secondly, with regards to D365 Enterprise.   The conversion or migration decision will be similar to the one you ave made from R1 to R3 and will be based on how much work is needed.   A good thing is that AX tables from 2012 to D365 are closely aligned at this time.

    However for reporting from D365, regardless of the migration or conversion decision you take, the reporting tables have changed.  You cannot currently access the D365 Azure tables themselves.  You need to use a secondary data set for reporting and analytics (BI).

    There are a few options directly from Microsoft that you can explore.  Jason in a post above mentions Data Entities as one.   Microsoft has released a large number of entities with D365 (near 1,700 i believe). There are some good things and bad things about these (see Jason's post for some examples).   Also notice that performance has also been a problem at some sites.   Jet and others have adopted a different Microsoft option, so there is more than one choice that you can explore.  Bottom line is that the different options will have different speeds, may or may not require rewriting your reports, and will almost certainly require adding some of your data to the reporting data mart of choice.





    ------------------------------
    Peter Jennings
    Jet Reports
    Portland OR
    peterj@jetreports.com
    ------------------------------

    AXUG Summit - Post


  • 13.  RE: transitioning to D365

    TOP CONTRIBUTOR
    Posted Sep 06, 2017 01:18 PM
    @Peter Jennings Thank you for the additional details.  Are you saying that all standard Dynamics reports now use the new tables/data entities or only the ones that access the BI cubes?  What if the local business data (aka on premise) option is chosen?  Does it affect inquiries as well?  Just trying to understand the enormity of the situation.

    ------------------------------
    GG Rowe, PMP
    Oregon Chapter Leader
    Chapter url: www.axug.com/portland
    IT Applications Manager
    Planar Systems, a Leyard company
    Beaverton, OR 97006
    USA
    ------------------------------

    AXUG Summit - Post


  • 14.  RE: transitioning to D365

    Posted Mar 06, 2019 02:40 AM
    These types of comments on reports and data conversion are very much in-line with the stressors I was expecting, and the experience I was hoping to learn from.

    As you can see from the original post date and the comment date, I started investigating this LONG before we were ready to move forward.  :-)  However, we have recently gotten to a position where we can look at making this happen.

    To shift to a specific topic:  code customizations.  Considering that the code changes for each "process" get spread across different methods and functions, how hard was it to pick and choose from previous customizations that had been done?  Did it feel more like an "all or nothing" process?

    Considering the industry-response, comments, and suggestions that have been included in the development since AX2012, I am hoping that we can dismiss some of the previous customizations and instead us the D365FO process as written, at least in some places.

    ------------------------------
    Joseph Anderson
    AX ERP Technical Architect
    Allegion
    ------------------------------

    AXUG Summit - Post


  • 15.  RE: transitioning to D365

    TOP CONTRIBUTOR
    Posted Mar 07, 2019 08:26 AM
    Edited by Shirley Adams Mar 07, 2019 08:28 AM
    Hi there, having done a few and proposed a few for our customers, the best first step is that LCS environment that was mentioned earlier and having the code analyzed.  While most partners and customers have known about the extension versus overlay requirement, not all customizations have been 'fixed' so that they can be upgraded to D365FO.  The best option is to first know what you are working with as far as code so that you can plan for any new coding or even getting rid of code if you have found it not used as extensively as anticipated.  Depending on how the customization was done (what model and layer), it may be easier to eliminate and re-add what you need.

    The first step in the actual process is the data upgrade, then the code application and then testing (to summarize - Microsoft has detailed steps that are listed out there in docs land).  Obviously, there are a lot of steps within each and there should be a lot of 'practice' runs to get to a smooth final upgrade (we usually have 5-6 based on our experience).  Also, Microsoft gives you something like 3 environments to start with so we usually recommend that you add at least a couple of additional ones (even if they are only temporary) so that you have places for training, CRP, UAT as well as the usual 'one developer per environment' requirement.

    Regarding reporting, if you are used to having direct access to the DB, something some of our clients have done if they can't live within the constraints of D365FO is to have a replicated database where they can have that direct access.  We have also added a few embedded Power BI reports, but I would always recommend starting with out of the box as much as possible and then revisit the reporting requirements - the reports have changed quite a lot in some cases.  For example, many use the GL detailed trial balance daily, but it has been removed and a focus on analytics and inquiry has emerged - most new implementations I have don't miss it because you do have other ways of getting to the data, but it's an example of how the reports have changed in potentially unexpected ways.

    Also remember that starting in April, the continuous upgrade model comes into play so keep that in mind when you are looking at timing.  It's not very far away!

    Shirley


    ------------------------------
    Shirley Adams
    Solution Architect
    AKA Enterprise Solutions
    New York NY
    ------------------------------

    AXUG Summit - Post


  • 16.  RE: transitioning to D365

    TOP CONTRIBUTOR
    Posted Mar 08, 2019 08:28 AM
    ​Is there a good source, either official or something someone has compiled as part of doing conversions they'd be willing to share, of what reports have gone away, what's new and what's changed from AX 2012?

    It still boggles me that Microsoft doesn't have provide a WYSIWYG report editor. We came from an ERP system where all the reports were built and maintained in Crystal Reports, so building new or modifying existing reports was something we could easily do in-house. It's more than a little terrifying that reporting options may be worse in D365.

    ------------------------------
    Steve Latta
    Accountant
    Ortec, Inc.
    Easley SC
    ------------------------------

    AXUG Summit - Post


  • 17.  RE: transitioning to D365

    Posted Mar 11, 2019 01:13 AM
    What's new - a lot
    What has changed - a lot, and not a lot

    https://docs.microsoft.com/en-us/dynamics365/unified-operations/fin-and-ops/get-started/whats-new-changed

    It all depends on the area you are discussing.  Firstly, the user interface is a web page.  Technically things have changed quite a bit.  Functionally many things are the same, with the addition of Electronic Reporting and Data Management.  Microsoft has purchased Dynaway EAM and I expect it to be incorporated this year and it is a great addition to the F&O offering.

    For a WYSIWYG report editor, check out Doccentric which has a good free version and a great paid version.  More or less you get to develop reports using an editor similar to MS Word.  https://ax.docentric.com/free-vs-full-edition/

    ------------------------------
    Dag Calafell, III
    Technical Solution Architect
    MCA Connect
    Houston, TX

    http://calafell.me/
    @dodiggitydag
    ------------------------------

    AXUG Summit - Post


  • 18.  RE: transitioning to D365

    TOP CONTRIBUTOR
    Posted Mar 12, 2019 04:04 PM
    As many others have posted input and this thread could go on forever, I will also mention we have worked with many clients on upgrades from AX2009 and AX2012 (R2 and R3) to D365FO, as well as one client who was still on Ax4.0. Please feel free to reach out with any questions or if you are looking for feedback.

    ------------------------------
    Andrew Lencsak
    Solution Architect
    DXC Technology
    Atlanta GA
    ------------------------------

    AXUG Summit - Post


  • 19.  RE: transitioning to D365

    Posted Mar 13, 2019 02:24 PM
    The original post was April 2017. Since then, there's some pretty significant payment compliance changes so moving from AX to D365 likely would not uncover or fix this in a general transition assessment. Additional actions are needed and I've outlined what to look for:

    • GDPR- The European Data Protection Regulation is applicable as of May 25th, 2018; both the payment gateway and merchant have a compliance piece, applicable to all payment types. Verify the payment gateway has met the standards.
    • Storing and using stored credit cards- (Stored Credential Framework & Mandate) New rules in effect since October 2017; enforcement was delayed to April 2018 due to lack of readiness. The biggest gap in compliance in 2019 is probably B2B (verify gateway supports Unschedule Credential On File or UCOF) and rentals (verify the payment gateway supports Estimate, Incremental, and Final Authorization, plus stored card general rules.)
    • Identify whether a stored card on file is being used for a merchant initiated or customer initiated transaction.
    • MasterCard Processing Integrity Fee Penalty increased to .25%- Final authorization : 

      Applies to final authorizations that are not fully reversed or cleared within 7 calendar days of the authorization date or when the final authorization amount does not equal the clearing amount or when the final authorization currency code does not match the clearing currency code. For example, merchant authorizes $10000, but only captures $6000. If the $4000 is not reversed, pay the penalty.


    ​​​​

    ------------------------------
    Christine Speedy
    Global Sales
    CenPOS
    Miami FL
    ------------------------------

    AXUG Summit - Post


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