Assessment Phase: Know What You Have Before Migrating

Part 2 of 5: Optix Migration Planning Series

Click here for Part 1

You've decided to migrate to FactoryTalk Optix. Or you're evaluating whether to migrate. Either way: You need to know exactly what you're migrating.

Assessment Goals

By the end of assessment, you should know the exact scope (screens, features, integrations), complexity factors (Global Objects, custom logic, animations), technical debt (what's messy and needs cleanup), migration blockers (what can't be automated), realistic timeline (based on actual complexity, not guesses), and resource requirements (people, training, tools).

Tool: Use the Migration Readiness Assessment Checklist as your assessment framework.

Application Inventory

What You Need to Document

For each ME application, document basic info and usage patterns.

Basic Info:

• Application name and purpose
• Last modified date
• Who maintains it

Usage:

• Number of deployed instances
• Target hardware (PanelView model/size)

Why it matters: You might have multiple ME applications. Some are critical (migrate carefully), others are legacy (migrate or retire?).

The Hidden Application Problem

Common scenario: Engineering says "we have one ME application."

Reality:

• BaseTemplate.MER (the original)
• Customer_A_Modified.MER
• Customer_B_Modified.MER
• Test_Version_Jan2024.MER
• Backup_DO_NOT_USE.MER

Which one is current? Assessment forces this question. Answer it before migrating.

Screen Analysis

Inventory Every Screen

Create spreadsheet documenting screen name, purpose (overview, equipment detail, alarm, trend, etc.), complexity rating (simple/medium/complex), dependencies (what screens link to it), and estimated migration time.

Complexity Rating Guide:

Simple:

• Display-only graphics
• Standard objects
• Basic tag bindings and information

Medium:

• Data entry to PLC
• Navigation and popup screens
• Basic animations
• Trend displays

Complex:

• Recipe Management screens
• Complex animations
• Global Object usage
• Custom graphics
• Dynamic object generation

Why it matters: "20 screens" could be 40 hours or 200 hours depending on complexity. Know which before quoting.

Navigation Mapping

Don't just count screens. Map how they connect.

Example structure:

Main Menu
├─ Overview Screen
├─ Equipment Screens
│   ├─ Tank 01 (links to: Setpoints, Trends, Alarms)
│   ├─ Tank 02 (links to: Setpoints, Trends, Alarms)
│   └─ Tank 03 (links to: Setpoints, Trends, Alarms)
├─ Alarm Screen
├─ Trend Screen
└─ Setpoints Screen

Why it matters: Navigation structure in Optix differs from ME. Understanding current flow helps design better Optix navigation.

Opportunity: Many ME applications have navigation that evolved iteratively. Optix migration is chance to rationalize it.

Complex Logic Assessment

The Global Object Question

Custom ME behavior doesn't automatically convert. Global Objects and custom logic are the biggest migration complexity for discrete OEMs.

For each Global Object, VBA script, or other custom behavior, document what it does (functionality), why it exists (problem it solves), how often it runs (event-driven, periodic, manual), can it be eliminated (Optix might handle natively), and does it require NetLogic (true custom logic).

Category 1: Optix Handles Natively

Many custom solutions solve problems that Optix handles with built-in features.

Common examples:

• Dynamic enablement/visibility (use advanced links and converters)
• Recipe save/load (use Optix recipe manager)
• Alarm filtering (use Optix alarm query features)
• FTP file operations (built-in Optix support)
• Event logging (better built-in logging)
• Alarm export functionality

Migration effort: Zero NetLogic needed, use built-in features.

Category 2: Leverage Template Architecture

Some HMI behavior will scale better by using the template architecture and reusable components rather than direct conversion.

Common examples:

• Equipment reuse across multiple machines (template instances with different configurations)
• Popup parameter passing (alias-based popups instead of hard-coded screen references). See this post for an example.
• Reusable motor/valve/tank faceplates (template types with configurable options)
• Multi-state graphics (template-based state machines)

Migration effort: Moderate, requires understanding template architecture. See the Architecture Advantage post for methodology.

Category 3: NetLogic Development

Advanced functionality requires software development skills.

Common examples:

• Integration with external systems (REST APIs, TCP/IP)
• Design time scripts for automating development
• Custom reporting beyond standard trends
• Advanced animations and visualizations

Migration effort: Significant, requires software development skills.

Category 4: Eliminate Entirely

Some custom solutions exist only to work around ME limitations.

Common examples:

• Workarounds for ME limitations
• Redundant logging (Optix has better built-in logging)
• Screen navigation hacks (Optix navigation is more flexible)
• Tag value manipulation that Optix converters handle
• Custom popup management (Optix handles this natively)

Migration effort: Negative (saves time by not porting).

Reality Check

If you have extensive Global Objects or custom HMI behavior, budget more time for conversion and template design, identify product owners who understand the functionality, and critically evaluate whether everything is still needed.

Optix handles a lot natively and via the template library tools. Don't blindly port everything.

PLC Tag Assessment

Assess PLC Tag Naming Conventions

ME points directly to PLC tags rather than maintaining separate HMI tags. Your assessment should focus on the PLC tag structure that Optix will also consume.

Document:

• PLC platform (ControlLogix, CompactLogix, Micro800)
• Tag addressing method (symbolic vs. direct)
• Total tag count referenced in HMI
• Naming convention consistency
• Tag data types in use

The Naming Convention Problem

Common reality across projects developed by multiple engineers over time.

First 100 tags: Tank01_Level_PV, Tank01_Level_SP

Next 100 tags: Tk02Lvl_PV, Tk02Lvl_SP

Next 100 tags: T3_Lev, T3_SetPt

Three different conventions because three different engineers over five years.

Decision:

• Accept as-is: Fast migration, preserves history, accepts inconsistency
• Standardize in PLC: Slower, requires PLC changes, cleaner long-term
• Map in Optix: Use Optix aliases to standardize presentation layer

Recommendation for OEMs: If you're developing machine templates, standardize PLC tag structure. Your templates will be reused 100 times. Invest once in clean tag architecture.

Alarm Configuration

Document Current Alarm Strategy

In discrete OEM applications, alarms are almost always PLC-driven. Both ME and Optix support HMI-based alarms, but they're rarely used in practice.

For Optix migration, document:

• How alarms are triggered (PLC tag monitoring, alarm instructions)
• Alarm priorities
• Acknowledgment requirements
• Logging format and retention
• Custom alarm parameters or displays

Why it matters: Optix alarm system is different (and better) with more sophisticated query and display capabilities. But you need to know what you're replacing to design Optix alarms properly.

Note: Optix has powerful alarm features and functions, but for discrete OEMs, alarms remain primarily PLC-driven with the HMI providing display and acknowledgment.

Hardware Assessment

Target Hardware Decision

Choose your deployment platform based on requirements and budget.

OptixPanel:

• Native Optix support (Perpetual runtime license included)
• Familiar industrial form factor
• Fixed resolution matched to panel
• Replaces PanelView for new Optix deployments

Industrial PC:

• More processing power for complex screens
• Flexible display options
• Higher cost per station
• Runtime license needed
• Additional configuration required
• May require active cooling considerations

Thin Client Architecture:

• Central Optix server with lightweight clients
• Network-dependent operation
• Support just released in Optix 1.6 (early adoption phase)
• Redundancy options available but still maturing
• Scalable for large deployments

Assessment questions:

• Does screen complexity require PC-level performance? (Probably not)
• Need flexibility in display resolution?
• Does network reliability support thin clients?
• What's budget per station?
• Is thin client maturity acceptable for your application?

Skills Assessment

Be Honest About Team Readiness

Evaluate what skills your team has versus what Optix requires.

Required Optix skills:

• HMI design fundamentals (your team has this)
• Understanding of Types and Instances (might have)
• Template architecture thinking (probably don't have)
• Optix Studio interface proficiency (definitely don't have)

Optional but valuable:

• Version control concepts (Optix Studio simplifies this)
• Object-oriented design principles

NOT required for most discrete OEMs:

• C# programming (NetLogic is for edge cases)
• Command-line Git (Optix Studio handles it)

Training Plan

Invest in proper training before starting development.

Before first project:

• Architecture training: Critical (understand template methodology)
• Optix Studio fundamentals: Essential (IDE is very different from ME)
• Template design workshop: Highly recommended (hands-on practice)

During first project:

• On-the-job learning: Expect 50% productivity initially
• Consultant support: Consider for architecture design

After first project:

• Advanced topics: NetLogic (if needed), performance optimization

Read more: The Architecture Advantage: Why Optix Template Design Determines ROI

Integration Options Assessment

External System Connections

Document potential integration requirements even if not currently implemented.

Integration options available in Optix:

• Historian (PI, Wonderware, FactoryTalk Historian)
• Database connections (SQL Server, MySQL)
• MES/ERP systems
• CMMS systems
• Email/notification systems

Note: Most discrete OEM HMI applications don't use these integrations on typical machines. However, documenting whether future integration is planned helps inform architecture decisions.

For any existing or planned integration:

• How does ME currently connect (if applicable)?
• Will Optix connection method differ?
• Are credentials/access documented?
• Who manages external system?

Why it matters: Integration testing happens late. Know requirements early.

The "Gotchas" Audit

Things That Always Surprise Teams

Undocumented dependencies, hard-coded values, and tribal knowledge always emerge during migration.

Undocumented dependencies:

• Global Object behavior tied to specific screen load order
• Alarm logic depends on startup sequence
• Recipe format tied to specific PLC memory layout
• Popup parameter passing that breaks with navigation changes

Hard-coded values:

• Screen resolution assumptions
• Graphical element coordinates

Tribal knowledge:

• "Press F5 twice to reset communications"
• "Don't touch the widget on the main screen"
• "Alarm screen must load first or history doesn't work"
• "Customer X needs button order reversed"

How to uncover:

• Interview original developers (if available)
• Interview operators (they know the quirks)
• Review any documentation (sparse but valuable)
• Test every screen, every feature, take notes

Assessment Deliverables

What You Should Have After Assessment

Completing a thorough assessment produces these critical documents.

1. Screen Inventory Spreadsheet

• All screens listed
• Complexity rated
• Dependencies mapped
• Migration effort estimated

2. Feature Requirement Document

• Must-have features
• Nice-to-have features
• Features to eliminate

3. Technical Debt Report

• What's messy and needs fixing
• What can wait
• What should be eliminated

4. Migration Complexity Score

• Simple/Medium/Complex rating
• Risk factors identified
• Timeline estimate

5. Team Readiness Assessment

• Skills gaps identified
• Training plan
• Resource requirements

6. Integration Map

• Potential integration points identified
• Connection methods documented
• Testing plan (if integrations exist)

Timeline Estimation

Use Assessment to Estimate Realistically

Migration timelines vary significantly based on complexity. Use your assessment to build realistic estimates. Note that the timeframe estimate per machine does not account for the design and architecture work.

Factors that drive timeline:

• Screen complexity and count
• Global Object conversion requirements
• Template architecture design time
• Team learning curve (50%+ overhead on first project)
• Testing and iteration
• Customer-specific customizations

Estimation approach:

Rather than rigid hour formulas, estimate based on complexity tiers.

Simple migration (mostly display screens, minimal Global Objects):

• First project: 2-3x ME equivalent time
• Learning curve is primary factor

Medium migration (mix of complexity, some Global Objects, template opportunities):

• First project: 3-4x ME equivalent time
• Template design and Global Object conversion add significant time

Complex migration (heavy Global Objects, extensive customization, sophisticated templates):

• First project: 4-6x ME equivalent time
• Template architecture design is critical path
• Global Object conversion requires careful analysis

Key insight: By project 3-5, you'll match or beat ME development time. By project 20, you'll be dramatically faster due to template reuse.

The investment in first-project overhead pays dividends through template-driven development on subsequent machines.

Common Assessment Mistakes

Mistake 1: Counting Screens Only

Problem: "We have 20 screens, should take 2 weeks"

Reality: Complexity varies 10x between screens

Fix: Rate complexity, estimate per screen based on Global Object usage and custom logic

Mistake 2: Ignoring Global Objects and Custom Logic

Problem: "We'll deal with the Global Objects when we get there"

Reality: Global Object conversion can double or triple project time

Fix: Assess Global Objects and custom logic upfront, decide convert/eliminate/redesign with templates

Mistake 3: Assuming Team Is Ready

Problem: "Our engineers know ME, they'll figure out Optix"

Reality: Optix IDE is fundamentally different from ME. Engineers who are proficient in ME will struggle with the Optix Studio interface, navigation, and development workflow without training. Architecture understanding is critical, not osmosis.

The learning curve includes:

• New IDE paradigm (project structure, navigation, object browser)
• Template and type system (completely different from ME global objects)
• Version control integration (new workflow)
• Different debugging and deployment process
• New terminology and concepts

Fix: Budget significant training time before first project. Expect 50% reduced productivity during first project as engineers learn the IDE and architecture patterns. Consider consultant support for architecture design on first machine.

Mistake 4: Not Documenting Current System

Problem: "It's all in John's head"

Reality: John gets hit by a bus (metaphorically), knowledge lost

Fix: Document everything during assessment. Capture the "why" behind design decisions, not just the "what."

Conclusion

Good assessment = realistic expectations = successful migration

Invest 3-5 days in thorough assessment to know exactly what you're migrating, understand complexity factors (especially Global Objects and template opportunities), identify blockers early, set accurate timeline based on real complexity, and get team ready with proper training.

Poor assessment = surprises = budget overruns = frustrated engineers

Next step: Take assessment findings and make architecture decisions that will determine your long-term ROI.

Next in Series: Part 3 - Migration Strategies

Get Assessment Help

Need assistance with your readiness assessment?

ASQI offers comprehensive migration readiness assessments. We'll inventory your ME application, assess Global Object complexity, and provide detailed migration plan with realistic timelines.

Contact ASQI →

Related Articles

Migration Strategies: Port, Redesign, or Hybrid? — Once you know what you have, choose the right migration approach for each screen.

Optix Migration Readiness Assessment — Use this structured checklist to evaluate whether your facility is ready to migrate.

Testing & Go-Live: Final Validation and Deployment — The final step — testing, operator training, and cutover planning.