What you’ll take away: 1.Define team and schedule 2.Software and hardware specifications 3.Analysing 4.Configuration and migration 5.Validation and Test 6.« M » day System switch Brand & Industries or Technology: Wonderware System platform WW 18 Migration Services Best practices Peter Von Tluck David Curt Focus of presentation: The intension of this presentation is to provide System integrators, Application Engineers and End customers the right information how to build a strategy to migrate an existing System platform application. This should avoid unexpected behavior and reduce plant down time to a minimum.

>Upgrading a System easy ????? Introduction PLCs & Automation Application Object Server Historian Wonderware Information Server Device Integration Server InTouch Wonderware Enterprise Integrator System Platform

>Why do customers want (need) to migrate their applications? Reasons for upgraded

End of OS livecycle support ( Windows 2003) Reasons for upgrade

End of WW livecycle ( intouch 7.11) Reasons for upgrade

Company standards (use the same Systemplatform version on all sites) Come into enjoyment of new features (Historian, enhanced alarming, scripting improvements, improvements in robustness) Reasons for upgrade

Migration only possible during production breaks Downtime: hard to migrate systems running 365/24/7. Customers might be afraid that application is not working as before. Unexpectable re-engineering effort Validation (GMP/ FDA) Coordinate participants (Production, IT, Integrator, WW, Quality) General Problems

>Define project team >Not mix migration and functional modifications >stop any modification in the live galaxy as soon as the migration process started. >Don´t forget documentation!!! Migration most often is a project

>Define team and schedule >Software and hardware specifications >Analyzing >Configuration and migration >Validation and Test >« M » day System switch Main tasks Documentation preparation

1.Define a schedule 2.Downtime available or not? 3.Kick off and Milestones 4.Fallback strategy 5.Team members and responsabilities 6.Project management – Documentation / Guideline Timing and Team

>Define team and schedule >Software and hardware specifications >Analyzing >Configuration and migration >Validation and Test >« M » day System switch Main tasks Documentation preparation

1.Which version of operating system should (must) be used. 2.Inventory of the existing architecture (hardware, software, topology) 3.Virtual / Physical environment ? Software and Hardware specification

>Define team and schedule >Software and hardware specifications >Analyzing >Configuration and migration >Validation and Test >« M » day System switch Main tasks Documentation preparation

1.Analyzing wonderware software (IAS, Workfow, Intelligence, AOT......). 2.License aspects - review 3.Installation verification 4.IT requirements (operating system/ MS SQL Server/ IE/.Net version supported?) 5.Check compatibility Matrix: 6.Migration of existing data (Alarms/ Historian) Analyzing – Wonderware/TAM

1.Application review („customized“ parts - AOT, scriptfunctions, controls -, third party software) 2.Consider/ discuss Improvements (i.e. Terminal Server) “InTouch for Terminal Services Deployment Guide” 3.Memory/ User/ Resolution optimization Analyzing – System Integrator

>Define team and schedule >Software and hardware specifications >Analyzing >Configuration and migration >Validation and Test >« M » day System switch Main tasks Documentation preparation

1.Galaxy scrubber 2.Integrity check (exec internal_validate_integrity) 3.Migrate Galaxy (Note: System requirements!!!). 4.Keep the log of the migration. Migration of customers galaxy

>Based of previous information a detailed chronological procedure is written include at the end of the procedure some test task to be sure that everything is OK. >For each task define: -Start date: -What we have to do -Who is in charge of this task -What is the previous task and the next one >Note : MS Project could be used and another document should contain the detail of each task. >To optimize the duration try to parallelized tasks when it‘s possible and focus on the most important machine to restart as soon as possible. Guideline/ Documentation Management

>Define team and schedule >Software and hardware specifications >Analyzing >Configuration and migration >Validation and Test >« M » day System switch Main tasks Documentation preperation

>For precommissioning it best practice to setup a testsystem. >In any case hardware configuration and equipment should be not reduced!!! The testsystem should include at least the following nodes, to make sure that everything will work in a proper manner: GR Node 2 AOS nodes (redundancy) 1 Client node 1 WIS/ Historian node additional nodes for Workflow, Intelligence, MES to be discussed Setup a minimal test environment (not best practice)

>Hardware is replaced – new installation >For precommissioning it is best practice using the definitive hardware on the real environment in parallel (when it‘s possible). >Hardware is kept –upgrade installation >For precommissioning it is best practice using the same environment as the site. Setup a complete environment (complete server/database architecture of the migration)

1.Check engineering: Checkin/ checkout/ creating new objects/ galaxy dump 2.Propagation of changes (scripts, graphics) – Performance! 3.Runtime: Deployment (objects, InTouch view) 4.IO: DA Server/ diagnostics 5.Changes (new objects, scripts, TSE....) 6.Licensing 7.Data migration test (Historian block, MES Database content…) Precommissioning

>The role of the TAM: Act as trusted advisor!!!!!! Precommissioning

>Define team and schedule >Software and hardware specifications >Analyzing >Configuration and migration >Validation and Test >« M » day System switch Main tasks Documentation preperation

What we already did: >Prepare all the architecture: hardware and software >Migrate galaxy >Wrote a migration procedure: a detailed step by step procedure for the „M“ day with an estimate time for each task. >Testing/ FAT Migration plan X (New hardware)

What we need to do: >Synchronize objects with the new galaxy environment - freeze object development >„M“ day: >Synchronize database content with the migrated version at the latest opportunity to avoid „gaps“ >switch galaxy >Functionality tests/ health check >If needed fallback ;-( Migration plan X (New hardware)

1.„IQ“ test successful 2.Track if the timing is respected 3.Create a backup and keep the logger of the „M“ day Day „M“

1.In case of major issue we can switch back to the old system. So it‘s important to keep the old system ready to restart. Fall back strategy

What we already did: 1.Migrate galaxy on an dev. Architecture (similar as the customer architecture if possible) 2.Write a migration procedure: a detailed step by step procedure for the „M“ day with an estimate time for each task. 3.Test Migration plan X (Existing hardware)

What we need to do: >„M“ day >stop the galaxy >Migrate all the components in specific order (to optimize downtime) >Restart (on a minimum architecture) >Functionality tests/ health check >If needed fallback ;-( Migration plant X (Existing hardware) – not best practice

1.„IQ“ test successful 2.Track if the timing is respected 3.Create a backup and keep the logger of the „M“ day Day „M“

Keep snapshots of previous installation Fall back strategy for upgrade on existing environment

Conclusion What we expect !!!

What it is !!!

Conclusion >Migration is a project >Consider time buffer >Step back in case production will be affected >Better use new hardware environment than existing ones

>Tech Note 705 Wonderware Application Server Migration Tips >Tech Note 921 Optimizing SQL Server for Large Galaxy Migration >Tech Note 948 Migrating IndustrialSQL Server 9.0 to Historian 2012 R2 >Tools: Galaxy scrubber Techsupport Install Check Utility Addendum

Everything clear or do you have Questions?

Please rate this session. Scan the code using the GCS Connect App Thank you!