v14 Upgrade Comparison

[Legacy User]

Can anyone compare the level of effort to upgrade from v13 to v14 (Much less effort, Slightly less effort, Same effort, Slightly more effort, Much more effort) with an upgrade from v12 to v13 or from v13.0 to 13.3?

Our last upgrades were from v12.0.4 to v13.0.1 and from v13.0.1 to v13.3.

We are currently at v13.3, using SQL Server 2008 R2 DB, and using Business Objects for reporting.  Will be upgrading to v14.x.

It seems that upgrading from v13 to 14 would be slightly more involved because of needing to upgrade the DB and needing to switch from Business Objects to Jaspersoft.  I have no idea if installing Jaspersoft is more or less difficult than it was to install Business Objects.

Anyway, I'm just trying to get a general feel.

Thanks.

[Andrew M]

I'd advise that you think of the business objects to jaspersoft migration as a separate project, it's not just an install.

You'll need to rebuild all your reports that you want to keep, potentially also need to learn domains too if the ottb domain won't do what you want. (equivalent to universe).

Then you've got to factor in the user adoption, big bang might be possible since jaspersoft is easier to learn but there are product changes. i.e. cannot run reports from objects ottb

 

if you target 14.3 you can do the upgrade, then migrate over to jaspersoft later and even run parallel with BO.

If you go to 14.4/15.1 you'll be forced into two upgrades which potentially will need outside support to be achievable.

 

Might be worth engaging with CA or a partner who will have done many upgrades by now.

[Legacy User]

Thanks Andrew, great information and very helpful.  So, two follow-up questions:

1.  Did you upgrade to 14.x yourself, or did you engage help (from CA / Partner)?

2.  Considering just the application upgrade (no Jaspersoft or DB), how did upgrading to 14.x compare to prior upgrades (Much less effort, Slightly less effort, Same effort, Slightly more effort, Much more effort)?

Thanks again.

[Deactivated User]

I've upgraded my VM's and done fresh install to versions 14.x.

If the system already meets the requirements for OS and DB then my effort was about the same as with v13.

That is just running the install script. That is bearing in mind very little configuration, no un supported customization, no unposted timesheets or WIP items, very few custom queries, little or none db overhead and sod.

 

Regarding the install of Jaspersoft the only install I have done went through without the install script failing or crashing.

That was not the case with my several attempts with BO in r8.1. and eventually I gave up and stuck with Actuate which was much easier.

 

In v14 there also the creation of DWH which was not in earlier versions.

[System]

Hi GaylanColledge - Did any of the responses help answer your question? If so please mark as Correct Answer. Thanks!

[mike2.2]

Do not under-estimate the training for end users to use JasperSoft.

[Robert_Ensinger]

I second what Andrew & Michael say re: Jaspersoft. I can't imagine going straight to Jaspersoft from Business Objects as a part of a 13 to 14 upgrade (don't get me wrong - technically possible - just more than I would care to bite off with the upgrade). I recommend sticking the landing on 14.3, running both reporting technologies in tandem as you work to get Jasper and the Datawarehouse stabilized (our load datawarehouse incremental job is failing again <sigh>). Once stood up, run a separate Jaspersoft project to roll out, train, support, convert reports, etc (ours starts soon). Like Martti mentions, the Datawarehouse and Jasper are a big expansion of the app's footprint by the time you consider dev, test & prod environments.

 

T-shirt sizing - our historical data shows our 13.2 to 14.3 upgrade 150% the effort & 333% the duration of 13 to 13.2. We virtualized MSSQL while moving from 2K8 to 2K12 and ran into performance issues that took unbudgeted time & effort to resolve. Going directly to 14.3 with the 14.3 installer did not work for us. We had to step through 14.2 then upgrade to 14.3. Notice the CLRTs in the attached document. Step 76 is rebuilding all our scheduled Execute a Process jobs that got cancelled because of a new "Allow only one running instance" feature on the Execute a Process job.

 

Nice addition - not a fun surprise late in testing to find 50 some jobs aren't running only to find them mysteriously cancelled. I don't know if this is documented now - I never found it at the time we hit it.

 

In good news - Content Packager was a shining star. Being able to migrate views forward saved 80 to 100 hours of effort from previous upgrades.

 

HTH

Attachment(s)

CA PPM 13.2 to 14.3 Upgrade Script.docx   286 KB 1 version

[Deactivated User]

Thanks for the script Robert_Ensinger that is great.

[Janet Ulrich]

I would also suggest doing any database or system software upgrades on the current version (look for common versions of this software between CA PPM versions) seperately from the upgrade. That will remove those from the risk and effort involved in the application upgrade. I would also recommend if you are doing any hardware moves/upgrades, that those be done seperately before hand as well.

[Robert_Ensinger]

GREAT call out Janet. Example: we took the DB upgrade portion of our upgrade in steps. In 13.2 we went from 2K8 to 2K12 first on physical servers, gave two month of bake time, then made the virtual jump. We fought the performance issues on 13.2, then after a couple more months of bake time did the software upgrade. Separate the architecture changes from the software changes as much as possible.

[Deactivated User]

Yes I, too, agree with that. Pay attention to jaspersoft requirements as well in planning as they differ from CA PPM requirements.