We have finally successfully migrated our 8.2.2 instance to 9r1 (upstream and downstream) minus SAP PI integration but with significant effort. After 160+ technical support cases and 6 months later we're still in development ironing out a few remaining issues but we're closer to our QA target first week in April. We're operating on SP9 HF3 and waiting on SP10 in April to fix a number of core issues. IVT doesn't work and Ariba has since acknowledged this with notice that it MAY be potentially fixed in a future SP.
1 of 1 people found this helpful
I have a copy of our production code all the way through the harness and the environment up (SP7, Downstream, we use Buyer, T&E, Eforms, Invoicing, Settlement, Contract Procurement). It actually looks pretty good. I did have to keep checking the migration logs and resolving issues. Some classes needed recompiled or missing or fixed. Really didn't think the aml upgrade was too bad, it seemed to figure out in most customizations places where a superclass may have changed and swapped it in. I remember having a few to do manually. Granted so far I just mean to the point of bringing the system up, not using or replacing to future state (example types of things looking at now after system up: custom user profile details fields doesn't show - the group name changed, move what you had into the new group name). I think the IVT can be ignored, similar things come up running the harness (but a lot more), so just running the harness on a copy of the prod code on a Windows machine helped me. Each task produces its own log, and archives when you have to rerun so you can get a history of the failures. For CSV files it tries to do it's best guess at a merge and so far from what I can tell did a decent job. The output directory stores the resulting file, but also what a "vanilla" would look like for when you go through them. We have a long haul ahead of us but I think getting through the harness and seeing what our upgraded LFG looks like will help us in requirements for what we should be doing the rest of the way through the upgrade. We also have a vanilla up and I think moving back and forth between and vanilla and what we have now immediately post harness upgrade will be really important for our requirements meetings.
-Tom Tobey, Lincoln Financial Group
We were missing a lot of the java source files. I had to decompile them - you want to do this before the task harness. The task harness / recompile does do a really good job of replacing classes.
1 of 1 people found this helpful
After upgrading Sourcing, Analysis, ACW, Buyer, Contract Compliance and Invoicing to 9r1, I would think it would be extremely difficult to do without Ariba's help. We had a full-time Ariba resource that had been through multiple migrations on site for 8 months. Even with this resource, we had many cases with Ariba support to address issues encountered. The documentation provided by Ariba is inadequate to fully understand the migration process. If you had only Buyer, then I think it would be possible to do it without assistance. But when you have all the modules, the migration process is much more complex. The first 2 mock cutovers we did failed to migrate the Sourcing data. We had multiple cases and worked with Ariba engineering to finally get to the point where we were able to get Sourcing data migrated on our third attempt at mock cutover.
The other things we encountered during mock cutovers was that we would hit errors that stopped us. Without the Ariba consultant, who had deep knowledge of the migration harness and underlying scripts, we would have been unable to move forward in a timely manner. We would have had more cases and wait time.
A lot may depend on the complexity of your environment and how customized things are. But I would recommend getting some help if you are migrating to 9r1.
After 13 months, we're about to go-live with 9r1. We used our own staff and 2 consultants from a 3rd party consultancy. There definitely are issues with the migration scripts that require Ariba Connect Technical Support and some that are best left to your project team to dive into the code to resolve. We have the internal resources with significant technical experience and some that had gone through upgrades in the past (Ariba 7 to 8 and 8.1 to 8.22). In my opinion, if your internal staff have not done Ariba upgrades before, then you will likely struggle to upgrade to 9r1 without outside help from a consultancy or Ariba's upgrade lab. If you have strong internal technical resources, then going through the process yourself, or with minimal outside help, is invaluable knowledge to support and enhance 9r1 post upgrade.
Key things to note:
- We did 4 migrations prior to production cutover, 3 of which we used Production database copies. I can't stress the importance of using Production data in your development and rehearsals. In the end, all you should care about is what you'll run into during Production cutover and this is the best way to accomplish this.
- Some migration scripts are poorly coded to handle large volume data. In particular the "PCardOrderChargeAccumulatorMigrator" took 20 hours against our Production data due to object reconstitutions. With the help from Ariba technical support, we found that other clients ran into the same issue. By changing the task to run update statements against the table instead of iterating through 400,000+ objects, we reduced the task to 5 minutes! (this should have been addressed in a Service Pack as the migration impact is very significant)
- Upgrading custom code from 8.22 to 9r1 was fairly straight-forward with 3 exceptions:
- The change from Level2Charge to Charge is very significant with impacts to charge loading and charge reconciliation. Charge Loading functionality in 9r1 regressed from 8.2. We ended up taking the 8.2 Level2ChargeLoader and customized it to work within the 9r1 framework. As a result we can process multiple charge files at once and leverage the file handing logic 8.2 had by moving files from transactionData incoming directory to processed. It's a head stratcher why Ariba took this functionality away in 9r1 as I can't imagine any On-Premise client not implementing a custom solution for the Charge load handling.
- Upstream removal of the standard conditions package. Ariba does provide a download of ariba.app.common.zip that allows you to continue to call Ariba's conditions, however the package was not upgraded from ASM 4r4 and some conditions have method references that do not exist in 9r1. (BTW, we do have a change request in to fix this.) Working around these conditions in and of itself was actually easy, however; we ran into significant issues and delays with Suite Integration that, in the end, pointed back to some of these conditions referring to invalid methods. The root cause however, was not evident through Suite Integration itself.
- 9r1 SAP transports have many issues with hard coding SAP Service Pack numbers in them. We are on a supported version of SAP, but Ariba's transports have these hard coded service pack issues such that we had to customize many of the function modules just to get them to operate. Secondly, and this is very significant, the Ariba 8.2.2 function modules no longer work as soon as you apply the 9r1 transports in your SAP system. This was totally avoidable had Ariba renamed some of the SAP key tables as they had done with the function modules themselves. As a result, clients are left in a bad situation in trying to develop for 9r1 while maintaining 8.2.2 integration with SAP. As a result, we were forced to suspend SAP integration changes during the project.
- We experienced significant delays in our timelines due to issues with the Service Pack we were upgrading on (SP15). The issues were not migration related, but rather core functionality related. We delayed our project until we had all our issues resolved in Hot Fixes. Due to the length of our upgrade, we decided to go with the latest SP in order to receive the proper Hot Fix support through the duration of the project (HF support typically only goes back 3 SPs). Lesson learned here is to give additional time in your plan to receive, apply and test Hot Fixes beyond your 1st round of regression testing.
- When idenitifying a Show Stopper/Go-Live Blocker issue, escalating the SR and providing a need-by date with Ariba Support is key. Ariba Support was great at turning around our show stopper issues or working with us to create suitable workarounds.
Hi, does anybody know how long the task harness will typically run?
It's hard to say what's typical as every Ariba customer's database is different due to usage of the system.
I can give you our stats:
For Upstream, the harness took 7.5 hours.
For Buyer, the harness took 3 hours. We had over ~400,000 POs. Most of which were PCard Orders. Note that we removed the PCardOrderChargeAccumulatorMigratorTask from the harness, as it was taking 15 hours to complete. We optimized the code and ran it post migration as a scheduled task that only took 5 minutes. If you use PCards and have a significant amount of PCOs, then you should look at doing the same.
Suite Integration took 13.5 hours.