Well, We’re Movin’ on Up. M2M Migration

The Jeffersons

Movin’ on Up.

In a previous post, I indicated that I would post my migration procedures. Made2Manage offers instructions to set up a test server and basic migration directions, but they don’t offer recommendations of what exactly should be tested during migrations. This is unfortunate, because only they know where the issues are likely to be.

Should I pay for migration assistance?

I’ve performed migrations both ways. The only time I contracted with M2M for migration was my jump from Version 3.6 to 5.51. Migrating from Visual FoxPro to SQL is not something to be taken lightly. If you are in that situation, I would recommend getting assistance with it.

If you are migrating from any 5.XX version, it all comes down to the extent your M2M is customized, and budgetary concerns. If you administer a completely standard Made2Manage instance, then theoretically you could skip the testing process I am about to recommend. In that case having an experienced Made2Manage or third party consultant on-site during migration is beneficial. If something goes wrong during migration, then you have an expert on site with immediate access to all of Made2Manage’s resources. At the Vegas conference, Made2Manage distributed a document advertising an Upgrade and Upsize Service to version 6.0. To give you an idea of cost, they advertised a cost of $6200 for those already on any 5.X version and $11,700 for those on a prior version. These prices do not include weekends, holidays, or travel expenses. Also, the services don’t cover customization migration or the migration of customized reports.

If you have customizations, then the migration consultants will be of considerably less help if something goes awry. In my experience, most of them are not trained to customize Made2Manage. If you have customizations, ideally you should have the programmer participate in the migration process or someone who can substitute for them.

Therefore, if you have customizations and a reasonably competent administrator, you should do the migration and testing yourself. Migration is a great opportunity to learn more about M2M and how your business uses it. The process I use encourages the administrator to communicate with his users about any problems they have with M2M.

Migration Procedure

  1. Go to M2MExpert and get a copy of the CUSTRP Report This report will determine which reports have been customized and in what way, as well as any new custom reports you may have. After you run this report, use Visual FoxPro to check your UTRPSESS table as the sessionid field records the last time each M2M report was run. This includes any custom reports. Use this information to discuss with your employees which customized items they no longer need. I’m a big proponent of deleting things you don’t use anymore, but make sure you keep a permanent back up because users often change their minds. After this process you know which custom report items you need to test after migration.
  2. Assess your customized code. Are you using FastForms, Interactive Form Editor (IFE), VBA, or 3rd party reporting programs like Crystal Reports? If so, are you sure what that customized code actually does? Often documentation is an afterthought and if the customizations are old enough, the customized functions are mistaken for normal M2M function. Take time to investigate your customizations so there are no nasty surprises during testing. Also, you must thoroughly test your custom functionality as it is much more likely to break than standard M2M code.
  3. Set up a test server with an exact copy of your live data and all of associated folders. Keep the database back up files so you have a constant restore point as you will be migrating the data more than once.
  4. Before you migrate, run and print the following reports with the default settings: Sales Order Backlog (RPBKLG), Inventory Evaluation (RPIVAL), Work in Process (RPWIP), General Ledger Trial Balance (RPGLTB), AR Aging/Status (RPARAG), and the AP Aging/Status (RPAPAG). If any of the reports generates an excessive number of pages, print the last 5 pages of the report.
  5. Perform the migration according to the instructions. Assuming you were successful, apply any applicable service packs. You may also need to upgrade any of your optional modules as well.
  6. Make a SQL back up of your migrated data, taking care not to over-write your pre-migrated back up. You may need to restore to that point when doing user testing.
  7. Re-run the reports listed above and make sure that they match the pre-migrated data. If so, you have proven data integrity and you can move on to the next step. If not, you’ll need to investigate the cause of the differences.
  8. Open M2M and do some preliminary checking for correct functionality. Create a sales order, shipper, and invoice to check functionality. Make sure to check areas in which you have customizations.
  9. If you have customizations which actually write to the database, you need two test machines or you can use a test company (with identical data) on your live server for comparison. If your custom code is writing to your database, you not only have to do the first data integrity test I mentioned above, but you also have to perform the exact same actions on both instances, and then integrity test them again. You add, modify, and delete the same records to both to ensure that the end results are the same. Only through this extensive testing can you be sure that your customizations will successfully migrate.
  10. Now you’re ready for user testing. Recruit a person from each department with instructions to perform at least one example of every procedure they perform in Made2Manage. Typically, I create a spreadsheet with a separate page for each department to document each test, the result, and a description of the fix required if there was a problem. I sit with each person while they’re testing and fill out their spreadsheet for them so they can focus on testing.
  11. Obviously the next step is to address any problems with the migration. This includes data integrity, customization behavior, as well as training issues for your users. Often your users will require some training due to additional functionality provided by the migration, and now is the time to address that.
  12. After you’ve addressed any issues, the next step is to perform the migration again. This time document every step, creating a checklist to follow during the real migration. You do not want to find yourself working through a problem at 3am Saturday morning. This is not the time for improvisation.

Now, you may be asking yourself, “Does David really follow all these steps that thoroughly?” The answer, dear reader, is yes I do. In fact, in preparation for the last migration I performed, which was from 5.51 to 5.6, I migrated the data 5 times. It was necessary because we were migrating from IFE customizations to VBA/FastForms customizations and there were many issues to deal with.

So, let’s assume this whole process was successful and your company is successfully operating on the new version of Made2Manage. You’re finished, right? Not as far as I’m concerned, you still have to address what I think of as the “Hook” effect.


Imagining things makes them so.

If you haven’t seen “Hook,” or don’t remember the scene, Peter (Robin Williams) is starving having trained and exercised all day. The kids bring him dinner but all the bowls are empty. Essentially, if they use their imagination the food appears and everything is wonderful. What does this have to do with Made2Manage? Well, I can’t tell you how many times over the years that I’ve had users complain post migration that the new version of M2M either does or doesn’t do something that the previous version did. They will swear up and down that they’re right. In the real world however, believing something does not make it so.

The only way to settle these claims is to have a test machine available which is still running the previous version of M2M. I typically keep this machine available for a few months after a migration for this purpose.

I’m sure many of you have been involved in M2M migrations, how did you do it?

7 comments to Well, We’re Movin’ on Up. M2M Migration

  • Scott

    I finished upgrading a little over a year a go from 3.21 to 5.6 SP1. I used the M2M suggested approach which involved sending them a test server and our old data. They then upgraded the test server and migrated our data. Using the test server I then spent about a year preparing for the upgrade. When I was ready they then sent a consultant to help me with the migration.

    The prep time took so long due to the amount of customizations required. Prior to my employment my company had always paid M2M to create customizations that primarily dealt with commissions. We pay commissions in about nine categories, often basing one commission off of another. The complexity of this made any kind of commission modifications extremely expensive and time consuming.

    Adding to the problem, no one at my company truly understood how commissions were suppose to be, or actually were calculated. Because of this M2M was not clearly informed on how it should work and therefore they often had to ask for clarifications and make assumptions. Adding to this, their customizations often did not work and had to be redone. The time and expense involved in changing the customizations caused us to put up with its limitations and greatly increased manual calculations leading to errors and lack of proper record keeping.

    Due to all of these issues it was decided that I would recreate all customizations using VBA and FastForms. Having never worked with FastForms or M2M’s version of VBA and being relatively new to M2M in general this took a great deal of time. Adding to this, FastForms had a major bug on the ARINV screen that M2M had to fix before we could upgrade.

    While doing the customizations in house took considerably longer then if M2M had done them, I am glad we took that route. Our commission process is now well documented and understood. When modifications need to be made to it I can make them much faster, cheaper, and more accurately then M2M could.

    Another cause for the delay was switching from R&R Report Writer to Crystal. I had to rewrite dozens of reports but overall I am happy with the result and the decision to change over. Because I rewrote all the reports in a short time, I was able to learn a great deal about how M2M worked in the background and was able to give all of the reports a standardized, professional format that they were missing in the past. Crystal also did not have the license issues that R& R did and allowed for user prompts much easier.

    The actual migration went fairly smoothly. The biggest issue that I ran into was upgrading all the workstations. I was informed that I could upgrade from 3.21 to 5.6. After doing so on all my workstations, I found out that simply upgrading caused some kind of VBA issue and that to correct it, I had to completely uninstall and reinstall M2M on all the workstations.

    I am very glad my company did the upgrade and that we used M2M help in performing it. All future upgrades I plan to do by myself since they will be from SQL to SQL.

  • Andrew

    I know I don’t have the experience that some of you guys do, but don’t you think all this testing is rather excessive? How many hours do you sepdn doing all this?

  • Well, it does take quite a bit of time for the Admin to do this Andrew, but consider the consequences of a bad migration. If you’re fortunate, you’ll realize the migration went bad as you are doing it and will abort the process.

    If not, and you put that company into production, your company could well be down for days and it may be necessary to contract with a professional to fix your data. This sounds like a recipe for unemployment to me. So, yes I may be exceedingly careful, but I sleep well at night.

  • Matt Jarvis

    In the Migration Procedures, Step 9, it sounds like it is assumed that your custimizations (forms) are the same across all companies. Remember that FastForms allows you to do company specific modifications, so how form X works for company 01 may not be the same for company 02.

  • Matt, I didn’t intend to give that impression, but thanks for the “heads up.”

    The interesting thing is that while FF allows you to do company specific customizations, all of your M2M databases are customized identically regardless, and it appears the only difference is in the VFP tables. I mentioned it in this article.

  • […] advice I’m about to give may sound a lot like my post on M2M Migration. If you don’t have a Visual FoxPro and SQL Server expert on site, and your company’s […]

  • Kim

    I wish I would have seen this article before I made my last upgrade. It was a mess.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>