Migrating STEP 7 V5.4 to TIA Portal V11: Error Fix Guide

Overview

Migrating a STEP 7 V5.4 (or V5.5) project to TIA Portal V11 (V11.0, V11 SP1, or V11 SP2) is a one-way conversion. The legacy project is consumed by the TIA Portal migration wizard, which produces a TIA V11 archive (.ap11) that contains the program blocks, hardware configuration, and the WinCC flexible (or WinCC Advanced) runtime data. Unlike a normal Save As operation, the migration rewrites every block into the TIA Portal representation, performs an implicit type check, and registers every tag in the new TIA symbol table. Any defect in the source project becomes a hard stop at the import boundary.

Three failure modes account for the majority of TIA V11 migration attempts that get stuck in the field:

• An unsupported source version (anything older than STEP 7 V5.4 SP5)
• An internal SQL Server error inside the TIA V11 installation (typically surfaced as a silent wizard exit)
• IEC 61131-3 type mismatches that the TIA compiler enforces but STEP 7 V5.4 ignored by default

Each is fully recoverable if you attack it in the right order. The procedure below covers all three paths, the .AM11 standalone conversion tool that ships on the STEP 7 V11 SP2 DVD, the hardware and HMI migration constraints, and ends with a post-migration verification checklist plus a troubleshooting matrix.

Source Project Version Requirements

TIA Portal V11 does not migrate every STEP 7 V5.x build. The migration wizard only recognizes projects that have been opened and saved with one of the source versions below. The check is performed against the source project's internal version stamp, not against the service pack installed on the TIA V11 target machine.

If the source project was last saved on a build older than V5.4 SP5, open it in V5.4 SP5 (or V5.5), perform a File → Save As, and close the project. That re-save updates the internal version stamp and is sufficient. Do not change any block contents during this step — the goal is to touch the version metadata only.

The TIA V11 installation itself must be on a TIA V11 SP2 build to use the standalone Migration_Tool_TIA_V11.exe (covered in detail below). TIA V11 SP0 and V11 SP1 cannot consume the .AM11 file format and must rely on a direct STEP 7 V5.5 install on the same PC for migration.

Pre-Migration Project Sanity Check (STEP 7 V5.4 / V5.5 Side)

Before launching the TIA V11 migration wizard, perform these checks in the source environment. They take 10–30 minutes and resolve the majority of the wizard-opens-then-dies failures reported in the field.

1. Update CPU firmware in the project. Open HW Config and inspect every CPU in the rack. TIA V11 requires firmware V2.6 or newer for the S7-300 CPUs in the 315-2 PN/DP and 317-2 PN/DP families (6ES7315-2EH14-0AB0, 6ES7317-2EK14-0AB0, 6ES7315-2FJ14-0AB0, 6ES7315-2FG14-0AB0, and related part numbers). If the project still shows V2.0, the migration wizard imports the program but rejects the hardware configuration and the CPU lands in the unsupported objects list. Update the firmware by double-clicking the CPU in HW Config, opening the Firmware properties tab, and selecting the V2.6 firmware file from the matching Hardware Support Package.
2. Run Check Block Consistency. In the SIMATIC Manager, right-click the Blocks folder and select Check Block Consistency. Resolve every reported inconsistency. Sources, in order of frequency, are: a block that compiles in STEP 7 V5.4 but not under strict IEC checking, a block with an unresolved symbol (a symbol marked in red in the symbol table), and a block that was generated by an old S7-SCL or S7-GRAPH compiler that is not on the V5.4 SP5 compatibility list.
3. Compile all blocks (Compile and Check Objects). Use Options → Compile and Check Objects → All (or the toolbar equivalent). The compiler report must contain zero errors. Warnings are tolerated; errors are not. The most common hard error is described in the Type Checking and Compile Errors section below.
4. Re-save the project. Use File → Save As and overwrite the existing project. This updates the internal time stamp and the version metadata that the TIA wizard reads on import.
5. Resolve every block-with-no-symbol warning. Even if the warning is non-fatal in V5.4, the TIA V11 import is stricter. A symbol assigned to a block that does not exist in the program makes the wizard's import pass ambiguous and can stall the import.

If your compile-all produces a hard error such as Error: Actual data type WORD does not fit the formal type INT of the formal parameter., jump directly to the Type Checking and Compile Errors section below — do not attempt to import into TIA V11 until the V5.4 project compiles cleanly. The TIA V11 wizard will reject the project outright on the first compile step.

SQL Database Error Resolution (TIA V11 Installation Repair)

The single most common failure on a clean TIA V11 install is an internal SQL Server error raised during the import wizard. The visible symptoms are:

• A dialog reporting Internal error: Cannot connect to project database.
• The migration wizard closing silently after clicking Continue, with no log file produced.
• Event Viewer (Application log) entries with source SQLSERVER or MSSQL$TIA reporting a corrupt master database or an inconsistent system catalog.
• The wizard finishes in under 30 seconds, even for a medium project that should take 5–10 minutes.

TIA V11 SP0 and V11 SP1 ship with SQL Server 2008 R2 Express as the internal project store. TIA V11 SP2 ships with SQL Server 2012 Express (LocalDB). A clean install that passes the installer's own checkboxes can still leave the SQL instance in a state that the migration wizard cannot open. The fix is a full repair of the TIA Portal installation using the original distribution media.

1. Insert the TIA Portal V11 DVD (or mount the ISO) on the target PC. Use the STEP 7 V11 SP2 DVD, not the WinCC V11 SP2 DVD — the SQL repair is part of the PLC installation, not the HMI installation.
2. Cancel the auto-start, then run Setup.exe from the root of the media.
3. On the Installation Type screen, select Repair.
4. Accept the default selection of all installed products and click Repair.
5. Allow the installer to re-register the SQL Server instance, rebuild the master and msdb databases, and reapply the SQL stored procedures used by the TIA portal.
6. Reboot the PC when prompted. The reboot is required because the SQL service is stopped and restarted by the repair.
7. Re-launch TIA Portal V11 and run the migration wizard again. The SQL error is, in the majority of cases, gone.

If the SQL error appears only when migrating a specific project and the wizard succeeds on a small test project, the issue is in the project, not the installation. In that case, run the same Repair procedure and then re-run the migration on a copy of the project. The project file is a likely candidate for a corrupted container that the SQL instance cannot ingest.

Type Checking and Compile Errors (WORD vs INT)

TIA Portal V11 enforces IEC 61131-3 strict type checking at compile time. STEP 7 V5.4 with the default permissive type checking allows a WORD to be passed where an INT is declared, with an implicit conversion that the compiler inserts silently. The TIA V11 compiler rejects the same call. The most common visible error after a successful migration is:

Error: Actual data type WORD does not fit the formal type INT of the formal parameter.

The error typically appears in three places in a migrated project:

• FC/FB interface declarations where a TEMP, IN, OUT, or IN_OUT variable is declared WORD but called with an INT actual parameter (or vice-versa). The Siemens Technical Support workflow has noted that this is most common in FC9, FC10, and FC11 of legacy S7-300 libraries shipped with V5.4 SP0–SP3.
• Symbol table entries that pre-date V5.4 SP5 and use the legacy data type WORD on a tag that later code treats as INT. The symbol table declaration overrides the block-local declaration in some legacy V5.4 builds.
• Generated blocks from older S7-SCL or S7-GRAPH compilers that emit WORD for what is logically a counter or loop index.

The compiler report in TIA V11 points to the affected block but does not give a network or line number inside the block. For an LAD or FBD block with multiple networks, this is the most time-consuming defect to locate. The two practical paths are: fix the declaration in the source STEP 7 V5.4 project and re-migrate, or temporarily disable the strict type check in the source so that the import succeeds and the fix can be applied post-migration.

Path A: Disable Type Checking in V5.4 (Authorized Workaround)

Siemens Technical Support has, in migration cases where the offending block cannot be located, authorized disabling the type check in STEP 7 V5.4 prior to running the compile-all. The setting is a single checkbox in the SIMATIC Manager options.

1. In the SIMATIC Manager, open Options → Customize.
2. Select the STL/LAD/FBD Editor tab.
3. Under Block / Check, clear the checkbox Check IEC types.
4. Click OK.
5. Re-run Options → Compile and Check Objects → All. The compiler will now accept WORD/INT implicit conversions.
6. Save the project, then launch the TIA V11 migration wizard.

Path B: Locate and Fix the Offending Block in V5.4

If the project is regulated or requires a clean compile after migration, locate the offending block in V5.4 and correct the declaration before re-migrating. Start with the blocks the compiler report names directly — typically FC9, FC10, FC11 in a standard migration — and inspect their variable declaration tables:

1. Open the block in the LAD/FBD/STL editor.
2. Select the Interface section at the top of the editor.
3. For every TEMP, IN, OUT, and IN_OUT variable, confirm the data type matches the caller's actual parameter. If the formal parameter is INT, the actual must be INT or DINT. If the formal parameter is WORD, the actual must be WORD, DWORD, or BYTE.
4. Check the symbol table for the same tag name. The symbol table declaration overrides the block-local declaration in some legacy V5.4 builds.
5. Apply the fix. Two options:
   • Change the formal parameter type from WORD to INT (or vice versa) so the types match.
   • Insert an explicit WORD_TO_INT (or INT_TO_WORD) conversion in the block body at the call site. The conversion is unambiguous to the TIA V11 compiler and does not require disabling the type check.
6. Re-run Check Block Consistency and Compile and Check Objects → All. Confirm zero errors.

With the type mismatch resolved, re-save the project and launch the TIA V11 migration wizard. The import should complete without raising the formal/actual type error.

The .AM11 Conversion Path (V5.5 → V11 SP2)

If the TIA Portal V11 PC does not have a STEP 7 V5.5 installation (and you do not want to install one), TIA V11 SP2 ships a standalone conversion tool that consumes a V5.5 project and emits an .AM11 archive. The .AM11 file is what the TIA V11 SP2 migration wizard imports in place of the original .S7P project. The tool is only on the V11 SP2 DVD; it is not on the V11 SP0 or V11 SP1 media.

1. On PC-A (with STEP 7 V5.5 installed and the source project openable), insert the TIA Portal V11 SP2 DVD.
2. Open the DVD in Windows Explorer and navigate to \Support\Migration_Tool_TIA_V11\ (or the equivalent support directory on the DVD root).
3. Copy Migration_Tool_TIA_V11.exe and its supporting DLLs to a local folder on PC-A.
4. Launch the tool. The GUI accepts a STEP 7 V5.5 project file (.S7P) as input and asks for an output path.
5. Click Convert. The tool emits a single .AM11 file.
6. Copy the .AM11 file to the TIA V11 PC (USB stick, network share, etc.).
7. On the TIA V11 PC, launch TIA Portal V11 SP2, choose Project → Migration of STEP 7 V5.x project, and select the .AM11 file.
8. The migration wizard now runs the same import pipeline as a direct V5.5 import. The .AM11 path exists because the wizard cannot be pointed at a V5.5 project on a PC that does not have V5.5 installed; the standalone tool effectively extracts the project metadata into a format the V11 SQL store can ingest.

Hardware Configuration Migration Details

Not every S7-300/S7-400 configuration migrates cleanly. The following part numbers and firmware levels are the most common in field migrations and have known migration behavior in TIA V11:

HMI and WinCC flexible Migration

If the source STEP 7 project contains a WinCC flexible 2008 (SP2 or SP3) project linked via the Integrated link in SIMATIC Manager, the TIA V11 wizard will migrate both the PLC and the HMI in a single pass. The resulting TIA V11 project contains a WinCC Advanced (V11) HMI device alongside the PLC device.

Supported WinCC flexible source versions:

After migration, verify the following in the TIA V11 HMI device:

• Tag count. Open the HMI device → HMI tags → Show all tags. The tag count should match the source WinCC flexible project. A lower count means the source contained tags that the V11 migration did not recognize (typically event tags or limit-value tags that have no direct V11 equivalent).
• Connections. The HMI connection to the PLC is recreated automatically; verify the connection point in the HMI device → Connections table is the migrated PLC device, not a stale reference.
• Screens. The TIA V11 project contains the same number of screen objects as the WinCC flexible source. Some legacy ActiveX controls (WinCC flexible 2005 era) are not migrated and must be re-inserted by hand.
• Alarms. Discrete alarms migrate with their trigger tags. Analog alarms require manual range and limit checks after migration.

If the WinCC flexible project is on a different release than the supported list above, upgrade the source first (WinCC flexible 2008 SP3 is the most common upgrade target), save, and re-run the migration. The TIA V11 wizard does not auto-upgrade the WinCC flexible source.

Migration Procedure (TIA V11 Wizard)

With the source project sanitized and the TIA V11 installation repaired, the actual migration is a five-step wizard. The procedure is the same whether the input is a .S7P file (direct import) or an .AM11 file (standalone conversion):

1. Open TIA Portal V11. From the Project menu, select Migration of STEP 7 V5.x project.
2. Browse to the source .S7P file (or the .AM11 archive if you used the standalone tool). Click Open.
3. The wizard displays a list of unsupported objects. Review the list. Typical exclusions are: CP 343-1 with firmware older than V2.6, FM 350 counter modules, and certain S7-300 CPs with proprietary protocols. Accept the list and continue. The wizard does not abort on unsupported objects — it imports the rest.
4. The wizard runs the import. This takes 5–30 minutes for a medium project (50–200 blocks). Watch the progress bar — a fast exit (under 30 seconds) usually means the SQL connection failed and you need the repair path from above.
5. When the wizard completes, the TIA V11 project opens. Click Compile → All immediately. Any error at this point is a post-migration type mismatch that the source V5.4 compile did not catch; the fix is in the TIA V11 project, not in V5.4.

Do not skip the immediate Compile All after the wizard closes. The wizard is best-effort: it copies the source into the TIA SQL store but does not re-run the IEC type check on every block. The first compile is the one that surfaces any latent mismatch.

For multi-project plants, repeat the procedure for each STEP 7 V5.4 project and merge them in the TIA Portal project tree. The TIA V11 wizard does not import multiple projects in a single call.

Post-Migration Verification

Use the following checklist on the migrated TIA V11 project before you commit to a download:

A clean pass on every row above means the migration is functionally equivalent to the source. The project is then ready for a staged download to a test CPU before being committed to production. If any row fails, refer to the Troubleshooting Matrix below.

Troubleshooting Matrix

Field-Proven Notes

Practical constraints that fall outside the wizard's documentation but are observed in the field:

• Migration is one project at a time. The TIA V11 wizard does not support a multi-project import. If your plant is split across multiple STEP 7 V5.4 projects, migrate each one to a separate TIA V11 project and merge them after the fact in the TIA Portal project tree.
• S7-200 is not migratable in TIA V11. S7-200 support arrives in TIA Portal V13 with the S7-200 Smart migration tool. For V11, S7-200 projects have to be hand-rewritten into S7-1200 code.
• Protective S7-300 CPs require a separate firmware update. The CP 343-1 (6GK7343-1EX30, 6GK7343-1EX40) is migratable, but the project must contain a CP firmware V2.6 or later. The CP firmware is updated in HW Config under the CP properties, not the CPU properties.
• UDTs with nested structures can fail silently. A UDT that contains another UDT as a member sometimes imports with the inner UDT flattened. Verify the UDT structure in the migrated project before relying on it.
• S7-PLCSIM V11 is required to simulate the migrated project. S7-PLCSIM V5.4 cannot simulate a TIA V11 project. If the source validation was done in PLCSIM V5.4, the validation has to be redone in PLCSIM V11.
• Save the V5.4 source project alongside the TIA V11 project. The TIA V11 project is a one-way conversion; the original V5.4 project remains the only authoritative source. Maintain both until the V11 project is in production for a full year.

For projects that pass the post-migration verification checklist and the troubleshooting matrix, the migration is functionally complete. The project is then ready for a staged rollout: download to a test CPU, run the test plan from the V5.4 validation record, and only then promote to production. For a deeper reference on the TIA Portal project model, see the Siemens Industry Online Support entry index for SIMATIC TIA Portal V11.

FAQ