6 Replies Latest reply on Nov 4, 2010 1:02 PM by Dan Contreras

    How long is the migration of charges taking when upgrading to 9R1?

    Jason Dombrowski Expert

      We have been a T&E customer since 2004, utilizing travel cards charges. In addition, we also utilize p-cards from a purchasing perspective. Both the travel card charges and pcard charges are loaded into Ariba for reconciliation purposes. It's my understanding that the migration of charges from the 8.x platform to the 9R1 platform has been challenging for most customers, but Ariba has made some fixes to their migration tasks.

       

      I'm looking to indentify what some of those challenges are and what fixes Ariba has put in. I've heard that the amount of time it takes to migrate the charges was one of the issues and I am trying to get my arms around how long it is taking for customers who have already been through it. My concern is that we have close to 2 million historical charges in the system. If the data migration takes as long as I have heard (10,000 charges per hour), it is going to take 8 days to migrate those charges. We don't have to migrate all of them, but we don't completely understand the mechanics to not migrate them all. For example, say we wanted to only migrate charges with a Transaction Date within the past three years.

       

      Thanks in advance to anyone who can provide some details!

       

      Thanks

      Jason

        • Re: How long is the migration of charges taking when upgrading to 9R1?
          Jason Dombrowski Expert

          Looks like I found some defect info on this on connect, but it doesn't quite answer the question about how long it takes.

           

           

          1-AL8I7H: Performance Issue with Level2Charges Migration

          ChargeMigrator ran too long and then terminated after two days with an Out of Memory error.

          Solution

          Migrating L2Charges may take days to complete for a large amount of data. Customers can now control the amount of data to migrate through the migration harness, and then migrate the remaining charges at a later time.

          1. Change the parameter "ChargeMigrationPeriodInMonth" in MigrateL2Charge in ScheduledTasks.table to the number of previous months of charges you want to migrate when running the migration harness. For example, a value of 12 migrates the charges for the last 12 months. By default, this parameter is set to "0" - migrate all charges.

          2. Post migration, run the MigrateL2Charges Scheduled task once the system comes up on a dedicated node. Set parameter "ChargeMigrationPeriodInMonth" to either 0 to migrate all remaining charges, or run the scheduled task multiple time, each time with the parameter set to a longer timeframe until all charges are migrated. Already migrated charges are not migrated again.

          Note:

          Ensure you migrate all charged to 9r1. ERs which contain non-migrated charges will not be accessible.

            • Re: How long is the migration of charges taking when upgrading to 9R1?
              jaideep mulchandani Novice

              Hi Jason,

              You are absolutely right. The charge migration is the most time consuming & database intensive job. I'm working on a client where we have some 450K+ PCard records. In DEV, we have to do 5 rounds of executing MigrateMetaData task (from the Migration Harness) to make it work. The sixth execution completed successfully and it took 30hrs & 25min to finish.

               

              With each failure, Ariba support will tell us to try something new. Fortunately, we compiled the list of fixes/database tunning steps and used the same when we did the MigrationHarness with the same number of PCard transaction in TEST. The same execution took 18hrs 32min.

               

              We saw this significant improvement as we changed the database server (better one) & Windows OS from 32bit to 64bit for the app server.

               

              Also, reg the performance fix that you mentioned in your posting, we tried that too. But, its of no use. Even if you specify 12 months or 1 month, the harness will still move all the pcard transaction to the new pcard object.

               

              When a substep of MigrateMetaData - PCardAccumulatorMigrator is running, you can run the following query to see how many records are left to update by the substep

               

              SELECT Count(*) AS Expr1

              FROM ariba_PurchaseOrderTab

              WHERE (((ariba_PurchaseOrderTab.po_OrderMethodCategory)='PCard') AND ((ariba_PurchaseOrderTab.po_AmountInvoiced) Is Null));

              • Re: How long is the migration of charges taking when upgrading to 9R1?
                Akshay Pole Journeyman

                Hi Jason,

                 

                We faced few issues which migrating Pcard Charges and have figured another approach which has potentially reduced the time from 70 hrs to 24 hours.

                 

                1) Remove the Level2Charge field from stringToEncryptedString.csv as encryption and decription takes lot of time. Just take backup of all the pcard number on to a additional field for reference.

                2) We migrated the Pcard Charge Accumulators in the 822 instance itself so that we do not have to run through the migration of all the accumulators during actual migration. We changed the ariba class file to get the delta charges while running actual migration.

                 

                These above mentioned changes made our life easier and we were able to successfully migrate the system. Please make sure to test the changes in your development enviornment and run test scenarions based on Pcards and Charges.

                 

                Let me know in case you need any further details.

                 

                Cheers,

                 

                Akshay

              • Re: How long is the migration of charges taking when upgrading to 9R1?
                Dan Contreras Newbie

                Charge Migration pretty much goes through two parts:  migrating all unassigned Level2Charges and then migrating all expense charges (those charges that are linked to Expense Reports).

                 

                It will not update procure charges - those charges that are linked to the PCardOrders -- those will remain for historical purposes.

                 

                So far on the runs we have done so far, the Migrator has been processing 15 records/charges per second . .. or roughly 50,000-54000 an hour.

                 

                A possible workaroud for this is to go live with the most recent (i.e. 3 months, 6 months) charges migrated with the understanding that some of the historical data in the older expense reports won't be available until everything is migrated.

                 

                Migrating only the most recent months can be done by updating the MigrateL2Charge entry in  $buyer/Server/variants/yourVar/partitions/yourPart/ScheduledTasks.table file:

                 

                MigrateL2Charge = {

                ApplicationHints = {

                Parameters = {

                Feature = (

                AribaP2PBasic,

                AribaP2PProfessional,

                AribaTEBasic,

                AribaTEProfessional,

                CoreBuyer

                );

                Visible = true; <----- make sure this is set to true so it is visible in the Admin screen

                };

                };

                ChargeMigrationPeriodInMonth = 3; <------------------  number of months to go back

                ScheduledTaskClassName = ariba.expense.server.ChargeMigrator;

                };

                 

                 

                After Go Live - you can run this task every evening (or hours when there is not a lot of activity) and increment by a month or two each time . . . if you have 5 hours, given the times above, you can probably migrate 250,000 charges on each one . .. that might be one month or more; and you can adjust accordingly.

                 

                Another potential issue related to charge migration is if there are extrinsic fields (with values) in your current 8.2.2 charge objects.  If so, a ticket will need to be opened with support in order to migrate these values.