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......................

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 ;-)

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

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)

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.

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.

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

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

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

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

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

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

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.

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

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.

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

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

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.

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.

Questions? Nigel.montgomery@novartis.com, David.garbutt@biop.ch