Migrating a v4.2 project to v7.1

[tammy_dezilva]

Hi

I am wondering the best way to migrate projects that were created in v4.2 of e-guide to v7.1.  We will be running in parallel initially so will be needing to keep both versions of the projects, plus also need to amend file paths as part of the migration.  What would be the most efficient way to do this?  I know you can manually open a v4.2 project in v7.1 and it can update it but I want to be able to do this plus update the file paths in batch for all projects if possible.  I've read about a migration wizard but am not 100% sure this is suitable or where to get it?  We are not migrating anything else other than the projects but rather starting from scratch in our new environment for metadata/user access etc but need to enable our existing users to be able to run their projects as before initially.  No tables are defined in metadata in the old environment so there is no need to migrate metadata.

thanks

Tammy

[Kurt_Bremser]

Since this is a one-way road (you can't open 7.1 project files in 4.2), I suggest to copy all the project files to a dedicated "7.1" location for use with the new version, so the old version is still available for the 4.2 users.

I'm afraid there is no way to backport changes made in 7.1.

If you set paths in a project to relative, the project will work in the new location if you copied all the files along with it.

[jakarman]

EGuide is an IDE not an production environment.

Having all paths etc hard-coded within EGuide will be hurting in operations and migrations.

A better approach would be to eliminate that as much as possible by stroring those as dedicates server objects and just use Eguide combine that all.

Now you are within a migration ask whether that improvement change:

  a/ can be done (what is the impact)

  b/ is necessary  eg by using 4.2  7.1 egp's by different users.

  c/ a nice to have you can manage the change without that.

  d/ something for some else after the migration.

[tammy_dezilva]

Yep we will be taking a copy of all the projects as we need a 4.2 and 7.1 version while doing parallel testing.  Unfortunately the projects are all owned by power users which existed well before I started.  They import files from a network drive (majority of the them via File -> Import rather than doing code) and we now have a newer and faster storage in the new environment where we will be copying all their files and tables to.  This new path is a different name hence why we need to amend the path in the 7.1 version of their projects.

We're not migrating anything else - just the projects and copying over user tables and files.  The rest is a new environment we will be building a data warehouse from scratch.  The old environment isn't really a data warehouse but rather teams just creating their own tables and doing their own thing.

[tammy_dezilva]

i have discovered the location of the migration wizard is on my PC under C:\Program Files\SASHome\SASEnterpriseGuide\7.1\MigrationWizard and this is the tool to use rather than the migration utility in the SAS depot which would be used during installation instead.  This wizard will do all that I am needing.

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

[tammy_dezilva]

This doesn't do all of what I'm needing.  The file paths cannot be modified via the wizard if they are in code, only via metadata.  Bummer!

[SASKiwi]

That's why it is now good policy to avoid coded LIBNAMEs in SAS server environments where possible and rely just on metadata-defined ones. Or if you have to use them, define the directories used in macro variables just once in your application setup. It makes migration a lot less painful. 

[tammy_dezilva]

The environment I have come into is not a very sophisticated set up so I have to work with what we've got for the initial move and then educate people more.  We are most definitely defining libraries for teams as required in Management Console in our new environment instead.  If we were to change everyone's code before migrating to take these out and define metadata in the old environment before migrating, we'd never get off it

[Kurt_Bremser]

I suggest that you make all your users aware that the Enterprise Guide is a fine DEVELOPMENT tool, but a very bad choice as a PRODUCTION tool.

Once a project leaves "project" status, the result needs to be codified in one or more .sas programs for batch processing and handed over to the people who run your IT. Changes in file locations would then not affect your programs, because file names are handed to them by the scheduling/jobcontrol system.

You also gain the benefit of using the common versioning repository etc etc.

[tammy_dezilva]

These are e-guide users within the business who generally do not write code but instead use the point and click tasks within e-guide.  They are doing all sorts of analysis - some of these projects they run ad hoc or some regularly.  These users are only working off a production environment (and don't know anything but the production environment) rather than developers who have access to any development or test environment. 

I'm not sure I understand what you mean by a project leaving "project" status?  Or are you meaning a project in business terms rather than an enterprise guide project file?

[Kurt_Bremser]

Usually, things done regularly within a EG project will "mature" and reach a status where

- the results are considered correct

- changes to the logic are rare and far between

- only some parameters (like dates) change from execution to execution

At this point the project code should be made "batchable" SAS code and handed over for batch processing, The people there can supply the necessary parameters.

This is, after all, BUSINESS intelligence and needs to adhere to BUSINESS standards in terms of accountability, repeatability, documentation etc. Keep in mind that decisions that may affect the survival of the organization are based on the results of these analyses.

Ad-Hoc analyses may face different needs. But in our organization, even a one-shot SQL query against the database is handled like a complete program:

- a request is made

- the code is created

- there's a check done by another developer (visual check of the code)

- the request, code and result is documented in the change management system

[jakarman]

tammy, yep it is there. Doing all you are needing? Hardly is not verifying the conversion result is a good working result.
The proof of the pudding is the eating.  Having changed names you still have to change and verify those all.

[SASKiwi]

I'd also strongly recommend you do data compares between the old and new projects as well. We recently migrated from SAS 9.3 to 9.4 and found we needed to make process changes to ensure that we got the same or very similar results. PROC COMPARE is an invaluable tool for this.

[jakarman]

Tammy that environment is like a natural wilderness.  ;<))     To get it more social organized according an ICT habitat you have to start.

One of the things I would advice to do is do a quick check whether you are needing additional appservers. The appservers are what the name is indicating a segregation in application areas/domains. Having that well planned and ordered all things after that are more easy to implement and migrate.

Libnames can be defines as autoexexs (usermods on the appserver) and as metadata definitions they have the goal of eliminating those from user code. The autoexec approach is behaving more direct in the same way as the normal SAS code. Putting all in SAS metadata is building additional layers around those.

Having those pathnames hardcode in source "why not it works" is a bad approach for conversions and release management as the same for developing in production "who changed that?".