My take on the Data migration

Data is the key to a successful implementation which can make the implementation as painless as possible for Customer to transition from their legacy systems to the new Dynamics AX application. The data gives them an unparalleled familiarity to use and embrace the new application even though they are in the midst of transition. The end users have nothing more joy in viewing the results in Reports or Inquiries with their data when they achieve their objective using AX Business Process. So Data Migration phase is an important area which needs to be planned and analyzed with importance right from the requirements stages with just the level of priority as the business processes.

Data migration requirements planning allows the Consultant to estimate and analyze the data maintained or archived in the legacy system. The data analysis estimation involves both size and quality of data that can be migrated to AX. Most importantly estimate the efforts required if there are complications and can be flagged early to the Customer. There are possibilities to pick up some functionality that may be required based on the data available in legacy but which has not been discussed or identified during the requirements workshops. Overall the effective Data migration strategy is crucial for getting the application ready for Training and UAT milestones. This in turn is the precursor signoffs for the Production cutover finalization and rollouts.

The workshops for data migration will involve all the key users spanning across modules but related business processes to ensure smooth decision making with consensus and settle any clarifications that may arise immediately. The workshops also allows the Consultant to identify who owns the data. For the session to be effective, key users may share their module data by showcasing reports, screenshots, etc ahead so Consultant can do a simple analysis and prepare any questions ahead of the data migration workshops. Based on the business requirement sessions conducted earlier, the Consultant should be able to identify and narrow down on the entities to be migrated and classify them as Configuration setup (Ledger accounts, GST, Payment terms, Module Parameters, etc), Master data (Customers, Vendors, Products, etc), Orders (Sales quotations, SO, PO etc) and Opening balances (FA, Ledger, Inventory, Cust/Vend, etc). Few more workshop sessions can be conducted in this format to ensure buy in from all the stakeholders and finalize the templates along with the conversion values required for AX.

Customers IT team or the key users will normally prepare a first round extraction as per the template provided for the entity along with the conversion values provided by the Consultant. There may be more extractions based on the feedback from consultant and the data migration templates will locked. Around the same time more planning will be done for firming up the dates for the real extraction for UAT based on the project schedule, considering if there are any other developments that is required for the data entity import. Generally an accepted 2 rounds of import is done to ensure the efficacy of the data and estimate timelines for the actual migration in production.

To summarize the data migration strategy, you would need to do;

Objectives

• Identify What to migrate, Source of data and How to migrate
• Classify and communicate clearly so there is no misunderstandings
• Ensure what’s in scope and out of scope

Stakeholders

• Key users who own their respective module data
• IT team who deliver the data as per template agreed
• Consultant who plans from strategy to execution
• Anyone else who is part of Sign off

Templates or Scripts

• Proper definition of what qualifies as a clean data expected for AX
• Columns with Legacy data conversion requirements to AX data
• Sign off both Migration strategy and Templates/Scripts

Simulate

• Ensure at least two rounds of testing including with Customizations, if any
• Sign off to ensure data imported is as per expected format

The key ingredient for a successful and a smooth migration is adequate planning, proper understanding, and do it early! Now that we have got the strategy part over (my understanding J), let’s do some import to AX 7 using Data Entities!!!

Disclaimer: Views expressed are entirely my own! please follow rigorous processes and project methodology for Actual Customer Implementations.

Dynamics AX 7 RTW and Activation of Cloud POS

Dynamics community is abuzz now after the Virtual launch of the Dynamics AX RTW which was promoted to GA. You should be able to deploy your demo, production or dev/test environments from LCS. A lot has been written over the importance of LCS and cloud deployments, so am not going to waste time on them but going to dig right in with the deployment of Cloud POS from RTW version. There are some pre-requisites that need to be done to ensure the Cloud POS is up and running in no time.

• Dynamics AX Batch management service

Dynamics AX Batch management service is responsible for executing all the batch jobs in AX. Consider it as a legacy [limited] AOS service which is stripped of all the rich client UX elements with just the business logic execution component. It is set as Automatic by default but sometimes I've found it doesn't start properly. Push it to Delayed Automatic to ensure it starts after the Server has completely booted up. You can find it under the Services, 

• Employee AAD entity

AX user is automatically associated with the AAD identity(office 365 poral user id aka @onmicrosoft.com account) but you would need to do a double check for the Workers to ensure the correct AAD entity is associated properly. Find out the Employee name from the User id and then go to the Employee record, link it from the Retail ribbon bar > External identity section > Associate existing identity,

• Employee address book

Add a proper addressbook for the Employee, this is crucial to ensure the Cloud POS activation wizard will allow you to choose the store. I choose everything just in case;

• Employee Job

Employee Julia's job scope in Marketing Executive was not part of retail, so had to choose the POS permission group as Manager to let her activate and use the Retail Cloud POS,

• Screen layout

The RTW that I deployed did not have a Cloud POS screen layout profile for Houston store, so had to link one to the Store or Employee. So make sure you save the hassle by checking the profile to the Store,

• Distribution schedule - Staff

Push it to the Channels, don't wonder if you don't find a separate Channel DB on the RTW demo. It is a topic for a separate post by itself. Run the Distribution Schedule for Staff. 

Activation of Cloud POS

Cloud POS activation is a breeze now in RTW, with the introduction of a wizard it makes it as painless as possible for the Customers and Partners. Go to the LCS, you should be able to see the Cloud POS url or if you are in server you can access the Cloud POS from IIS manager to view the URL. The first step would be to provide the Retail Server URL to the activation wizard. You can get it from the channel profile settings too.

Click Next and it will bring out all the stores that is accessible for the Employee,

Choose the Store and click Next, in my case I used Houston,

The wizard will pick up all the Registers with their Device activation status, go ahead and pick one. I chose Houston-14

Let the wizard cook up some magic by completing the 10 step which includes creating device token, gathering device configurations, hardware profiles, number sequences, etc

Viola, you get the message as Device successfully activated and Cloud POS ready to log in. Use Julia's employee id as 000020 and password as 123

Play with your cloud POS!