Upgradation of SAS EG from 4.2 to 6.1 and SAS from 9.2 to 9.4

[nandanosho]

Dear All,

I want to upgrade my application from SAS 9.2 to SAS 9.4 and SAS EG from 4.2 to 6.1. So How much effort it will required to upgraade my Application.

Please Suggest.

Thanks

[jakarman]

What do you need to upgrade? You are mentioning tools releases. The planning is more on what artifacts you have, *metadata di like, information maps web) and what the effort is for converting / rebuilding.

All can be different to each business environment

[nandanosho]

I want to upgarde my SAS version from 9.2 to 9.4 and SAS EG from 4.2 to 6.1

[Kurt_Bremser]

This depends very much on the way you need to do the upgrade, and what your environment looks like

- Is your server only for SAS (that means: no other apps can cause conflict (eg port numbers) with SAS)

- Will you set up a completely new server/client environment? In that case you can do the install out of the box on the new server (and possibly clients), without altering things like install path (esp. the configuration in the SAS subdir) or port numbers. Manually selected port numbers can cause lots of grief

- Do you want to migrate your metadata or will you create new metadata (eg if you found logical shortcomings in your 9.2 structure)

SAS only server with a completely new, "green field" installation could probably be done in one or 2 days. Complex installations (multiple-use server, several concurrent SAS versions) can take months (I know from dire experience) until you've weeded out all the errors.

[ChrisHemedinger]

SAS has a section of the support web site devoted to migration topics. See: Migration: Planning

As others have said, this can be a very simple process depending on the complexity of your current environment.  You can add SAS Enterprise Guide 6.1 to your PC without removing 4.2, so you can work with the two versions side-by-side until you've completely switched over.  And SAS Enterprise Guide 6.1 can work with SAS 9.2 through 9.4, so you can make the switch gradually if needed.

If your SAS environment is simply a SAS workspace and metadata server with no other services/assets, then the conversion is probably very simple.  If you have other assets such as web reports, stored processes, etc. -- then you will need to make sure that those metadata-based items are migrated over properly.  The link I cited above can help in that planning.

For SAS Enterprise Guide project files, your EG 6.1 will open the 4.2 projects and convert them automatically.  However, once you open/save them in 6.1, you cannot use them again in the EG 4.2 version.  It's best to keep a backup copy of the files before this conversion.

If you are also moving from 32-bit SAS 9.2 to a 64-bit SAS 9.4, then you'll want to read up on these cautions/guidelines.

Chris

[SASKiwi]

It is worthwhile noting that as well as upgrading SAS, you need to test your SAS 9.2 programs to make sure they still work correctly in SAS 9.4, and ensuring that they give you the same results. You may need to consider keeping SAS 9.2 for a while so you can compare results between 9.2 and 9.4.

We are just going through a SAS 9.3 to 9.4 upgrade ouselves and we estimate that SAS application testing will take at least as long as it did to upgrade SAS. We have already found a number of differences between 9.3 and 9.4 that required code changes and I expect you will strike more going from 9.2 to 9.4.

[DaveBirch]

There are few things to note generally about upgrading software versions.  Often, it is not the only thing being changed.  Sometimes, you are also changing platforms, e.g. from AIX to Linux, this requires migrating (not just copying) the data as well.  Also, organisations frequently use the opportunity to introduce/enforce corporate standards, such as standard Autoexecs, autocall macros.  These are usually the main cause of coding changes, as SAS (at the code level) is pretty good at maintaining backwards compatability.

Applications that are built with code generators, such as SAS EG or SAS DI Studio, have the additional complication that a new version may generate different code, or won't recreate specific customisations.  One example that I've encountered in converting from EG4.3 to EG5.1 is code that had been generated as:

    /* SUM_of_volume */

       (SUM(t1.SUM_of_volume)) AS SUM_of_volume

became:

    /* _calculation */

       (SUM(t1.SUM_of_volume)) AS SUM_of_SUM_of_volume

without modifying the node anew.  Needless to say, later steps failed with missing variable errors.

In many ways the greatest effort in upgrading versions is in testing your applications.  As others have advised, a careful staged approach with both versions running in parallel is safest.