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------------------------------
Original Message:
Sent: 09-05-2017 10:13
From: GG Rowe, PMP
Subject: transitioning to D365
@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
Original Message:
Sent: 09-01-2017 22:35
From: Jason Carter
Subject: transitioning to D365
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
Original Message:
Sent: 08-28-2017 13:40
From: Peter Jennings
Subject: transitioning to D365
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
Original Message:
Sent: 08-28-2017 09:55
From: David Coombs
Subject: transitioning to D365
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
Original Message:
Sent: 08-25-2017 12:21
From: Kirk Blackburn
Subject: transitioning to D365
​I would also be very interested in the feedback and experiences.
------------------------------
Kirk Blackburn
Sr. Engineer - Software Development
LDS Church
Salt Lake City UT
Original Message:
Sent: 08-24-2017 15:49
From: Joseph Anderson
Subject: transitioning to D365
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
------------------------------