DI Studio Migration or the SPK shuffle

[RedPlanet]

We are migrating from DI Studio 4.21 to 5.3.  The DIS Migration document recommends using the migration wizard, followed by deployment and post-deployment tasks. It looks easy on paper.  Is it?

I got flak from the system admin about doing a CSB migration.  Too much trouble, and not enough time.  He recommended exporting everything, and then importing all of the objects into the 5.3 trees.

Here's the problem.  The export process is not so good, and it takes 30+ spk files to export everything.  Then it needs to be imported into 5.3 with no planning on where the data is supposed to go.  I know that the directory structures have changed, so where are the best places to import the data?  When I consider those facts, the migration utility looks much better than the export and import of spk files.  Not to mention the potential governance issues of all this manual work with 30+ spk's and logs to keep. 

Note that we do not have access to the ExportPackage command, which would let us write a script to export the 30+ spk's.  Nope -- we would be doing that manually, and I expect that we will encounter many errors from the Java interface, which has some memory overflow errors for large packages.  Are large package exports even a good idea -- either for me or the admin?  I suspect they are inherently error prone.

If you (or your admin) used the CSB migration utility for any version of CSB, please tell me how it went.

If you used the spk import/export method, please tell me what you like or dislike about that method.

If you have any convincing arguments for my system admin, I am all ears.

[jakarman]

DI 4.21 is related to SAS 9.2 SAS Data Integration Studio

DI 5.31 is related to SAS 9.4 SAS Data Integration Studio uhh latest version DI =4.9 did I miss something or is it an other tool/product?.

    You are probably in the tool/solution Credit Scoring for Banking as that has a version 5.xx

    A solution is build on top of BI/DI and you should be confident in all those layers and tools.

Both are using the SAS metadatabase and SAS metadata server of that SAS version. That structure has been changed while adding all kind of new features. 

Comon guidelines:

1/ The DI studio tool (extend the xmx setting in jvm-windows) That setting will allow DI to use bigger numbers of data.

2/ The SAS metadata should be defined and set-up in some concept  libraries jobs in some application and artifacts structure suited to your business.

3/ Some ict governancel processes to be aligned to your business.

Are you saying this all has been missing? 

When this is in place your migration is dong more of the same kind. Rrelase management of tools/middleware as infrastructure).

  - new middleware (SAS) getting installed

  - synchronize environment (business) for system verification

  - advance to user acceptance and synchronize (business) again

  - going into production (business) with new infrastructure

should not require longer as 6 months, speeding up in 3 months.

You are not the only one with this kind of trouble. SAS migrations can take looonnnnngg times. Many do not even start with that. 

[RedPlanet]

That's great advice on the migration and the timeline for implementation.

Versions were my end-of-day numbers, and it was a busy day.  We are upgrading CSB (SAS Credit Scoring for Banking) from 4.4 to 5.3, DI Studio from 4.21 to 4.9, and SAS from 9.2 to 9.4. 

The metadata for CSB 4.4 has a different structure than CSB 5.3.  CSB 5.3 was installed without migrating CSB 4.4, and only has the Libraries have been imported.  There has been no planning for where to place other objects exported from CSB 4.4; but we would probably keep the old "directory" structure.

I like your development plan, and much of that has already been done.  But the CSB migration looks like a major project that requires more time that we have available.  Even 3 months would be too long.  We are looking at alternative solutions which can be implemented quickly, while we figure out what to do with the new CSB software.

I'm not sure how to change the Java options.  I killed the current Java process, and then ran my own version which uses more memory.  I'm hoping that DI uses the version that's running now. 

[jakarman]

For DI on the desktop, no it not running the java version you have installed on your own (browser included). Be happy they are not connected.

To find those setups for java go to the installation directory of sas. It is named normally <sashome>  wrong name/expectation as it is NOT your home directory.

Exploring that one you will find the product and ini files. Those ini files are the settings that a wrapper program (looking like a windows program) is using the java application.

DI is a java application. The used java version is a JPRE of some dedicated version.  

SAS(R) 9.4 Intelligence Platform: Desktop Application Administration Guide, Fourth Edition

That the metadata for CSB 4.4 is different than CSB 5.3 makes sense it is new version/release.

As it is a solution most should run out of the box. Than you are needing the business data, no SAS is not going to do that unless they would do a take over of your company.

That makes a full copy of the metadata content imposibble. The best thing would be only the thing that have been updated/changed for your business process.

Make me wondering why thinking on a new tool would save time. Not knowing your business process is either you have none and it can be dumped or there is something important going that is missed. Start with you business process, needs impact is the leading one for decisions.