1. AD07: Migration + Upgrade = happy users, but how much downtime
AD07: Migration + Upgrade = happy users, but how much downtime? Nigel Montgomery, Novartis Pharma AG & David Garbutt, BIOP AG
Describe each of our roles:
NM – Business Coordinator:
1 of 3 in the end
Coordination between business and IT and to relay appropriate information / details when needed. (Desribe business here).
DG – Soultions Architect:
1 of X in the end
Responsible for

2. Content
Description of migration and upgrade as part of the whole GPSII upgrade project at Novartis
Lessons learnt (both good and bad) – described in detail
Examples of SAS differences discovered
Summary
Mention briefly the ‘migration’ picture – the more beautiful version of migration ;-)

3. Migration and upgrade as part of the GPSII upgrade project
GPSII upgrade involved:
SAS data conversion from version 8.2 to 9.2,
Clearcase upgrade,
Server migration, relocation and virtualisation,
Some 900 users over various different departments
Incorporating approx. 3 TB of SAS data

4. Migration and upgrade as part of the GPSII upgrade project cntd
Mention:
2 servers to 1 server, running SAS, two others running ClearCase
System downtime and hence disruption to daily work,
Other technical stuff (Dave)

5. Lessons Learnt: Do not under-estimate what you need 
Thoroughly evaluate:
what’s within the scope of the project
Discuss with key stakeholders on each task / subtask to get time estimates for completing.
Edge on over-estimating resource.

6. Lessons Learnt: Consult ALL business areas.
Consulted for inpact on their area and input on timelines, proposed go-live dates etc
omission of one or more business areas will result in re-work and loss of time.

7. Lessons Learnt: Ensure the appropriate communication channels are set-up
Setup AND used efficiently and effectively
Between key stakeholders
Obviously driven by the project manager
Failure to have these in place can lead to increased downtime, confusion etc

8. Lessons Learnt: Do not be afraid to (radically) change your plan
45 pg
17 pg
If there are time issues.
Question everything you do and if it is really necessary.
Look for parts that can be done in parallel.
Look for differences in your Migration Units (that can be exploited (mention CNC projects here.
Once concrete plans are in place, thoroughly document your processes and all it’s elements.
Our original basic 5 step process turned into a 40 step process.
0.25 page

9. Lessons Learnt: Perfecting the process – from parallel and homogenous
8 copies of the
Replication
Migration
Conversion process
All Vob bundles alike (homogenous)
Done independently

10. Lessons Learnt: Perfecting the process - to two streams, heterogenous
First – split replication to separate stream done first
Second – split bundles by their urgency and activity

11. Lessons Learnt: Perfecting the process - schedule as three types
First – Weekends  FIXED
Second  fixed
Third  inactive – background fillers can be
re-scheduled easily

12. Lessons Learnt: Develop a clear and concise migration schedule, after having assessed all variables.
Variables here include:
Business constraints (when project can migrate),
Project size
Other points:
Schedule in some slack for catch-up activities
Downtime minimised by scheduling VIP projects to migrate over a weekend (describe VIP projects – with studies close to submission and deemed highly important to Novartis Management9
Perform Dry Runs in order to make good time estimates for migration, develop a list of migration issues (and hence how these can be fixed)
Following on from the above, accurate time estimates on migration are much more important than keeping a commitment made before testing began

13. Lessons Learnt: Manage expectations: - Process was expected to run ‘like a machine’ from the start
Mention:
Unexpected / unforeseen problems that the planned process had not been developed to deal with.
Only through repeated testing, dummy runs or actual ‘real-life’ runs will the developed process become more stable.

14. Lessons Learnt: Automate the migration process where possible
With ad-hoc scripting tools for fast coding, easy redesign, monitoring and notifications.

15. Lessons Learnt: Users MUST follow all given directions / instructions
Additonally take recommended training.
Explain the above figure (IMAN and Migration Champions role) and that it not only works for post migration, but also pre and during migration.
Following the correct path (as per the figure) will avoid additional work for the project team.
Example of not following the standard path: Personnel asking questions directly to Migration Champions / Business Coordinators for a question, when it had already been answered in the FAQ.

16. Examples of SAS differences found
1. Change in the file name function / option:

17. Examples of SAS differences found
2. When using if then else statements, a ‘lagging’ then cannot be used:

18. Examples of SAS differences found
3. Standard transformation for confidence intervals changed from LINEAR to LOGLOG. Use the Survival statement with convtype = LINEAR to reproduce sas v8.2 results:
State, there are more in the paper.

19. Summary
Thoroughly assess the project before making any resource estimations
Involve all appropriate departments from an early stage and make sure appropriate communication channels are in place.
Develop a clear and concise migration plan, getting input from all appropriate areas affected and manage expectations of all business personnel involved
Put in place a process for issue management (and make sure it is followed), adequate documentation and training etc
Specific details can be found in the AD07 paper on the PhUSE website.

20. Questions?