Planning for data import, export & migration with AX 2012

With every Microsoft Dynamics AX 2012 implementation, a very import topic, that involves a lot of planning, and technical work, is around the process of migrating data. This includes a lot of exporting, importing, transformation and so on.

Like all task relating to an AX 2012 implementation, these should be governed and defined based on functional business requirements and discovery. That is what should drive the choice being made, for how specific entities are imported, migrated or even entered into AX 2012.

To that end, and with this in mind, lets look at some new content on MSDN, specifically on this topic.: Plan data import, export, and migration [AX 2012]

From the article:
"This topic describes the tools and strategies to use when planning to import or export Microsoft Dynamics AX data. It describes how to plan to migrate data from one enterprise resource planning (ERP) system to another. Finally, it describes performance and security considerations for data import and export."

This is actually a very well thought out, and put together article, and I highly recommend it be used as a source when in reference to such task, when working in this area of a AX 2012 project.

With that said, there are some understandings that we need to circle back around to, to allow business requirements and customer needs to drive what is completed, in regard to such task.

One broad stroke statement that is not always applicable from this article is the following.:
"We[MSFT] recommend that you do not migrate transactional data or historical data to Microsoft Dynamics AX. Instead, close all open transactions before migrating, if it is possible. Maintain the database that contained your previous transactional data for reporting and compliance purposes."

This, as many of you senior consultants understand full well, is a great statement, and if it's possible really helps reduce the cost of data migration efforts in a project. However, it's hardly always true, and would say that the above statement is typically not what takes place for open transactions on any AX project.

Instead, what we try to push for, in the above statements place, is based on volume for open transactions. With that, if the volume is not to large, then a two birds, with one stone event can occur.

Instead of having to write data migration logic, this can be used as a training opportunity and get the open transactions into the new AX 2012 instance. There still can be an argument that even if there is a perceived large amount of volume to such data, that it's cheaper and better ROI to have more hands entering in the open transactions than writing migration code.

Why would that be? The reason is, any time spent, and therefore budget dollars burned, on the process of data migration is all throw away once the go live takes place. This means it looses it's value, as soon as the new AX 2012 instance is up and running.

So the trick, for adding the most value to such projects, is to perform the least complex, and spend the least amount of time possible in this area. It's not the the point that it should be overlooked, I'm not stating that at all. What I am saying, is that whatever the solution for migration is, it should be defined based on the understanding that the work will be throw away as soon as the go live takes place.

Now, on larger implementations, most likely all of the options that you see listed in the above document will be used. There is no single way to achieve importing all entities, instead, each should be defined, based on volume, complexity, and level of transformation that needs to take place. The process should be as fast as possible, and least amount of time and therefore budget dollars. Simple is king of value, and rules over it in this area with an iron fist.

Another point I would like to bring up, that is not listed in the above article, is around RapidStart Services and it's impact on data migration, specifically around reference and setup data. With the release of RapidStart Services for AX 2012, this too should be considered, weighted and then valued for helping create data entities, and for importing other entities via.

I will leave with this, always look for the most simplest approach when migrating data. Only be as complex as the requirements and customer constraints force you to be. Sometimes the most elegant solution, is the worst in value, when it comes to the task related to data import, export & migration.

Finally, I will reference back to this post in future articles, as I review some of the options in detail. Talk about the real world impact, by example, and give some food for thought to help better understand the value of the choices made on real projects.

That's all for now, till next time!



"Visit the Dynamics AX Community Page today!"

RapidStart Services for Microsoft Dynamics AX 2012 is live!

RapidStart Services for Microsoft Dynamics AX 2012 is live! PartnerSource or CustomerSource access is required to get access to it.

The link on PartnerSouce can be found here.: Microsoft Dynamics ERP - RapidStart Services for Microsoft Dynamics AX

From the post:
"Microsoft Dynamics ERP RapidStart Services allows organizations to easily configure business processes and modules thru an intuitive interview style questionnaire. Organizations can answer questions specific to their business processes and based on the responses to questions the necessary records for those business processes are created. Time of configure Microsoft Dynamics ERP can be greatly reduced and allow organizations to spend time on value add services."

The link contains a download, services guide as well as configuring projects guide. I've looked at this now, and it really has the possibility of truly helping out projects of all sizes.

The first focus for this offering, for out-of-the-box questions and templates is around U.S. & Canada Financials, with a lot more planned offerings to come.

Based on the guide, this is a Partner focused effort, in which a Partner would on-board it's customers, and in turn then can enable the RapidStart Services for that given project. From there, an On-Premise connector is what enables the connection to this Azure based software, and let me say again, this is pretty dang cool. I would say bye-bye rapid configuration tool, hello to the next generation!

What I think is very cool about this offering, is the fact that Partners, and even implementation projects, can tailor the use of this tool, for their needs. Like all software, the community has to dig in, and start to see real value out of this. However I see this becoming a staple in all AX 2012 projects.

If your a partner, or even in the midst of a AX 2012 deployment already, this needs to be looked at now to see how it can help your implementation. If your an ISV, you need to be looking at this, so that you can create templates, that tailor the RapidStart Services to include Rapid Configuration ability to your IP for AX 2012.

The official product launch, or RTM, is not for some weeks, so you can look at this as being the GA release of RapidStart Services. I've heard several people from Microsoft comment on this is just the first release, in which many more or planned to have out-of-the-box questions and templates.

So if you have access, go check this out now!

That's all for this post, till next time!

Update: There is now further documentation about RapidStart Services over on TechNet: Help for Microsoft Dynamics ERP RapidStart Services users [AX 2012]



"Visit the Dynamics AX Community Page today!"