Resolving WinCC 6.2 to 7.4 Migration Display Problems Field Guide

Problem Summary: Intermittent Tag Display After WinCC 6.2 to 7.4 Migration

After completing a WinCC V6.2 to V7.4 project migration using the Project Migrator, runtime behavior frequently shows a split state: a subset of process values updates normally on the HMI screens, while other tags appear frozen, blank, or display placeholder text even though the migration utility reports "WinCC project migrated successfully". No compile or load errors are produced, and the Graphics Designer opens the migrated screens without warnings. The problem only surfaces once the project is placed in Runtime.

This symptom is a known class of migration defect that almost always traces back to one of the following root causes:

1. The source project was not first upgraded to WinCC V6.2 SP3 before the jump to V7.4.
2. Legacy DDE connections were left in the V6.2 project. DDE was removed in WinCC V7.0 and orphan DDE channel references silently break tag updates.
3. The Project Migrator was not used at all (the .mcp file was simply opened in the V7.4 Explorer) — the file is opened but the internal database is not rebuilt.
4. Channel drivers, tag addresses, or quality codes behave differently between the V6.2 and V7.4 AS/OS engineering stacks, producing good vs. bad values side-by-side on the same screen.
5. Global color or visibility animations were inherited but reference now-missing variables, leaving I/O fields visually static.

WinCC Version History and Migration Path Constraints

WinCC does not permit an arbitrary N-to-N version jump. The internal project database schema, the channel DLL contract, and the Graphics Designer tag-binding format all changed at multiple points between V6.2 and V7.4. The supported migration ladder is enforced by the Project Migrator and is not optional.

Reference: Siemens KB 35958594 — Upgrading a WinCC V6.2 project to V6.2 SP3.

Skipping the V6.2 SP3 step is the single most common reason a V6.2 → V7.4 migration produces a runnable but functionally broken runtime. The Project Migrator will often complete without an error code, but tag bindings, alarm classes, and the internal CCDataMgr will be in an inconsistent state.

Root Cause Catalog

The "some values OK, some not online" symptom has five distinct underlying causes. Each is diagnosed with a different tool and corrected with a different procedure.

Root Cause 1: DDE Connections in the Legacy Project

WinCC V6.2 and earlier supported DDE as a data exchange mechanism. DDE was removed in WinCC V7.0. Any tag, archive, or script that used a DDE channel as a source will not receive updates in V7.4 because the DDE channel DLL is no longer loaded.

Diagnostic:

1. Open the original V6.2 SP3 project in the V6.2 SP3 Explorer (do not skip the SP3 step).
2. Right-click Tag Management → inspect every channel. Any channel whose driver name is DDE, WinCC DDE, or FastDDE must be removed or replaced.
3. Search the project for DDE in: Tag prefixes, C-script DDE_ calls, VBS script HMIRuntime.Tags with DDE-prefixed names, and archive tags whose source is a DDE connection.

Resolution: Replace DDE with one of the supported successors before migration:

Root Cause 2: Project Migrator Was Not Run

Opening a .mcp file in WinCC V7.4 Explorer without first running Project Migrator causes the V7.4 Explorer to read the V6.2 binary header, then attempt to load the database directly. The Explorer will typically display the screens and tag list, but the runtime will not start or will start with degraded tag updates.

Diagnostic: In the V7.4 Explorer, select the migrated project → Properties. The Project Version field should read 7.4 after a successful migration. If it reads 6.2, the file was opened but never migrated.

Resolution: Close the project in V7.4 Explorer, then run the migrator as described in Step-by-Step Migration Procedure below.

Root Cause 3: Channel Driver Behavior Change Between V6.2 and V7.4

The S7 channel suite (named "SIMATIC S7 Protocol Suite" in V6.2, "SIMATIC S7-1200, S7-1500 Channel" or renamed S7 channel in V7.4) reorganized its unit list, soft-data handling, and time-stamp resolution. The SIMATIC S7 MPI channel in particular was deprecated in favor of SIMATIC S7-300/400 and SIMATIC S7-1200, S7-1500.

Tags that were originally bound to a renamed or removed channel will migrate to the new channel but the addressing parameters may not translate cleanly. The tag appears "online" because the channel is connected, but the value is stale or constant.

Diagnostic:

1. Open WinCC Explorer → Tools → Channel Diagnosis for the migrated project.
2. For every channel unit, verify the connection state, the configured partner, and the error counter. Look for non-zero Lost Frames or Error Counters.
3. In Tag Management, right-click an affected tag → Properties. Note the assigned channel unit and the address. Compare against the V6.2 SP3 source. If the address syntax differs (for example, DB offset formatting changed), the tag is technically bound but reads the wrong memory location.

Resolution: Re-enter addresses in the V7.4 native syntax. For S7-300/400 the format DB<n>,DBX<x>.BYTE<b> still works, but bit-level tag aggregation and byte-swapping behavior was tightened in V7.4. For S7-1200/1500 you must use the optimized block access path through the SIMATIC S7-1200, S7-1500 Channel.

Root Cause 4: Tag Quality Codes Reporting Bad Communication

WinCC tags carry a quality code that is updated continuously by the data manager. After a failed migration, many tags report quality codes from the OPC Quality Flags namespace. Inspect the codes directly to determine whether the problem is in the PLC, the channel, or the project binding.

Diagnostic procedure (in V7.4 runtime):

1. Open WinCC Explorer → Tools → Tag Diagnosis (or use the WinCC Tag Simulator).
2. Filter the tag list by the affected screen and inspect the Quality column.
3. Cross-reference the quality code with the table above. Group the affected tags by quality code — the grouping reveals the root cause. If all affected tags share 0xC0000040, suspect a DDE or channel-startup issue. If they are mixed, suspect per-tag address re-binding.

Root Cause 5: Color, Visibility, and Animation Bindings

Graphics Designer objects in V6.2 stored color and visibility animations in a property-script format that was extended in V7.4. When a script references a tag that was renamed or had its datatype altered by the migrator, the property evaluates to a default value (typically black or hidden) and the operator sees a "missing" value where there is in fact a value present.

Diagnostic: In the migrated V7.4 project, open a screen containing a suspected value. Select the I/O field → Properties → Output/Input → Output Value. Right-click → Tag. Verify that the tag name resolves and that the datatype is consistent with the source V6.2 project.

Resolution: If the tag is correct but the visual is wrong, check Properties → Colors → Background Color and Font Color for any Dynamic Dialog that references the tag. The Dynamic Dialog in V7.4 can be reset to evaluate the value range and reapply the color mapping.

Pre-Migration Prerequisites

Complete the following checks before running the Project Migrator. Every item is required.

1. Source project must be V6.2 SP3 or later. If the source is V6.2 base, upgrade to V6.2 SP3 first using the procedure in KB 35958594.
2. Remove all DDE connections and references. The migrator will not warn you about DDE — it will simply leave the tags in an unbound state.
3. Compile the V6.2 SP3 project once before migration. A clean compile verifies that all C-scripts, VBS scripts, and Graphics Designer bindings are syntactically valid. The migrator propagates the last successful compile state, so a dirty source produces a dirty V7.4 target.
4. Back up the entire project directory. The Project Migrator does not modify the source in place, but rolling back a partially migrated project is far easier with a clean backup.
5. Verify the OS language. Open Control Panel → Regional and Language Options → Advanced → Language for non-Unicode programs. The migrator inherits this locale; a mismatch with the V6.2 project locale can cause message-library text to be misread.
6. Verify licensing for WinCC V7.4. The V7.4 license (RT 128 / 512 / 2048 / 8192 / 65536) must be installed and the License Server must be reachable from the ES station. Without a valid license, the runtime will start in demo mode and external tags stop updating after one hour.

Step-by-Step Migration Procedure

The procedure below is the canonical two-step Project Migrator flow documented in the WinCC V7.4 Information System.

1. Close the WinCC V6.2 SP3 project in the V6.2 Explorer.
2. Open the Windows Start menu and navigate to Simatic → WinCC → Tools → Project Migrator. The Project Migrator launches and displays the CCMigrator — Step 1 of 2 window.
3. Click the ... button and select the directory containing the V6.2 SP3 .mcp project file. To migrate multiple projects in a single pass, add additional paths by repeating the selection — the migrator processes them sequentially.
4. Confirm the language setting. The default is taken from the OS locale. If the source project was created on a station with a different locale, change the language here to match.
5. Click Migrate. The CCMigrator — Step 2 of 2 window opens and shows the migration steps as they execute. A typical V6.2 → V7.4 migration takes 15 minutes for a 5,000-tag project, but complex projects with extensive C-script libraries can take several hours.
6. Wait for the final message: "WinCC project migrated successfully". If the migrator reports a step failure, note the step number and consult the WinCC Migration.log file in the project directory before re-running.
7. Click Finish to close the migrator.
8. Open the migrated project in WinCC V7.4 Explorer. Verify the Project Version field in Project → Properties reads 7.4.
9. Open the Graphics Designer and compile the entire project. Address any compile warnings — these frequently include "tag type mismatch" or "C-script API function deprecated" — by editing the affected objects.
10. Activate the runtime and run the validation checklist in the Verification section below.

Verification: Confirming a Clean Migration

Once the runtime is active, validate that every tag, alarm, and archive is functioning. Sampling is not sufficient; a defective migration can produce a 99% pass rate with the failure concentrated on safety-critical interlocks.

1. Tag count parity. In WinCC Explorer → Tag Management, count the tags in the migrated project and compare against the V6.2 SP3 source count. The numbers must match exactly. Any delta indicates dropped or duplicated tags.
2. Quality code sweep. Use Tools → Tag Diagnosis. Filter the list to Quality ≠ Good (0x00000000). Every remaining row must be explainable (for example, a tag bound to a CPU that is intentionally in STOP).
3. Alarm class and message class check. Open Alarm Logging and confirm that all message classes from the V6.2 source are present and that the message-numbering gaps have not shifted.
4. Archive continuity. Open Tag Logging and verify that the archive configuration imported, the cycle times preserved, and the archive DB path is writable on the V7.4 station.
5. Script-level execution. Force a value change at the PLC and confirm that the I/O field on the migrated screen updates within one cycle. This is the primary check for the "some values OK, some not" symptom.
6. Recipe and user administration. Open User Administrator and Report Designer to verify that no permission sets or report templates were dropped.
7. Print and logging test. Trigger a controlled report and confirm that the output file format and printer assignment match the source.

Advanced Diagnostics: Channel-Level Forensics

If the verification sweep leaves a residue of bad-quality tags, escalate to channel-level forensics.

1. Open WinCC Explorer → Tools → Channel Diagnosis. The tool displays per-channel-unit statistics including Update Time, Error Counter, Lost Frames, and Connection State.
2. For each channel unit that shows non-zero Error Counter values, open System Tray → SIMATIC WinCC → Channel Diagnostics for real-time data.
3. Enable the Trace for the affected channel: Channel → Properties → Trace. Set the trace level to Detailed and reproduce the issue. The trace log is written to <ProjectPath>\<ComputerName>\Trace_<ChannelName>.log.
4. For S7-300/400 channels, the MPI / PROFIBUS status word in the channel diagnosis indicates whether the AS is reachable, in STOP, or has diagnostic-buffer entries. Open STEP 7 → PLC → Diagnostic Buffer on the AS side and correlate timestamps.

Field-Commissioning Checklist

Use this checklist at the receiving station before signing the FAT/SAT protocol.

Troubleshooting Matrix

Rollback Strategy

If the migrated runtime cannot be brought to a clean state within a defined time budget, the project can be rolled back to V6.2 SP3 by re-opening the backup copy. The V7.4 migrator is non-destructive to the source directory, so the backup is the only safety net.

1. Stop the WinCC V7.4 runtime on every partner and the central archive server.
2. Close the migrated project in the V7.4 Explorer on every engineering station.
3. Restore the V6.2 SP3 backup into the original project directory.
4. Re-open the V6.2 SP3 project on the original V6.2 SP3 station and verify that runtime activates cleanly.
5. Document the root cause of the migration failure, schedule a fresh migration attempt, and re-validate the field-commissioning checklist above.