Troubleshoot TIA Portal V15 to V18 Migration Failure at 1%

Problem Summary: TIA Portal V15.1 to V18 Migration Stops at 1%

When invoking the TIA Portal project upgrade wizard, the migration tool may abort almost immediately — at or near 1% progress — without producing a meaningful error in the user interface. Both TIA Portal V15.1 and V18 are fully installed and updated to the latest service packs, the source project compiles and saves cleanly, and the service pack compatibility check returns green. Despite all preconditions appearing correct, the conversion halts and writes only a cryptic line into the migration log stating that certain files already exist. The target project never opens, and the source project remains at the V15.1 format.

This failure mode is well documented in Siemens Industry Support entry ID 58638200 – Migration Tool TIA Portal, which describes the .amxx intermediate migration file format and the conditions under which the tool refuses to overwrite an existing target. The same entry confirms that the Migration Tool is the only sanctioned mechanism for cross-version project conversion and that the service pack consistency between source and target installations must be verified before invoking the wizard.

This article consolidates the recovery procedure used in field escalations, the root causes observed in practice, and a defensive pre-migration checklist that prevents the failure on subsequent attempts.

Migration Tool Architecture and File Format

Understanding why the migration fails at 1% requires a short review of how the TIA Portal migration tool actually works. The wizard does not modify the source project in place. It instantiates a separate converter process, reads the project in its source schema, and writes a version-neutral intermediate representation that the target TIA Portal installation can then deserialize.

The .amxx intermediate is written to the path you specify in the migration wizard. If the target file name you supplied in the wizard matches a file that already exists in that folder, the converter aborts before it has done meaningful work — which is exactly what the 1% symptom indicates. According to Siemens Industry Support ID 58638200, the migration file is created by the source-side Migration Tool and then read by the target-side TIA Portal; the file name collision therefore happens before any target-side conversion is attempted, which is why progress reads 1% and not 25% or 50%.

Root Cause Analysis

Three root causes account for almost every reported 1% migration abort when both TIA Portal installations are up to date and the source project compiles cleanly.

Root Cause 1 — Pre-Renamed Project Collides with Target Output

The most common cause, and the one reported in the case this article is built from, is renaming the source project to its intended target name before launching the migration. If the project sits in a folder named MyPlant_V18 and the user points the migration wizard at the same name on output, the converter cannot create MyPlant_V18.amxx because the directory of the same name is already occupied. The log message “some files seem to already exist” is the converter reporting the collision. The fix is to never pre-rename the project to its target version name; use a neutral working name and rename after the migration succeeds.

Root Cause 2 — Path Contains Special or Non-ASCII Characters

TIA Portal project storage paths are sensitive to spaces, accented characters, parentheses, ampersands, and Unicode code points outside the basic Latin set. A path such as C:\Users\Jean-Noël\Projets > V18 (final)\ can cause the migration tool to fail to materialize intermediate files. The conservative path C:\Automation\simple\ is recommended for both the source project and the migration target.

Root Cause 3 — Long Source Version History

Projects that have been migrated several times — for example V13 → V13 SP1 → V14 → V15 → V15.1 → V18 — carry forward metadata from every prior schema. The cumulative schema divergence occasionally causes the V15.1 → V18 converter to reject the project even though no individual schema element is wrong. Siemens Support in such cases recommends creating a fresh V18 project and copying the program blocks, PLC tags, HMI screens, and device configurations over, which re-anchors the project in a clean V18 schema.

Diagnostic Workflow

Follow this ordered procedure to confirm the failure mode before applying a fix. The objective is to isolate whether the cause is naming, path, schema, or installation.

1. Open the migration log. In TIA Portal, the migration wizard writes Siemens\Automation\Logs\MigrationTool\ under %LOCALAPPDATA%. Look for the literal string “file already exists”, “already present”, or “cannot create”.
2. Inspect the target file path. The wizard displays the exact output path and name. Verify that no file or folder with the same name exists at that location.
3. Verify service pack consistency. From Help > Installed software in both TIA Portal V15.1 and V18, confirm that both installations are at the latest update. A mixed SP level is the most common reason the SP check reports green but the conversion still fails.
4. Confirm the source compiles. Compile the entire STEP 7 program and the HMI where applicable. A compile error blocks migration. Resolve all warnings about unsupported instructions or libraries.
5. Test on a copy. Copy the source project to C:\Temp\mig\src\ and attempt migration to C:\Temp\mig\dst\new\. A clean path often isolates the issue to the original storage location.
6. Archive and re-extract the source. In V15.1, choose Project > Archive to produce a .zap15_1 file, then Project > Retrieve into a fresh folder. This rebuilds the project container and strips transient state that occasionally interferes with the converter.

Solution 1 — Project Renaming and Path Hygiene

The first fix to apply, and the one that resolves the majority of 1% failures, is to control the project name and the storage path.

1. Close the project in V15.1.
2. Right-click the project folder in Windows Explorer and rename it to a neutral working name, for example MyPlant_src. Do not include the target version number (_V18) in the name.
3. Move or copy the renamed project to a path with no spaces, no special characters, and no Unicode characters, for example C:\Automation\src\.
4. Open the project in V15.1, perform Project > Save as, and choose a fresh name if you want additional safety.
5. Launch Project > Migrate to project (or the Migration Tool) and specify a target path such as C:\Automation\dst\MyPlant\. The target name must differ from the source name.
6. When the migration completes, rename the resulting V18 project to its final name.

The naming rule can be stated simply: the source folder name, the source project name inside TIA Portal, the target file name in the migration wizard, and the destination folder name must all be different from each other, must be ASCII-only, and must contain no characters outside A–Z, 0–9, and underscore.

Solution 2 — Service Pack Update Order

Although the source reports that both V15 and V18 are fully updated, the wizard in some environments does not detect mismatches that the user can see in Help > Installed software. Apply updates in this order before re-attempting the migration:

1. Update TIA Portal V15.1 to the latest available update through Help > Installed software > Update or via the Siemens Automation Tool.
2. Restart the workstation. TIA Portal caches SP metadata; a stale cache can report green while the underlying binaries are out of sync.
3. Update TIA Portal V18 to the latest available update.
4. Re-open the V15.1 project, compile, save, and close.
5. Launch the migration tool from the V18 installation. Launching from the target installation, not the source, is the supported entry point per Siemens Industry Support ID 58638200.

If intermediate versions are not available on the workstation, note that the migration wizard is designed to skip versions; the typical Siemens-supported upgrade paths are V15.1 → V18, V16 → V18, and V17 → V18, provided both ends carry the latest service pack. The lack of V16 and V17 in the environment is not a barrier to a direct V15.1 → V18 migration.

Solution 3 — Recreate the Project and Copy/Paste

When the project originated in a much older TIA Portal version (V13 in the source case) and the migration log does not point to a clean root cause, Siemens Support typically recommends recreating the project from scratch in V18 and migrating the content by copy and paste. The procedure preserves the engineering content while discarding the schema baggage accumulated through multiple upgrades.

1. Create a new V18 project with the same PLC and HMI device targets as the source project. Match the device order numbers and firmware versions exactly, otherwise references will not resolve on paste.
2. In V15.1, open the source project. Open the new V18 project side by side.
3. From V15.1, copy PLC tags, program blocks, data blocks, watch tables, traces, and HMI screens in that order. Paste into the matching folders in V18.
4. Resolve any references that are reported as unresolved after the paste. Most resolution failures come from device firmware mismatches or from removed library elements.
5. Compile both the STEP 7 and HMI portions of the V18 project. Resolve all errors before attempting to download.

Solution 4 — Split the Project

For very large projects, splitting the project into smaller parts and migrating each part independently can work around converter size limits and orphan reference errors. The split procedure depends on whether the project contains a WinCC component.

1. STEP 7 only: Identify logical subsystems (one PLC per cell, for example). Create a fresh V15.1 project containing only one PLC and its associated program blocks. Migrate that subset to V18. Repeat for each subsystem.
2. With WinCC: Split the project into the STEP 7 portion and the WinCC portion. Migrate STEP 7 first. Then create a new V18 project and attach the migrated STEP 7 to a new WinCC runtime of the same version. Re-create HMI tags by export/import (CSV) rather than by copying the WinCC project wholesale.

Splitting is a last resort because every split introduces risk of cross-reference loss. Use it only when the consolidated migration has failed twice with the same log signature and the project size exceeds several thousand blocks.

Engaging Siemens Support

If the four solutions above do not produce a clean migration, open a Support Request through the Siemens Industry Online Support portal. The escalation path is:

1. Navigate to support.industry.siemens.com and sign in with your Siemens customer account.
2. Click Support Request and select the product “TIA Portal” and the version that fails (V18 in this case).
3. Attach the source project as a .zap15_1 archive (under 2 GB is the standard upload limit; for larger projects use the Siemens upload link provided in the ticket).
4. Attach the migration log from %LOCALAPPDATA%\Siemens\Automation\Logs\MigrationTool\.
5. Attach screenshots of Help > Installed software for both TIA Portal installations.
6. State the original version of the project (V13 in the reference case) and the migration history.

Siemens Support has direct access to the development team for the migration tool and can dispatch the case to engineering if the issue is reproducible. Include the project only as an archive; never share an open .ap* folder because the internal files reference absolute paths and lock files that the support team cannot read.

Verification Steps

After a successful migration, run the following verification sequence before considering the project ready for commissioning or download.

1. Compile everything. Use Program > Compile > All in the STEP 7 portion. Use HMI > Compile > All in the WinCC portion. The compile must finish with zero errors. Warnings are acceptable if they were present in the source project.
2. Cross-reference check. Open Tools > Cross-references and verify that the number of cross-referenced objects matches the source project to within a few percent. A drastic drop indicates that a paste operation dropped a referenced block.
3. Device consistency. Open each device in the project tree and verify the firmware version. A migrated S7-1500 may have its firmware upgraded to match the new TIA Portal catalog; confirm this against the actual hardware in the field before downloading.
4. Library reconciliation. Compare the libraries used in V15.1 against those in V18. If V18 contains a newer major version of a library, review the release notes for breaking changes before compiling.
5. HMI tag link check. In the HMI editor, open Tools > Tag simulation or Tools > Cross-reference to confirm that HMI tags still resolve to PLC tags.
6. Project archive round-trip. Archive the migrated V18 project to a .zap18 file, then retrieve it to a different folder and open it. If the retrieved project opens and compiles, the migration is durable.

Pre-Migration Checklist

Use this checklist before every TIA Portal version migration to prevent the 1% failure mode and other common abort conditions.

Troubleshooting Matrix

Field-Proven Caveats

• Do not pre-rename the project to its target version. This is the single most common cause of the 1% abort. A project named Line_V18 sitting in a folder Line_V18 will collide with the migration target.
• Do not run the migration from a network share. The converter performs many small file operations; a slow or interrupted SMB connection produces partial writes that look like collisions. Stage both source and target on a local drive and copy back when finished.
• Do not attempt parallel migrations. The Migration Tool uses a per-user lock file. Running two migrations as the same Windows user from different V15.1 windows corrupts both target folders.
• Do not modify the project during migration. The source must be closed and not edited until the target has been opened and saved in V18. Any write into the source during the conversion will desynchronize the converter and the target will fail to open.
• Long file paths are capped at 260 characters. If the fully qualified path of the target file exceeds the Windows MAX_PATH limit, the converter fails silently. Use short folder names and keep the project near the drive root.

Related Procedures

For projects where the migration is part of a larger hardware upgrade (for example S7-1500 CPU replacement or TIA Portal upgrade as part of a STEP 7 V5 to TIA Portal transition), the migration must be sequenced with the hardware swap. The recommended order is: migrate the software first in a test environment against the new TIA Portal version, validate on a test bench with the target CPU, and only then schedule the production cut-over. The Siemens Migration Tool entry ID 58638200 covers the converter mechanics; the project-level upgrade planning is covered in the TIA Portal help under Migration > Planning the migration.