Preparing Your FRx Data for Migration to Management Reporter

As more GP users get settled into Dynamics GP 2010 and/or begin refreshing their aging server environments, we’re beginning to see more migrations from FRx to Management Reporter. Management Reporter includes a Migration Wizard to automate this task, but because the two systems are structurally quite different on the back end, it is really important to clean and prepare your FRx reports before trying to get them over to Management Reporter.

You should carefully follow the entire Migration Guide document to familiarize yourself with the requirements and process, but in a nutshell the following steps are the ones you’ll need to prepare for:

1. Remove unused companies, specification sets, and building blocks (rows, catalogs, columns, trees) from FRx that are not in use or shouldn’t be migrated.
2. Delete the demo companies, any reports pointed at the demonstration specification set and then the demonstration spec set itself.
3. Delete any .f32 files in SysData that are not in use by existing specification sets.
4. Check your rows, columns, trees, and catalogs to identify if any of them are not associated with a report – this means you’ll have to check each one manually. If you want to keep them, you’ll need to create dummy reports to associate them to. If you do not want to keep them, you should delete them or they may cause the migration to fail. Note: in some environments with long lists of building blocks, this could be pretty big job. Give yourself enough time to get this done.
5. Remove any spaces at the beginning of row, column, tree or catalog names.
6. Compact the spec sets for each company.
7. Compact the system database.
8. For GP, you should try to make sure that all the names of your segments are consistent. For example: if GP Company A uses “Account” for segment 1, “Department” for segment 2, you should try to make that consistent across all your GP Companies, and not have them called “Acct” and “Dept” in GP Company B, or “Segment 1” and “Segment 2”.  The reason for this is consolidated reporting and consistency between report designs, and I think it’s the sort of thing you’ll regret later if you don’t clean up before migration, even though you’re not being forced to do it. These names are changed in your GP company Account Format setup.
9. Delete all .g32 files from the SysData directory, so that there are no old indices around with the old segment names.
10. Log into each remaining company in FRx, so that the index gets rebuilt fresh with your corrected account segment names.
11. Export any existing reports in Management Reporter (migration is going to wipe them, so we strongly advise doing your migration before you do anything else, but it is possible to export ahead of time and import them back in after the fact). This is also a good time to run a SQL backup of your MR tables.

Something not mentioned in the instructions but worth auditing if you have FRx installed on individual workstations: check to see if they are all using the same SysData folder. If they are not, you’re going to need to consolidate any desired reports from any local SysDatas (not a simple task; contact FMT Consultants Customer Care or see CustomerSource for more information) before you begin the clean-up and migration process.

For most environments, it won’t be a quick morning’s work to get prepared for your Management Reporter migration. So as you get your year-end close wrapped up and financials run for last year, it may be a good time to start making notes of what reports are actually in use  in your FRx environment, and to start making plans for determining what is going to stay and what is going to go.

Written by:
Lyn Warren, Senior II Consultant
FMT Consultants, LLC

Posted by: Jakob Bechgaard