What you’ll take away:1. Define team and schedule2. Software and hardware specifications3. Analysing4. Configuration and migration5. Validation and Test6. « M » day System switch

Brand & Industries or Technology:Wonderware

• System platform

WW 18Migration ServicesBest practices

Peter Von TluckDavid 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

HistorianWonderware

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

https://support.microsoft.com/en-us/gp/lifeselect

End of WW livecycle ( intouch 7.11)

https://softwaresupportsp.invensys.com/Pages/ProductHub.aspx

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

Docum

entation 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

Docum

entation 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

Docum

entation 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: https://gcsresource.invensys.com/ProductCompatibility/HTMLClient/

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

Docum

entation 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

> Define team and schedule

> Software and hardware specifications

> Analyzing

> Configuration and migration

>Validation and Test

> « M » day System switch

Main tasks

Docum

entation 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 Node2 AOS nodes (redundancy)1 Client node1 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

Docum

entation 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 705Wonderware Application Server Migration Tips

> Tech Note 921Optimizing SQL Server for Large Galaxy Migration

> Tech Note 948Migrating IndustrialSQL Server 9.0 to Historian 2012 R2

> Tools: Galaxy scrubberTechsupport 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!