Interesting post on preparing for a 2013 upgrade when you are also migrating credit cards. I'm not quite sure that there will ever be an instance when you can know that credit cards were never used - so seems as if you'd have to follow all these steps. What seems to be new here (to me) is the suggestion/requirement to load the Sage Exchange SDK separately from productivity applications.
My personal observation - this is not right. An install routine should be just that - it should install what's required. Having separate manually loaded required components is just sloppy work in my opinion.
The information in this article has shown to be successful in resolving one or more actual customer cases through direct contact with Sage Customer Support. It may not have undergone a complete and thorough review. It may not be entirely accurate for every situation and may also have typographical errors.
Process
Note: All companies run through the CI_SageExhangeProcessing portion of the the conversion process. It can be very long and even generate errors. Below is detail on how, why and how to prepare for these types of datasets that have any of the issues stated in the description
Definition of a Non Sage Payments Solution (SPS) user vs. a Sage Payment Solutions User
There are what is referred to as a Non SPS (Sage Payment Solutions) Vault users and actual Sage Payment Solution Vault users. A Non SPS user does not own the Credit Card Processing module. However, they do store and process with credit cards. A SPS Vault user does own the Credit Card Processing module and they are registered and using the SPS Vault to process their credit card transactions. Based on the data being uploaded the Cloud will know which Vault to drop the data in. When Sage ERP 100 2013 reviews the dataset during conversion it looks at the Encryption key that exists in SY_Company . From 4.30.0.18 release the Laws changed in regards to having credit card stored on in house systems. It was required that they be secured which brought life to Sage SPS Cloud. The conversion process called CI_SageExchange will then go through the following to either load Credit Card data to the properly Vault or to verify the data has really been deleted in prior company. It is imperative that data sets with Credit Card info do the complete clean-up process which consists of the following steps.
CLEAN UP AND DATA PREP WORK:
Rebuild Key Files all modules in source installation
Rebuild Sort Files all modules in source installation
Analyze and Relink all modules in source installation
Complete Backup of Source MAS90 directory and all of its contents before Parallel Migration run
Click on the Autorun.exe for Sage ERP 100 2013
Click on the Initial version of Sage ERP that will be installed
Click on Productivity Applications link
Install Module SDK for Sage Exchange
Install Sage ERP 100 2013
Install Sage Product Updates
Backup the brand new 2013 MAS90 directory and all of its contents.
With every thing cleaned and backups made proceed with Pre-Migration and Parallel Migration for source to new system
..
NOTE:
Even if the companies coming over do not use credit cards the clean-up process should always be completed for all modules activated for a company code that will be migrated over for conversions. Doing this process can resolve errors before they even occur. If something happens and the process needs to be reversed from scratch the backups created during the Clean Up and Data Prep Work section will be needed to go backwards and try again. When Sage Exchange is not installed before migration of a fairly large company it can result in Error 80 or Error 88's occurring. Once these types of errors occur the conversion is locked up and cannot be restarted from where it left off. It will be required to remigrate the dataset from scratch and start the conversion from the beginning.
https://partners.sagenorthamerica.com/irj/go/km/docs/sageKM/Sage%20MAS%2090%20and%20200/Gated%20Customers/Warr_Svc_Support%20Plan/110-1005232.xml