FOCUS AREAS

Hot Topics

Related Links

Dependencies

Migration

Matching Resources to Needs: Details

Use the issues in this topic to discover more about your site's needs. See the previous page, Scheduling, for an overview of this process.

Determining Need for Migration Aid

A SAS user's need for technical help is generally equivalent to the user's familiarity with SAS software, SAS files, and third-party databases. If some members of a workgroup are not familiar with SAS, you might be able to identify a single individual in each workgroup, or an individual from another workgroup, who can migrate the data, SAS programs, and custom applications.

Minimizing Downtime

This might be your most important goal for the migration schedule. A planned outage might occur, for example, while you switch production from the source installation to the target installation, that is, when you bring the new installation online.

Best practices

Addressing Interdepartmental and Workflow Dependencies

To learn where dependencies occur, simply use a whiteboard or paper and pencil to map the workflow, upstream and downstream. Ask individuals how their processes flow among or within departments. For example, does group A perform a process that group B acts on? Should group A migrate before group B, or should both groups migrate together?

Best practice

If your IT or helpdesk department migrates early, they can respond better to user questions.

Addressing Dependencies between SAS and Third-Party Software

Ask individuals to list all the software that interacts with SAS. One obvious dependency is in output, such as an HTML browser or RTF reader. Another dependency is input, when you access a third-party database. Or you might have a custom Web interface layered on top of SAS.

Here is an example: consider a workgroup who collects operational data in Oracle and queries it via SAS/ACCESS software. The workgroup must migrate the third-party software together with SAS, and must determine how to maintain access to Oracle data at critical times. In addition, they must confirm that their release of Oracle is supported under their target operating environment in SAS/ACCESS 9.1.

Addressing Dependencies from Batch SAS Jobs

Determine the batch SAS jobs that are regularly scheduled. The largest jobs usually run at night. Questions include the following: Who or what depends on the output from those jobs? What happens if the jobs are interrupted? Can you keep the SAS job and the recipient of the job's output together during migration?

Migrating in Stages

You can migrate in stages for different reasons:

See Running Source and Target in Parallel for issues such as disk space, CPU time, peaceful coexistence, and live update.

Fulfilling Service-Level Agreements

Service-level agreements define the amount of support that is provided for an application. These agreements can be made from one group to another within your organization, or from your organization to a client.

Planning for Rollback

A rollback plan is a safety net, providing peace of mind during migration. You know you can go back to the source installation in the unlikely event of a disaster-recovery situation.

Best practices

Need for Training

Strategies for training can vary widely. You might want all full-time SAS programmers to take SAS training in changes and enhancements. Consider scheduling introductory training at the beginning of migration and product-specific training or advanced training as users' experience with increases.

Significant new features can be found in SAS/IntrNet, ODS, MP CONNECT, SAS Intelligence Platform products, the MDDB-based OLAP server, thread-enabled procedures, new Base SAS functions, XML, section 508, national language support, PROC MIGRATE, and installation validation.

Remember that adopting new SAS features can result in significant changes to your processes.