In Part 1 of this blog post we talked about the preparation work to get your old FRx 6.7 reports migrated over to the newest & shiny Management Reporter 2012 (MR2012 in short). In Part 2 we’re going actually to walk thru the entire migration process and do some clean-up work after it’s completed with success (hopefully for you).
Step 1:To start the FRx Migration Wizard, simply hit the Start menu button in Windows and open the sub-folder Dynamics GP > Migration Wizard. You get prompted with a nice welcome screen which is going to guide you thru a total of 11 steps until completion
You have 3 choices, but given the fact that you want to be operational as soon as migration is completed, I don’t see the purpose of option 2 & 3 (unless someone has a very good reason NOT to validate their building blocks).
Step 2: Clicking on Next at the bottom brings you to next screen, at which you’re required to enter your SQL server name where your MR 2012 database resides. Tip: use the ‘Select @@SERVERNAME‘ in SSMS to quickly grab your SQL instance name, especially if it’s spelled out as a long name :-). Copy paste the name into the Server Name field and select your MR database from the drop down list (you can click the Test Connection button to validate first if you’re on the right place).
Step 3: Continue with Next when you have select your MR DB and use the […] browse button on the right side to select the location where your frxsys32.mdb file is located (the one copied over from your old server). The document says that it can either be a local folder or a UNC path on the network.. your choice 🙂
Step 4: Next you will have to confirm the migration process by checking the box “Proceed with the migration”. This is your last chance to take action on your existing MR 2012 database (i.e. take a full backup) and/or abort the process. So far no data has been damaged in your destination DB.
Once the process is started, you’ll get a progress bar of the definitions migration from the Access .mdb file to the SQL MR database. This usually goes pretty fast, it took less than a minute in my case.
Step 5: Once the definitions are imported, you have to map them with your MR GP companies.. Make sure that all the definitions you wanted to migrate over from FRx companies have a corresponding MR GP company. The migration wizard is not going to map them automatically for you (unless maybe they have the exact matching name, wich I haven’t tested, as MR was installed with the Legacy connector and thus the company name has ‘-Curr’ appended to it).
Click on each company line and select the corresponding MR GP company to map with the FRx company. Once this is done, you would end up with a mapped list of companies like this. If you installed the DataMart connector in MR 2012, the company names would like be identical between the two columns.
Step 6: Click on Next and you’ll be prompted to provide the credentials for GP login in each company in MR. In this case, the Legacy connector was used and I used the ‘sa’ user to connect to each companies and saved the credentials. Though technically you could use a different one for each company, I don’t see the point of it, as this is just for the time of the conversion.. but hey, Microsoft maybe thought that you might not be able to access all the GP companies within a single user account 🙂
Step 7: Assign the default company. This will also be the GP company that will be used for any report or definitions that uses @ANY as placeholder for company data. This can be changed anytime later in MR’s company settings, so no worries.
Step 8: Map your GP segments. This is one of the place where the preparation work document from Microsoft was providing a warning. In essence, if all your GP companies are using the same segment description, you can check the box “Use the same mapping for all companies” and it will apply the same rule for all companies. When you try this and your GP companies do not have the same segment naming convention, you’re getting an error message.
You won’t have a choice than to hit every line indivdually and map each segment one by one:
As you can see, here we have 2 companies with different segment names.. thus it is impossible to use the ‘all’ option from the main screen. For some reason the company owner (or their CFO) decided to use different descriptions. In my case 2 out of 5 companies had Segment #2 spelled differently, using ‘Cost Center‘ instead of ‘Department‘
Be aware that even in MR 2012 later, when you want to run consolidated reports with a reporting Tree, if the the segments names are not consistent across companies, you’re going to run into issues.
Once your segments are all mapped, you should see a check-mark next to each company name. With that done, you can hit ‘Next’ and go to step 9 to convert your actual data in MR.
Convert your imported FRx Data in MR 2012
Step 9: At this step you’re almost done and all that remains is convert your imported FRx data in MR 2012 to be usable with Report Designer. Check the box to confirm you want to move forward and click Next.
Step 10: One final step in the Migration process is to Validate your converted data. If the previous one is pretty fast, this step is the one that takes the most time and is quite CPU intensive to your SQL server (taxing about 25% of your CPU during the process). It will last several minutes, especially if you have a large numbers of definitions (Row, Columns, Trees and else). Check the box to proceed with the building block validation and click Next.
Step 11: Once the validation process of the building block(s) is completed, you’re greeted with a success screen. Check the box to view a summary log of the whole process (in HTML format).
The report will provide a detailed overview of several pages about the migration process. The meaning of the icon colors in the reports are explained briefly in the Migration Wizard documentation from Microsoft.
I was lucky to not have a single red flag, which means none of the existing Spec Sets are missing in the new Building Blocks in MR 2012.
The timestamp is misleading in the report, as it took about 15-20 minutes to go thru the validation in Step 10. Again, Your mileage may wary.
In Part 3, we’re going to look into the ones that need to be addressed after the migration process is completed (i.e. the yellow flags).
Stay tuned until next post, and wish you happy reading
@GP_Beat
The Dynamics GP Geek Blog 
Leave a Reply