[Stuart Gallion]

About this time last year we were still on GP2010 & FRx 6.7 and attempted, with support from our then partner, to migrate reports to MR. It failed. I got busy with other things and since FRx was still a solid product with GP2010, we let it slide.
In September we updated GP to 2016 and our new partner used the known workaround to get FRx to work. This was intended as temporary until the reports could be redone in Jet. I retired in October with the commitment to return in January to do the report rewrite in Jet in the new year. Mid-December I was informed that the decision was made to move to MR. I told management that the preferred solution was to have MR on a separate server and IT would have to spin one up. They went ahead and installed MR on the GP database server. The partner’s person then tried to migrate reports without success. I am not sure to what extent he cleaned up our three spec sets before the attempt or other clean up processes. I have spent the part of the last couple of weeks reading blogs, watching videos, rereading the MS migration documentation and researching on this site what needs to be done to make the report migration successful.
I have found these items to pay attention to:
Make sure no one is in FRx.
Delete rows/columns/trees that are not assigned to a report catalog.
Delete the G32 files.
Replace @ANY as the reporting company in a catalog with an actual company.
Compact the FRx databases.
Confirm the account number segment IDs are the same in all databases.
Confirm multicurrency is set up the same for all databases.

Does anyone have any additions to this list?
We need to move off of FRx as soon as possible as it has become fragile in the 2016 environment.
Thanks for any comments or additional things to consider.

——————————
Stuart Gallion
Project Accountant/GP System Administrator GP2016/FRx6.7
Stanford Hotels Corporation
San Francisco CA
——————————

[Matt Paulen]

Delete rows/columns/trees that are not assigned to a report catalog.

Stuart Gallion,  14 hours ago

For this, if the users actually use those building blocks, you can essentially create “dummy” catalogs and assign those building blocks to the dummy catalogs so that way they’ll migrate over.  Other than that, it looks like you’ve covered all the bases.

When you say failed, what was the issue?  Was the migration tool actually throwing errors?

——————————
Matt Paulen
GP Admin
Chadwell Supply
Tampa FL
——————————
——————————————-

[Annette Brown]

While it is true you need to delete the G32 files you will also need to Recreate them as well.  MS suggests  you delete them so you will have a rebuilt copy right before you migrate.  You can do this by selecting each company as the default company.  The G32 files get used during the migration and if you are missing them your reports will NOT convert correctly.

I would be interested to know what the migration looks like after.  Does it complete?  If so, are you missing accounts in the Link to financial dimension column?  You may have errors in all the building blocks, but sometimes they are things easily fixed when you open the definition.   (I.e blank row codes, formulas that reference invalid row codes, certain format codes set to ‘np’  in the printcontrol attribute, etc.)

There are a number of thinks that will NOT migrate and will have to be created in a different manner in MR vs the way FRx did it.  For example, security/Emailing, row linking, different row formats in a single tree, are you using account categories in the Link to GL column in FRx?

All these things will play a role in whether your reports convert the way you expect them to.

I have done many FRx to MR migrations and if you would like to discuss pit falls I have run into I would be happy to help.  

It can be done you just need to know where to look and what to fix.  I have had times where I had to send the spec set to MS due to corruption, but we were eventually able to get the reports to convert. 

——————————
Annette Brown – Sr GP Implementation Consultant
InterDyn BMI
Roseville MN
——————————
——————————————-

[Derek Krebs]

Another tip or two to share we have found helps:
* Apply the latest FRx 6.7 Service Pack 12 before migrating
* Yes to reiterate about make sure all FRx reports have a company assigned to them and NOT @ANY, delete the g32 GL indexes an rebuild, delete FW and FWC sample companies, get rid of old specs sets NOT using (I usually will make backup of Sysdata folder and clean these items up and have backup to revert to)
* Even though FRx rows/columns/tree/reports convert, many times I still would get error messages when generating n MgtRpt so I simply would create a completely new row/column/tree and copy the entire contents of the row/column/tree into the new one and it would work
* We (MSX Group) are the original FRx team members 100% focused the last 18+ years on FRx, Forecaster & Mgt Reporter so glad to also provide any other insight and experiences so call or email anytime and join us at a future GPUG event we host with them monthly

——————————
Derek Krebs
Sr Consultant
MSX Group
derek.krebs@msxgroup.com
——————————
——————————————-

[Diana Doane]

An oddity that we have run into is similar to Annette’s corrupt report issue. However there was no report visible in FRX which was corrupt.  It was one showing up with special characters in the report name and components’ names.  We found it with Microsoft’s help as they could access the spec set at a level we aren’t allowed.  They eliminated this oddity in the spec set and with all the other items you and the others have already indicated, the migration was successful. 

Any type of full copy/export of the spec set will include this oddity even though it does not show up in the report list. The way around it without engaging Microsoft is to export specific reports (not by ‘select all’) to a new spec set, then using the new spec set for the migration.  We had a separate sandbox environment to do the migration as not to impact production.  Then we could export/import final MR reports to production. 

Because of other requirements, we actually did multiple migration report groupings from FRX to MR over several months. We used this alternative method as the correction Microsoft did was to the sandbox environment (on that specific copy of the production spec set) rather than the original production spec set.

There was no way to know this oddity existed without Microsoft’s assistance. But if you do a sample of reports using the alternative spec set and it works, maybe you have some special characters hiding in your spec set too. 

——————————
Diana Doane
Ascend Learning, LLC
Leawood KS
——————————
——————————————-